Our contributors participated in Bitcoin Magazine’s Twitter Space on Toxic Change in CoinJoins based on this article by @thibm. The conversation compared the various solutions for dealing with toxic change across multiple coinjoin protocols.
There are three so-called privacy guarantees of Wasabi 2.0. One is that the more inputs there are, there is the likelihood that there’s gonna be multiple equal denominations. It gets higher and higher, and like Max said, when it gets to 150 inputs or 300 or something like that, it’s gonna be very, very likely, that there’s gonna be multiple equal amounts for all of the denominations. Now that is good. That provides us anon set. That is one privacy guarantee. Now, there’s also the fact that now in Wasabi, you cannot really know how many inputs this user has, how many outputs did he break the amount into. And you know, all of these kinds of nuances, it makes it really, really difficult to try to analyze Wasabi coinjoin transactions because there’s kind of this possibility of you breaking down your amounts in many different ways, so you don’t really know it. It’s kind of another way of making it difficult for any analyzer to figure out what really happened over here.
Now the third one, which is not really a guarantee, you know, it’s just a practical thing that we’ve noticed that it is very difficult to try to even create a probability table for a coinjoin transaction as large as Wasabi 2.0 coinjoin. If you have 300 inputs and 300 outputs, just trying to calculate some kind of a, you know, doing coinjoin Sudoku and trying to figure out which inputs could have gone or broken down into which outputs or consolidate into, you know, all of the possibilities.
That is just something that we have not with our hardware been able to even do.
Well K Y C P doesn’t either on large transactions, they just go “run it yourself” because it’s so computationally expensive.
Yep. So even if you have these amounts, as long as you are not the big whale and a lonely whale in Wasabi 2.0, coinjoin transaction, it is gonna be very crazy hard to figure out the input-input linkage, input-output linkage or output- output linkage.
Now in the Wasabi Wallet 2.0 coinjoins, there is a bunch of these so-called privacy guarantees. So we have the traditional anon set, but we have much more things on top of it.
I think when we want to focus on change in coinjoins, it’s important to look at the entire user journey and Rafe you just hinted it in some regards.What about post links? So the entire user journey is arbitrary amount input value. Maybe that’s not gonna be enough as the minimum denomination that the coordinator dictates in Whirlpool or Wasabi 1.0, for example. So then you have a problem and you’re excluded. And so you have to consolidate multiple input coins in the same joint transaction or TX zero transaction, which reveals common input ownership, at least to the coordinator with Wasabi 1.0 and to the entire blockchain with TX zero in Whirlpool, which isn’t great, right? But you’re now in the coinjoin. You get your private output amount of a standard denomination, but now you want to make a payment. And the big problem is, well, the payment, the merchant wants an arbitrary amount, and it’s very likely not that standard denomination that you have.
So you have to consolidate multiple inputs to make a payment. Also, you are gonna have to create a change output because the merchant’s payment output is, is not the value of your inputs. Then if the coordinator dictates certain input and output values in the coinjoin, this means that you cannot do the payment inside the coinjoin. Like for example, in Wasabi 1.0, no merchant wants to get exactly 0.1123, or something. In Whirlpool you couldn’t even collect multiple inputs, the coordinator says you can only have one input, and no merchant wants to get the exact pool denomination. So this means in Wasabi 1.0 and in Samourai, you would have to make single-user payment transactions, but single-user transactions are horrible because we reveal common input ownership. And so now if you need to consolidate multiple standard denomination coinjoin outputs in your single-user payment transaction, you just revealed common input ownership.
Then you have the merchant’s payment output and your change output. Well, now the merchant knows that this is your change output and an outside observer knows that this is the change output to a payment that was done by a coinjoin user, and then you will most likely want to get privacy back on that change output, right? It’s toxic after all. So you want to put it into a coinjoin. The problem is, The problem is, you just commissioned a payment with a standard denomination. So the change output is gonna be less than that, meaning you cannot go back into the same denomination coinjoin pool, right? Let’s say in Wasabi 1.0 you get a 0.1 output, you make a 0.03 payment and you get your 0.07 change. Well, the 0.07 change cannot be registered in the 0.1 pool, meaning you have to consolidate to get into the coinjoin again, and that sucks for privacy. The change output is such a huge problem, not just inside coinjoin, but also inside payments, which cannot be made inside the coinjoin, but because of the entire idea of trying to prevent change. But here is where Wasabi 2.0 really comes in to shine.
It just shows the incredible benefit of having arbitrary amount coinjoins. You can come in with any amount that you just put through from an exchange or whatnot and get only private outputs on the output side, and now you have a multitude of different standard denominations in your wallet after a couple rounds of coinjoin. And now if you want to make a single-user payment transaction, you can combine these standard denominations very efficiently to reach any arbitrary payment output value with only a handful of inputs.
These standard denominations are good for decomposing, like breaking down a certain large amount into many smaller amounts, but they’re equally as efficient in taking a bunch of small amounts and adding them up to a precise large amount. So with very few inputs, you can make any value payment, but still, let’s assume that you still get a change output back. Well, the change output is gonna be lower than the standard denomination on your input side. But in 2.0 it doesn’t matter because you can register as low as 5,000 satoshis on the input side, regardless of what amount it is. So a payment change output can directly be registered in the coinjoin and it can be registered together with private outputs that you have. So you can combine one or two non-private change outputs together with three or four private coinjoin outputs, which means now even though one or two coins of yours are revealed on the input side, all of your other coins that you have on the input side are private. And so, even an outside observer who might know that this specific change coin belongs to you, does not know which other inputs you have and therefore the value of the inputs that you have. And if you don’t know the value of the inputs that you have, it’s gonna be even more difficult to find out which output values do you actually have.
Ultimately with 2.0, we have a much smoother user experience that is faster and especially cheaper and more private.You can get any arbitrary input value, and even after making a payment, you can register the change without any issue in the next coinjoin.
Just to kind of explain a little bit of what is anon score.
Imagine that you have a coinjoin round where you have one of the outputs of one Bitcoin and there are nine other outputs that are also one Bitcoin. Normally we would consider that this, your coin has anon set of 10. The thing is, we could previously say that with all of the three old implementations, because we had this idea that the user will have only one of those equal denomination outputs. That was the guarantee that enabled all of these implementations to somewhat of at least use anon set as an estimation of how private did their output get. There is nine other outputs that are equal amount, and each of the outputs are owned by different people. Now with 2.0, that is not true anymore.
So there can be that you might have, let’s say two of those, one Bitcoin outputs instead of just one. What would be then your anon set? Well, it is again, for each of the outputs that we have, like this one bitcoin output, the anon set is 10. But because we cannot know, if all of the other eight outputs are also coming from different people, we have to be conservative.
So there is certain calculation of how anon score is a conservative version of anon set. Instead of you having one of those one Bitcoin outputs, we don’t give an anon set of 10. We give, let’s say, as an example, an anon score of 4. Because we assume that multiple of these outputs might be actually from the same user, not all from different individuals.
That is kind of like anon score. So whenever, like we have in the wallet now ‘Anon Score Targets’, when the user starts a wallet, he has to choose from different profiles. And those profiles have a certain amount of Anon score that they are targeting. And automatically, whenever the conjoin rounds succeed in a way that they actually do get this traditional anon set, we make a conservative calculation from that and then we show it for the user that, hey, you got privacy. So we are not even calculating or counting into our privacy calculation the fact that it’s computationally just hard to figure out all the possibilities of how the linkages could go in this coinjoin. We are not counting on this being able to break down the amounts into multiple different ways.
We are being ultimately very, very conservative. Even more conservative with the anon set in the calculation of privacy.
Check out the full recording, if you haven’t already: https://youtu.be/Zu-bT9XojYk
