Coinjoin attack vectors and mitigation
Full technical examination about Coinjoin, threat models, attacks and mitigation.
I was getting more and more questions about Coinjoin and I spoke about this with Giacomo Zucco who made considerations about this. We then decided to prepare this article about attack vectors on Coinjoin and possible mitigations.
This is an advanced article, so we do not explain here what is a Coinjoin. There are easier articles about this topic. Now we are focusing on Coinjoin techniques, and possible attacks.
The threat models
You have to separate the threat model of some external actor knowing or suspecting you are participating in a Coinjoin from an external actor being able to undo the Coinjoin and actually track you as before the Coinjoin.
External actor knowing your are participating in CJ
The first one is a very hard problem because right now most implementations are pretty trivial to recognize. So it's easy. So for example, you buy Bitcoin KYC, then you Coinjoin and then the exchange will ban your account because they've seen you have Coinjoined.
Or the other way around, you Coinjoin, then you want to sell, but they will detect that you Coinjoined before. So in itself, this is not resolvable but there are some ways to disguise a little bit the Coinjoin. There will be many more plausible liability ways after Lightning integrations and Payjoin integrations. So the more we advance with stuff, the easier it will get to deny that something is a Coinjoin. But the real problem is that even if we prevent services from blacklisting Coinjoins, we cannot prevent them from whitelisting non-Coinjoins.
So if you just ban any transaction that is not obviously anon-Coinjoins, that's basically not easy to counteract. There are few mitigations to this kind of attack.
Mitigation (cultural)
One mitigation is basically cultural and economical. And I think we should promote as a culture that any service that will ban Coinjoin will restrict the use of previous Coinjoin in previous transactions. It's not a service accepting Bitcoin, because Bitcoin as a protocol tells you that if a transaction is done in such a way, that's a valid transaction. You can still refuse from dealing with somebody because you don't want them as a client or as a provider, but you cannot say that you are not being paid. That would be fraudulent. Just saying that you received some gold and you decided that the client didn't give you gold because you don't like the kind of picture there is on the gold coin. That's juridically invalid.
You can say that you don't accept gold in your contract. You only accept some specific kind of gold coin with some pictures. So I think we should all be very hard on changes that are making this distinction. Of course, they're making it because they're scared to get their bank account closed, but I don't care. We should lobby hard that whoever is adding this kind of caveat on top, basically is not using the Bitcoin protocol, is not accepting Bitcoin payment. They are accepting another kind of payment, which is an arbitrary subset of Bitcoin transaction, basically based on some arbitrary heuristic.
Right now, this kind of cultural mitigation, don't worry, we'll get into more technical stuff later below.
This kind of mitigation seems unrealistic, I realize it, but I think it will get better and better and better, because after they will completely ban Coinjoins, they will have to ban other kind of stuff.
Mitigation (technical)
For example, another mitigation is that you can make a few steps:
So you can pay to yourself on-chain one time with a normal change, so it's not suspect. You do it one time, two times, three times, so on and so on. You get to 7-8 and then you pay to the exchange. The exchange will not block you. But then people will just learn to do on-chain steps in order to avoid this kind of blocks, both in deposit and withdrawal.
So the exchanges will need to block any transaction that has a history of Coinjoin before or after or even very far. And in that case, even users that never use Coinjoin will actually be banned from exchanges. Then people will realize that Lightning is better than a Coinjoin from a privacy point of view, especially after we evolve a little bit. And so they will start to use Lightning, but then the exchange will be forced to ban Lightning as well. And I think that's inevitable.
Lightning gives us exactly the same level of privacy of Coinjoin, but better if we go in, I mean, not right now, but as a trend, absolutely.
So when Coinjoin (right now that just some Coinjoin transactions very close to the deposit or very close to the withdrawal) are banned, it's possible for exchange to keep this discrimination on. But eventually that will just become closer and closer to banning Bitcoin at all. So it will be easier to show that if you accept Bitcoin, you have to ignore regulation and you have to basically do it recklessly and accept any kind of Bitcoin. Otherwise you just stop accepting Bitcoin. I think that will become a clear trend. This is the first threat model. This is the more like social. The second one identifying, so like undoing your Coinjoin is a more technical one.
Making CJ useless
So about undoing Coinjoins. So basically understanding, making your Coinjoin useless. There are two main kind of attackers (+1 which is a mix).
Attacker is the external passive attacker looking on the blockchain.
The active centralized attacker, which is the Coinjoin provider in case of Wasabi or Samourai.
This one is a mix of previous two. It's a Sybil attack. It's probably closer to the second.
Passive attacker looking at the blockchain
So from the public passive observer point of view, the risks, the weak points of Coinjoin are basically one, the fact that amount correlation is non-trivial. So basically, there is the fact that even if there is, in theory, perfect fungibility between each input and each output, the reality is that if you assume that there is no transfer of money, no complex transfer of money, then what you know is that basically this is a Coinjoin.
Amount correlation
So people getting in are X entities and people getting out are X entities. And there is a fee to the Coinjoin coordinator and everything else is basically the same. If you make this assumption, you can probabilistically, of course, de-anonymize a lot of stuff. Of course, that doesn't mean that you have any certainty. But for example, if you want to protect from any investigation, so you need also to eliminate clues, not just certainties, then you don't want amount correlation.
In Joinmarket, the taker, so the coordinator, the peer that initiated the transaction, he basically selects the amount he needs and then asks to all the makers (the liquidity providers), to just match his amount.
So you decide what you have to do. Like you spend these UTXOs and you create two UTXOs. One to your payment destination, for example, and one to yourself as a change. Then you will ask to all the makers, so the liquidity providers, in exchange for a fee, you will ask them to match your amounts in both regards. So you will not have any leak of amount correlation.
Instead, in Samourai, Whirlpool, they break yours: basically you choose a pool, which is a denomination. They will break your UTXOs into a specific denomination in an initial transaction called TX0, and then they will stay in the same denomination, so there is no amount correlation. There is a lot of lying by Samourai about the characteristic of this T0. Actually, there is no need to make this stuff in an additional transaction. The reason they do that is for business model only. So they use the TX0 to collect the fee and to identify the users, and then when they start conjoining, they will let you remix for free, which is a good thing for another kind of attack vector that I will tell you later.
So there is this kind of TX0 where they split into a denomination and then they go. This creates a problem that is not present in Joinmarket model, which is toxic change, so toxic change that doxxes you. Basically, if you have some UTXOs, all the UTXO that doesn't really match an integer number of times the pool denomination will give you a change.
You will keep this change, you cannot spend it in a conjoin because it's too small. So eventually you will spend it outside of a Conjoin, and maybe you will spend it with one of your resulting private UTXOs. So you may Conjoin for months, and then one of your final UTXOs, you will merge it with your initial change, the spare change, in order to spend, and now everybody will correlate your entry point with your exit point, and you can do a lot of heuristics in between, so that's kind of bad.
Wasabi also had this problem. Wasabi didn't manage this problem very well, a lot of doxx change attacks in Wasabi, while Samourai managed it, Whirlpool managed it better. Joinmarket doesn't have this problem at all.
When you actually move from Wasabi 1.0 to Wasabi 2.0, there is a new thing, which is called Wabisabi. Wabisabi is basically very complex very difficult to understand.
Basically, it's a statistical study on the way you could, instead of just making equal amount, which is what basically Wasabi did, and what Whirlpool does, and what Joinmarket also does in a different way, instead you can allow way more complex combinations that are still provably not correlation prone.
So you can, instead of just say, enter, everybody has to put 3 and get 3, minus fee, and as you have the toxic change problem, unless you are in Joinmarket, you allow for a wider range of combinations that will still be statistically unrelatable, because they are too complex: there are too many ways to put them.
So basically, Wasabi 2.0 expands the level of combination you can have with the same statistical deniability, and allows you to get rid of the toxic change, and to get rid of the problem of fixed denomination, which is kind of bad.
A Wasabi 2.0 Coinjoin it’s like a magical statistical black box.
If you make stuff which is complex enough, it makes sense that you can get to some level of amount complexity where you cannot really reconstruct anything anymore.
And you solve, you mitigate the toxic change problem as well. It's worth to mention that the toxic change can also be flagged not to be spent anymore, that's a solution. You can swap it, using CoinSwap on Bitcoin, or you can swap it with Lightning for example, you can use it to open Lightning channel, then you use it alone, you don't merge it with anything else, and then only when you close it somebody will see.
So you can do many things. Or you can move it on-chain a few times, you can do many things. Usually it's small, so it's not very practical to do stuff with it.
But still, that's also a problem that self-solves, right, because right now the change, the toxic change is small, so you just don't move it, then you wait 3 cycles, you wait 12 years, and now it's a significant amount of money, and you can spend it all alone without merging.
So it's a relative problem in my opinion.
Whirlpool, Samourai, since they started to pander mostly to the Monero community, they implemented a Monero atomic swap.
So when you have the toxic change, you swap it with Monero, which doesn't make any sense because the same technology can be used to swap it with another Bitcoin UTXO as well.
So it's really just shitcoining, there's no technical reason. There is no way an atomic swap with Monero is simpler to implement, or faster, or more effective as anonset, than a Bitcoin to Bitcoin swap that will have exactly the same effect.
Anonset elimination
Another public correlation is due to Anonset elimination.
So basically, you have, for example, 100 people together in a conjoin in Wasabi, and they make one Conjoin round, and they think they have an Anonimity set of 100.
But then 80 of them don't follow best privacy practices. So you think you have an Anonimity set of 100, but actually now you have an Anon set of 20, because 80 of the people there, they re-consolidated after the mix.
Many people do that. A lot of users, especially Wasabi users, unfortunately, they Conjoin a lot. Then they take all the UTXOs and they send it to the same address in cold storage in one transaction. Or they split it, but there are strong time correlations and stuff like that. So that's the other possible attack vectors there.
Not only people can make post-mix mistake, which is a re-consolidation or stuff like that, or timing correlation, but other people making mistakes can reduce your actual Anon set.
The way to mitigate this is basically in Whirlpool, they decided that you only pay the TX0, and then you will get selected for remixes after the first time. So that means that people are incentivized to stay to avoid paying a fee twice. So a lot of people that are with you in the first conjoin will also be with you in the second and the third.
That's good, because in this case, the Anon set doesn't sum, but it multiplies. So if you have one Anon set of 100, maybe it will become of 80 very soon. But if you have an Anon set of 5, which is the typical official Whirlpool Anonset, then you do every time people remixes, you will have 5x5x5, and in a very few hours or days, you get a more solid Anon set.
Wasabi didn't used to do this. It was one of the fair criticisms by Samourai.
They used to make you pay for an Anon set for every mix, so people almost never remixed. Now they give you free remixes as well, so they basically incorporated the feedback, even if it was not a very gentle feedback.
In Joinmarket, if you are a taker, you will not remix, you pay just once. But all the people that are giving you liquidity, the maker, they stay online, and not only they don't pay for mixing, but they get paid for mixing.
What they lose is that they don't decide when, you just wait and you will get selected eventually. But you don't pay, you get paid, a small amount, but you get paid.
So there is an incentive to remix in Joinmarket, even better than the one in Whirlpool.
When you enter an Anon set of 8 in Joinmarket, you know that the other 7 are makers, so most of the cases they will remix, by definition. So it's probably the best case.
Then there is the possibility of a centralized non-public active attacker that will then de-anonimize you, this is mostly a problem for Samourai. In Whirlpool, if you use the Samourai app as default, it will connect to their server, it will tell the server your IP, if (you don't select the Tor flag), it will also give the IP to the server and all the UTXOs. So all the Magic, Chaumian Blindness, it's all fake in default Samourai, it will give them all the information.
The problem is that if you install Dojo, which is like an incompatible Electrum server, (but very few people do that), or if you use Sparrow with Whirlpool, then you are safe from this attack, but the problem is that Samourai, Whirlpool, Anonymity set is usually 5, they match you with 4 entities, with 4 UTXO. If more than 1 quarter of people using Whirlpool in this moment are using default Samurai app without Dojo, which was very realistic, at least some time ago, then basically the Samourai server can easily take any non-default user, so any private user, (using Dojo or Sparrow) and put you with 4 default non-Sparrow, non-Dojo users; so your Anonymity set will be 0 to them, or 1, because basically what they do is they can take any non-doxed users and put it with 4 doxed users.
Right now I think this objection doesn't hold anymore, because especially in the remixes, in every round of Whirlpool there are a few people coming in and a few people remixing, basically it's 2 vs 3, so there are 3 remixers, remixing on cell phone, keeping your cell phone on with the Samourai app on, waiting for remixes is impractical, while keeping your Sparrow wallet on desktop on is way better, it's easier, so I think that most people remixing right now on Whirlpool are not using Samourai from mobile, instead they are using Sparrow, so they are not leaking the keys. So I think that right now if you pay for an anonset of 5 for a round in Sparrow, probably you don't get 5 but I think it's unlikely right now that the server of Samourai can match every single non-doxxed user with 4 doxxed users. It becomes harder with the spreading of Sparrow as an alternative.
So right now using Sparrow plus Whirlpool is still bad ethically, because you give money to Samourai team, and you get a lower Anonset than declared, but it's probably not that bad.
Then Wasabi doesn't have this attack surface, you have different Tor circuits, so the only possibility for Wasabi to deanonimize you if there are some vulnerabilities in the implementation or in the David Chaum original cryptography assumptions.
So if a Chaumian blinding is broken, ok, they can attack you, if Tor is broken they can probably attack you, if Wasabi implementation of Chaumian on Conjoined is broken, just as implementation they can attack you.
But it's different, if everything works as we think it works, there's no attack surface there, like in Whirlpool it's way worse in this sense.
Of course in Joinmarket there is no such problem, there is no central, you are the coordinator when you are the taker, of course if you are the maker, your taker knows who you are, but that's ok, because the security model of Joinmarket when you are a taker is very strong, you are the coordinator.
When you are a maker, it's weaker, because you will have toxic changes, and you will also have the problem that the coordinator, the taker knows who you are, in the sense of knows your UTXOs, but the model there is that if you are a maker, you wait, you get involved in many, many different rounds, and eventually, slowly, you build your anon set slower than the taker, but every time the taker is different, so basically you will end up building your anon set and being paid for your Anon set, which is good.
Sybil Attacks
The last thing is basically Sibyl attacks. I told you a weak variant of Sibyl attack, which is Whirlpool server matching you with users that are already doxed, that's ideal, because that's a zero-cost Sibyl attack by Whirlpool, so it's more likely, but even if everybody was using Sparrow, nothing prevents Whirlpool from putting you with four fake conjoin users, and you will not know, so they could de-anonymize every single user, always, but that's the same for Wasabi. The Wasabi ZKSNACK server, even with Chaumian Magic, they could, for every single request via Tor to mix with 70 people, they could create 69 fake users with liquidity to mix with each one, so they could de-anonymize everybody.
This is possible, here the mitigation here is economical: if a nation state is paying Whirlpool or Wasabi to do this, they may be doing this, and de-anonymize, I mean, unmixing every single mix since the beginning.
For Wasabi it would be very expensive, but still, well, there is a lot of discussion to have here; Wasabi uses very big unknown sets, so it's expensive to Sibyl attack for them, but they get paid for every round, so basically, if I take you, you will pay me a lot, so I will have to deploy a lot of liquidity to Sibyl attack you, but you will pay me more for more anon set.
So in a way, it could be easier on Wasabi to do this. On Whirlpool, it's economically, with the Whirlpool model, with the fixed round, with the remix incentive, is less advantageous, it's more expensive for Whirlpool to attack you, assuming that everybody runs Dojo or Sparrow, but that's not the truth, so probably the truth is that it's more expensive in Wasabi, but that's debatable.
In Joinmarket, that's way worse, because in Joinmarket, originally, the Sibyl attack, so the central company cannot attack you because it doesn't exist, but a random external party could basically corner the market of makers, so you see that in the natural level there are like 100 makers, so you just deploy some liquidity, you create another 900, so now you have 90% of the makers, so you can probably de-anominize everybody in joint market and nobody will know, and you can do that more privately within the company, so you don't even have to do a conspiracy, you can do it single-handedly.
So not only you will not lose money to do that, because Whirlpool will lose money, some money, Wasabi will lose money, more money, so there is disincentive. If you are a joint market attacker, not only you don't lose money, you make money as an attacker. So Sibyl attack is more serious in Joinmarket than the others.
The way they decided to try to mitigate it is the fidelity bond, which is basically a proof of stake. So you freeze some bitcoins for some amount of time, and in this transaction basically you prove that you as a maker did that. The score that you get, the fidelity bond that you get, is proportional to the second power of the amount and the third power of time, something like that.
That means that it's inconvenient for you if you have two bitcoins, it's very inconvenient for you to split it and to create two entities with one bitcoin each, because you will receive way lower fidelity bond, so a score which is way lower. It's more convenient for you to basically unify all your fidelity bonds together. So this should work as a Sibyl prevention.
It's still unclear, it adds a lot of complexity for the maker, and it's a little bit unclear how it works, how well it works. Interestingly enough, this is a case of proof of stake that works, because in this case there is no other typical circularity of proof of stake. In proof of stake usually you use a stake to determine the history, and then you use the history to determine the stake.
In Joinmarket you have a working proof of stake, because you use proof of work to determine the history, and the history to determine your trust-ability as a maker. So I think I gave you the overall.
Worst scenario on CJ
One last thing to say is the case when you mix it, and now you have a problem because your counterparty doesn't want your mixed coins. In worst case scenario you can always show which one were you in any round, using your private keys and signing.
So you can always, if you keep your wallet. If you want to sell and the exchange refuses because you conjoined.
So you may say: we conjoined because of personal security reason, because otherwise you leave your all financial information open to be accessed by random parties on the internet, with risk of kidnapping and stuff like that.
So you cannot ask us not to take security measures, but what we can do is to sign messages with every key from the origin of the funds until now, and this way you can undo the Coinjoin yourself.
So this is always possible, and this is an answer to the FUD, you should not Conjoin otherwise you end up with an Iranian terrorist. No, you can easily prove, and that always worked with exchanges.
We never ended up in court, it was always like a technical opinion that always worked to unfreeze the funds.
But finally, if Kraken (for example) doesn't want your money because of this, Kraken is not a Bitcoin exchange.
It's an exchange that is not accepting Bitcoin as deposit, but only a strange parallel protocol which uses as oracle the Bitcoin protocol plus another centralized protocol which is channelized as a score, like a risk score. So it's another payment protocol, it's not Bitcoin anymore, which is my, I know that now it's very lonely, but I think it will become easier to push with this narrative the more censorship advances.