sgp_

We tried a specialized Ethereum smart contract auditing AI tool. It made up a bug and suggested introducing the same critical vulnerability to fix it.

There's a lot more context about what browsers they recommend (and what they recommend them for) on the dedicated page for it: https://www.privacyguides.org/en/desktop-browsers/

The part you quoted was an example of what _not_ to do ("not the time").

Hey, I'm Justin from the 501(c)(3) fiscal host of Privacy Guides, MAGIC Grants. Us board members administer the funds for Privacy Guides, and we are different people than those who are on the Privacy Guides committee.

I assure you that Privacy Guides has not made a deal with Brave or any other of the tools that it recommends on the website. I'm happy to address any other questions about raising funds if you have them.

There are lengthy discussions about whether to recommend a tool or not on the Privacy Guides GitHub and their forum. There is a lot of great context there.

Ironically, not necessarily.

If you sent funds to Coinbase's provided address and they wanted to refuse/refund it for some reason, your new owned output would likely be marked as clean and from Coinbase.

This may vary across circumstances of course. And they may decide to refuse to issue a refund.

It's not comparable though. The simplified (though slightly wrong) way to think about Grin is that its privacy is like Monero but without Monero's ring signatures. Its transaction graph privacy is quite weak.

While the author of this article makes some mistakes, here's an example of that weakness: https://medium.com/dragonfly-research/breaking-mimblewimble-...

Grin developers said in response:

The Grin team has consistently acknowledged that Grin’s privacy is far from perfect. While transaction linkability is a limitation that we’re looking to mitigate as part of our goal of ever-improving privacy, it does not ‘break’ Mimblewimble nor is it anywhere close to being so fundamental as to render it or Grin’s privacy features useless.

Hiding addresses and amounts is certainly better than Bitcoin, but the transaction graph privacy offered by Grin is significantly weaker than Monero. It's not the same.

About 25,000 transactions per day right now. So about 750,000 per month.

Edit: here's a good comparison chart https://moneroj.net/percentage/

I feel you're deliberately being pedantic. There's nothing legally dictating 1 pound of flour = any other 1 pound, but it is fungible, by the definition of them being indistinguishable.

1 NFT isn't the same as any other NFT. They're deliberately non-fungible.

Specific Bitcoin outputs have histories associated with them. While you dismiss this as related to traceability (which is also true), it still stands that one output with a favorable history is preferable to an output that was known to be mined in North Korea.

For these differences, as evidenced by the specific exchange action examples in the linked article, show that different output histories allow companies like Chainalysis, CipherTrace, TRM Labs, and Elliptic to add specific risk scores to outputs. Those with lower risk scores are worth more than those with higher risk scores. This is a breakdown in fungibility.

This largely is not true. While privacy on LN is still being evaluated, it is also extremely complicated. There's no easy "privacy on LN" guide that's industry standard, for example. Monero comparatively is much older and much better understood on the privacy side (eg: see Breaking Monero).

Largely, no. While the full privacy implications of lightning network use are extremely complicated and still being researched (and the best practices updated with that information), it absolutely is not as simple as open/close channel, done.

Also, with enough time, all the Bitcoins would be dirty.

This is a misconception. Coins are only associated with the last identified node. So for example if I sent tainted BTC to Coinbase, sure Coinbase would investigate my account obviously. But the coins can be used from then on as "clean" Coinbase coins, until they hit the next identified node by blockchain analysis companies.

I work for Cake Wallet and Monero.com so I'm biased, but you should try one of the wallets that does this relatively burdensome scanning task locally to see that normally it's not the end of the world. It takes me only a few seconds to scan a month of blocks.

Kraken US supports Monero, so clearly it can be done. If another exchange chooses not to, that's a company making their own decision.

Monero is on Kraken US. Coinbase and Gemini, acting as companies choosing to add the coin they're mutually invested in Zcash instead of Monero, is a dumb indicator to use of what's "allowed," especially when there are obvious compliant examples in the US (Kraken, DV Chain, etc).

Don't take my word for it. Read what FinCEN says directly:

https://www.fincen.gov/sites/default/files/2019-05/FinCEN%20...

Well, you see what FinCEN says about those:

An anonymizing software provider is not a money transmitter. FinCEN regulations exempt from the definition of money transmitter those persons providing “the delivery, communication, or network access services used by a money transmitter to support money transmission services.” This is because suppliers of tools (communications, hardware, or software) that may be utilized in money transmission, like anonymizing software, are engaged in trade and not money transmission.

In simple terms, the Monero developers are providing software (the Monero network, nodes, and wallet software) that can be used for money transmission, but the developers do not need to register as MSBs unless they also have a side company that conducts money transmission.

Obviously not legal advice, but FinCEN's guidance is quite easy to follow here:

https://www.fincen.gov/sites/default/files/2019-05/FinCEN%20...

Providers of anonymizing services, commonly referred to as “mixers” or “tumblers,” are either persons that accept CVCs and retransmit them in a manner designed to prevent others from tracing the transmission back to its source (anonymizing services provider), or suppliers of software a transmittor would use for the same purpose (anonymizing software provider).

An anonymizing services provider is a money transmitter under FinCEN regulations. The added feature of concealing the source of the transaction does not change that person’s status under the BSA.

An anonymizing software provider is not a money transmitter. FinCEN regulations exempt from the definition of money transmitter those persons providing “the delivery, communication, or network access services used by a money transmitter to support money transmission services.” This is because suppliers of tools (communications, hardware, or software) that may be utilized in money transmission, like anonymizing software, are engaged in trade and not money transmission.

Another resource: https://www.perkinscoie.com/en/news-insights/anti-money-laun...

There are many ways to account for this in a risk-based approach however. Asking for basic information about a customer's occupation and source of funds (as is common when opening a bank account) can adequately address ML/TF risks. You don't see exchanges freaking out over other higher-risk activities like onboarding PEPs, but they can do this with proper risk controls.

https://www.perkinscoie.com/en/news-insights/anti-money-laun...

Miners are unlikely to be money transmitters under current regulatory guidance since they never "accept" money for transmission. They only verify transactions that they never have custody over.

Creator of the Breaking Monero series and a compliance analyst at a cryptocurrency OTC desk here.

This mixer was penalized for running an unlicensed MSB. This is far more about that then it is about banning privacy technologies generally. For traditional Bitcoin mixers as in this case, someone receives money from users and then transmits money to many users. This is money transmission and requires registration with FinCEN and sometimes requires registration with states (though some states have exemptions for completely crypto to crypto transmission that doesn't touch USD or other fiat).

Mixing in this case is interactive where there is a clear money transmitter. In Monero's case, the ring signature "mixing" (mixing is a terrible/misleading way to refer to ring signatures) is non-interactive, and there is no intermediary (eg: a mixer) acting as a money transmitter. Thus, there is nothing to fear from this specific enforcement action.

I'm happy to answer other questions as well. But for money transmission to occur, an intermediary needs to accept customer funds. For a Monero transfer, there is no intermediary. Someone could build an MSB on Monero itself which would require registration, but using Monero to send funds directly to a merchant for one's own purchase, for example, is not money transmission.

Correct, not as far as I can tell. The methods they describe may be applicable to CoinJoin services (at least the very high-level methods are applicable), but they didn't show any testing with these sort of transactions (unless that's covered by one of the two "Unknown"s, which isn't likely).

Monero has a significantly higher "base level" privacy than other cryptocurrencies, and it's great for many use-cases. However, it still has limitations. You should check out the Breaking Monero series: https://www.monerooutreach.org/breaking-monero/

I work in compliance for an OTC desk that supports Bitcoin, Ethereum, Monero, others: https://dvchain.co

We conduct AML on everyone who is onboarded, but we're of the opinion that trades should not be public information.

It's not impossible to use properly, but it requires time and money. Just to enter the Samourai mixing pools, for example, costs ~$5-270, exclusive of Bitcoin miner fees. Mixing can also take days. Mixing may provide the intended effect for some people, but it's certainly not something for non-enthusiasts. Plus, Chainalysis and other companies will just mark the whole mixing pool as higher risk anyway and flag those deposits with exchanges, even if they can't trace it.

Is having your coins flagged by an exchange for using privacy features convenient?

Exactly, people freak out when companies look at public data on an open, permissionless network. What did you expect?

The really short answer is that you should not have an expectation of privacy when sending public transfers. Even in the best case that mixers protect your privacy, your transactions will be flagged by exchanges and services as relating to mixing or another privacy feature. The really only way to have privacy without drawing suspicion is Monero. It sounds like shilling but it's true.

I spoke with Eric a few months ago to help give a few pointers when he was considering the idea for this movie. He saw some of the media surrounding "Monero Means Money," our film that we put together from idea to theaters in a week. I explained how I cold called theaters who were very willing to show unusual movies at this time while they have essentially no revenue.

https://www.vice.com/en_us/article/jgewky/how-a-random-guy-m...

For us, getting a movie on the charts was more of a logistics challenge than anything, and I assume it was the same for him. Congrats to Eric and everyone else involved for topping the charts!

This has apparently been in their policy since July 20, 2018: http://web.archive.org/web/20180721081756/http://www.century...

Thanks for being informed about some of the limitations! I highly appreciate having these conversations, and I look forward to working with you to improve Monero.

Main issue: Ringsize is small. Used to be 3 [why??] got bumped to 5 because 3 is obviously useless. Now getting bumped to 7. The team is taking a very aggressive approach here. Aggressive approaches with security tend not to work. They should be conservative and set the ringsize high then back off later once they have done the research to support a small ringsize.

This is a balancing act. Will the anonymity set actually lower if transaction fees double?

Despite this they refuse to provide any sort of disclaimer. Contrast to Tor Project which makes a big deal of telling users they can hurt themselves and Tor is not some magic. In comparison Monero just claims untraceable & private with no caveat whatsoever. This is irresponsible & reckless, damaging to users and not justified. Only when users start thinking and asking questions are they told oh of course you need to churn but no one knows what this is.

The response to all this is 'churn'. This is sending coins to yourself [looks same as sending to other people] so that you obfuscate the connection over time. But despite that this is a core feature of Monero they have provided zero research zero guide on how to do so. They spend money and time researching fancy new maths and this is great. Yet the core functionality to answer the question: How anonymous am I, how mixed in am I, this remains unanswered.

Despite this they refuse to provide any sort of disclaimer. Contrast to Tor Project which makes a big deal of telling users they can hurt themselves and Tor is not some magic. In comparison Monero just claims untraceable & private with no caveat whatsoever. This is irresponsible & reckless, damaging to users and not justified. Only when users start thinking and asking questions are they told oh of course you need to churn but no one knows what this is.

I think thus is a fair concern, but no one has "refuse[d] to provide any sort of disclaimer." I think it's totally fair to write one up. Add it to a certain portion of the website.

For churning, research has been ongoing. Specifically for EAE scenarios.

1. Unencrypted transactions. Your ISP or NSA may easily monitor which tx you broadcast. This let them link your IP to a tx as well as link your tx across time. Even though HTTP is used thus adding TLS [unauthenticated but at least preventing passive snooping] would be an obvious step. On the other hand... traffic analysis might break this anyway. Tor is needed to really protect but see below.

Kovri will include encrypted connections. Monero community members have never claimed to provide IP protection in the current state. If you are currently worried, use a public hotspot somewhere.

2. Wallet leaks information. When connecting, it requests block info from the last block it has. This allows tracking that user over time. The obvious solution of having the wallet always request fixed number of blocks back in history is not implemented. This is simple engineering fixing, not fancy math.

This is an issue with remote nodes only. This can be mitigated at a cost of efficiency, and even if mitigated, it can still be relatively traceable if enough connections are made. If you are concerned about this risk, use your own node. There will always be privacy loss when using someone else's copy of the blockchain.

3. The height leak is very damaging for users attempting to churn. In that case they connect, sync, broadcast, disconnect, repeat. Every time they connect they are indicating approximately where they left off. This means when they broadcast again ... one only need to look at the tx to see if there is a ring member near where the wallet connected. If so, you have linked TX.

I argue that churning is absolutely outside the scope of users who are using remote nodes. It's extremely unlikely an advanced user who cares about their privacy will make a fundamental mistake in trusting someone else's node. This is outside the scope of protections. Just run your own node if your threat model even considers churning.

4. The wallet will ask to confirm transactions sometimes... AFTER it has send the ring to the remote node! If you cancel tx then try again, you have sent 2 rings to the remote node but in each ring the real input is the same. Congrats, tx linked or ownership of output now shown.

This was disclosed in HackerOne and has been patched.

5. Wallet and network does not support Tor. Despite using HTTP they do not have proxy support. On Linux they suggest hooking syscall to force proxy [torsocks]. On Windows they scorn users and tell them to use Linux. At the Monero network level only IP addresses are accepted meaning we cannot have Tor-to-Tor.

Little effort has gone into this since the support is being designed for I2P.

6. Tor is downplayed because they are writing-from-scratch a new I2P implementation in C++ named Kovri. Instead of using Tor today they provide no sort of IP hiding while everyone must wait for a new I2P impl. This is bad engineering and means few people can properly submit tx over Tor.

There are other considerations when submitting transactions over Tor. I'm not an expert here, but fluffypony has been critical of this approach in the past.

7. All TX are not the same. There is no solution to joining bad outputs. When you make a multi-in transaction you provide strong linkage if an attacker knows or suspects multiple outputs are yours. Example: you accept donations or are a darknet dealer. Attacker sends many small outputs to you. Attacker will know when you make a move because they will see a multi-input transaction containing one of their known outputs in each ring. This is useful for LE: send small money then know when money is moved. From that point trace forward and see if descendants of that TX end up at known exchange. Now you have a short list of suspects.

Each output is used in several transactions. While it does not completely mitigate the risk you describe, it means there is at least some plausible deniability in practice. If you are in a situation with a significant number of outputs, you definitely should not simply send a transaction with these to an exchange or similar.

8. A lot of metadata per TX. Each TX can have a payment ID [old style], payment ID [new style] or none. Each tx has a fee, and fee is one of 4 levels [0.25x, 1x, and 2 large x]. But the default is 1x. This encourages smart or big users to change from default to 0.25x to save money. But now their tx look different from common users. Exchanges in particular may do this.

There will always be some metadata, but based on how the system works, there will always need to have the fee. The multiplier is set to be more automatic in the latest version. The payment ID metadata has been improved to be encrypted, and to encourage use for all transactions with integrated addresses. Metadata for these two items is the least of our concerns since there is still a pretty large entropy set for normal situations, but of course there could be improvements.

9. Probably other things I am not thinking off of the top of my head.

Me too :) Key image reuse attacks seemed to come out of nowhere, and we needed to respond to them.

In short I think that Monero practical privacy for users that have something to hide [darknet] and may find themselves against a LEA might find themselves in a bad position. Compounding this is Monero's total refusal to warn users and provide self-sabotaging options. A Tor-style warning is absolutely required given the state of things. More paranoid people might think the lack of warning and some of these issues are intentional.

I disagree with your tone here. Here I am, a community member, agreeing with many of your criticisms. The idea of a better warning guide has been discussed for quite some time, and I believe it has been relatively strongly received. If you were to start a project on Taiga to get this started I'm sure many people would respect you.

The best summary I can say is this: Monero is a tool that can provide significant privacy under a variety of use-cases. If your use-case is hiding your wallet balance and transactions from merchants, ad agencies, and most attackers, you can use Monero with little to no significant consideration for your privacy. If you are worried about colluding KYC exchanges, governments, and motivated attempts to target you specifically by powerful attackers, then the use-case for Monero needs to be better-defined. Monero will preserve privacy under some situations better than others. Given that it is relatively hard to understand, Monero will need to use a mix of education and default/mandatory functionality to encourage the correct behavior.