| Monero has some real issues! These papers are OK but I am not sure if they focus on current practical issues: 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. Users cannot just increase their ringsize. Doing so makes their transactions stick out: different metadata. If you always use, example, ringsize 21: then your tx look different on-blockchain. Despite this, BOTH wallets in common use have features that encourage users to make this mistake. It is like sabotage. The official GUI provides a slider that goes to 26 and says more privacy [you see a good number of of ringsize 26 tx]. The 'official' Web Wallet run by the Monero lead offers a 4-setting: 5 [default], 11 21 & 41. You see a good number of 11 21 41 ringsize tx because of this. It has been known for a long time that picking and forcing one ringsize is a good idea yet both wallets insist on encouraging the user to mess up. Not good. No warnings in the wallet, either. We need higher ringsize because the privacy of your transaction going forward depends on other users picking your output as a decoy in their own rings. Now the small ringsize is made worse by the fact that a single entity, ShapeShift.io, runs 7-15% at least of the network by tx volume! That means with one hack or warrant an attacker will be able to eliminate many fake decoys from other tx rings! How much will a few other exchanges or payment processors make up of the network? 50%? More? Despite this the ringsize stays very small. 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. That is the core issue. Other issues: 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. 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. 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. 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. 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. 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. 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. 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. 9. Probably other things I am not thinking off of the top of my head. 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. Edit: I still support Monero and think it is the best project. Despite ZCash looking better on paper the team makes me nervous and I avoid it. [Their wallet software is even worse despite them having many millions to fix it] ... I just want Monero stronger as it will help our users overall and that is good for my business. |
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.