UPDATE: See also this podcast
where I speak with Monero dev ArcticMine about this stuff.
UPDATE 2: Seems that some people are misrepresenting what I wrote
here and using it to shill various coins, read memo #7
for more details.
Recently some information became public about a Monero vulnerability, at first called the "Rucknium Ratio Attack" and now called the Maximum A Postieri (MAP) Decoder attack. The "fix" and proposed solution is called OSPEAD.
The TLDR is that Monero privacy (what I call Where's Waldo Privacy) hides your "real" (Waldo) data next to 15 other "decoys" (the crowd). But according to Rucknium's research, using standard statistics methods can reduce this privacy to hiding in a crowd of (on average) 4.2 instead of 16. We thought Monero had a certain level of privacy but it turns out to have about 75% less privacy than we thought.
Monero still has drastically better privacy than using Bitcoin, so there is that. First I will give actionable advice for Monero users in the next section and then after that we will dive into technical details that will probably only interest cypherpunk weirdos and cryptocoin devs.
Read this section if all you care about is how to improve your privacy while using Monero, taking into account this now publicly known reduction in privacy.
Should you churn? Churning just means sending funds to yourself, often the entire wallet balance. The unfortunate answer is that churning doesn't magically solve the problem, and it is possible that churning hurts your privacy or does nothing and wastes money on fees. My advice is to not churn unless you feel that you know exactly why you are doing what you are doing.
Instead of churning, use two wallets, one for incoming funds and one for sending funds out, which we will call Incoming and Outgoing. This could even be inside a single application, because many Monero wallets support having multiple named wallets (essentially a bucket of funds) inside the same GUI. I will explain why this increases your privacy soon, but for those that just want the actionable advice, here are your rules:
NOTE: If your wallet only gives you a single address (starting with 4...) and you can't make stealth addresses, stop using it because it sucks.
That's it. Four rules to increase your Monero privacy. We could even condense it down to a single rule "use two wallets, one for incoming and one for outgoing and always give out a different address to different entities" but four simple rules seems easier for most non-experts to follow. Yes it's more annoying, but privacy ain't free. Privacy requires knowledge and work in the modern surveillance culture in which we live. If you only care about the how and not the why, you can stop reading now and go enjoy life. Make sure to be thankful there are weirdos like Rucknium and many others that spend ridiculous amounts of time working on privacy tech so we can try to avoid a dystopian panopticon future.
And if you want or need one little bit of inspirational happiness before closing this tab, think on this: By using two wallets you are actually increasing your privacy to be more than what we thought it was before this attack, because 4.2 times 4.2 is 17.64, which is bigger than 16. Yay.
The main reason is that we are adding a hop in the transaction graph between any incoming transactions and outgoing transactions. This not only helps your privacy against the MAP Decoder Attack but in various different attacks against Monero. The biggest problem is not that this new attack is amazingly bad but that it pairs well with various other attacks. Just the MAP Decoder Attack by itself can tell you the real spend 23.5% of the time, which isn't great. But when you also use it in tandem with an EAE (Poisoned outputs) attack, or a flooding attack or various others, it will sometimes be possible identify the real spend with very high probability.
Let's give a concrete example of how using two wallets increases privacy. Bob buys XMR from an exchange, withdraws it to his own wallet, then later on sends it back to this exchange, with a different account. Or it could be a different exchange which colludes and shares information with the first. For this simple example we will assume it is one exchange. With a ring size of 16, the exchange can see there is a 1 in 16 (6.25%) chance that the funds it received from Bob's second account are the same that they sent Bob originally in the first account. But now we know because of the MAP Decoder attack, it is really a 1 in 4.2 chance (23.5%) that these two accounts are the same. If Bob instead uses the "two wallet dance" described above, he would have put another hop in the transaction graph and the exchange would then see a 1 in (4.2*4.2) = 5.7% chance these accounts are the same. Bob ends up with slightly better privacy by using two wallets than we thought he originally had before the MAP Decoder Attack was made public.
Now let's make the situation worse for Bob and say that there is an active Flooding Attack on the network during the times he makes trasactions. This means the attacker is making many outputs or the majority of outputs, which means many of these outputs will be chosen as decoys but known to the attacker, which means they can rule them out of transactions as potential real spends. Rucknium stated in October 2024 that "mean effective ring size has decreased from 16 to 5.5" during the ongoing attack at that time. Also, that some transactions had an effective ring size of 1, which means the real spend can be identified with certainty. Even if it is only 1% of transactions that have an effective ring size of 1, it sure does suck if they are yours.
What is the chance that the 2024 Monero Flooding attacker knew about the MAP Decoder Attack and used both methods together? Even if they didn't know about it at the time and just learned about it, they can correlate their flooding data and re-analyze it along with the MAP Decoder Attack. If just flooding decreases ring size from 16 to 5.5 and just MAP Decoder Attack decreases it from 16 to 4.2, what is the effective ring size when both are used? It seems very possible that using both together reduces the effective ring size to a number between 1 and 2. For instance if the flooding attacker can rule out 10.5 inputs on average from an arbitrary tx (leaving 5.5 inputs, one of which is the real spend) and then use MAP Decoder on these remaining 5.5, reducing this ring to 23.5% of it's original size, that is an effective ring size of 1.3 . That is like Waldo hiding in a crowd consisting of himself and 1/3 of another person. Not great.
The real fix for this attack is to throw away ring signatures via Full Chain Membership Proofs (FCMPs) and thankfully that process is well under way. Unfortunately it seems that right now it is unknown when they will be ready to activate on mainnet. Right now it looks like one to two years before that is going to happen, so something needs to be done in the mean-time.
What I hope to see in the near future is OSPEAD implemented and activated in the next hardfork along with an increase in ring size somewhere in the 32 to 64 range. Yes it will increase blockchain bloat and take longer to validate these transactions, but it is worth it. Both of these combined will hopefully bring Monero back to the privacy we previously thought it had and also takes pressure off of those working on FCMPs to try to get it out the door as fast as possible, which means less testing and a higher likelihood of bugs.
-- Duke