This is an unathorized and not solicited response to the short, but rather strong, tweets from @nothingmuch about the very-soon-comming Wasabi Wallet 2.0 release.
I feel the need to write here because @nothingmuch is the father of WabiSabi, the cryptographic protocol that makes Wasabi Wallet 2.0 new unequal-value outputs transactions possible, as well as the mind behind some critical components needed by the coinjoin implementation, and because, even though it could result in redundant to say, he's talented and a real expert in the field. Also, and this is the most important reason, i think, it's that even when it is evident he is not on good terms with the team, he is being honest in his concerns and then i cannot simply ignore what he says.
First, in my opinion tweets are good for saying what you want to say but are not very good for explaining reasons, context, tradeoffs, and things like that.
Let's start from the beginning:
if your threat model includes making or receiving payments that must not be linkable with other payments under any circumstances, there's a good chance they will be linked on the input side by auto coinjoin, with no recourse.
This is true. Basically, the point here is that the wallet has no way to know that two coins should never be registered in the same coinjoin together. Unlike Wasabi Wallet version 1, the UI doesn't have any mechanism for providing that information from the user because it doesn't have a manual coin selection.
@nothingmuch believes automatic coins selection is a problem, but I think users manually selecting coins is also a problem. It is just a different type of problem.
Wasabi Wallet 2.0 main idea is to make coinjoins transparent for users, so everybody can participate without needing to understand what an UTXO is. Reintroducing manual coins selection here would be an step backward.
Anyway, users will expect a solution to this, and my recommendation is: if you have two wives, you should create two wallets to keep the money and the transaction history completely isolated.
in other words although in principle the toxic change problem is no longer inherent to the protocol, and the client could have eliminated it, it chooses not to for no discernible reason.
I agree with @nothingmuch here and my opinion regarding this point is very-well known in the team. Clearly, I cannot defend it from my personal point of view but I have lawyers in my family so, let me try:
We know[^1][^2] that any number can be broken into a set of n smaller standard denominations when n is 8, tolerance is 100sats and no output is less than 512sats. However, the chances of finding valid decompositions decrease while we do n smaller. This means that if we want to create fewer outputs (to make the coinjoin cheaper for the users), it could happen that there is no possible decomposition without assuming extra loses. Just a simplistic example for normal users: you have to break 18 using these denominations {10, 5, 2, 1} but you can use no more than three of them. Now try with only two of them only.
[^2] Simulations for different denominations (@nuthingmuch's jupyter notebook) for a deep dive.
the claimed "orders of magnitude" (i.e. at least 100x) more efficient transactions is dubious at best given the tendency for fragmentation. to mitigate this, various ad-hoc rules have been added to fudge things.
This is obviously a sales speech and not a hard-technical metric. In fact, i doubt people know how to measure "transaction efficiency". Any number, 100x or 36.4x is equally inaccurate because it doesn't try to be accurate in first place, it just tries to say: the new coinjoin transactions are a lot better (still not clear) because they are much cheaper, allow you to
participate with much more money, get a desired anonscore in less time, reduce the inputs-to-inputs linkeability and so on.
multiple perverse incentives are also provided. for example, you can just modify the client to never pay any coordination fees. (sic)
I don't agree. What kind of perverse incentive is that? Well, if that is true, then the incentive is for people to modify the client. That would mean many things, but perverse not by sure.
(sic) if transactions are full, users race each other to register their last inputs, an incentive for yet more temporal privacy leaks on input side.
I not sure to understand this point. I think that "transactions are full" refers to the situation when the number of registered inputs is equal to the maximum allowed number of inputs, in that case i am not 100% sure but i think @nothingmuch is right. I mean, even in that scenario Wasabi Wallet 2.0 is far superior in that regard to Wasabi Wallet 1 because in version one all the inputs for a given client were registered together using a single request. Can this be improved? Yes, I think so.
temporal fingerprints are not taken into consideration, though several exist even without assuming an adverserial coordinator.
WabiSabi is a much more complex protocol and it requires to take care of many details that simpler protocols don't, especially considering an adversarial coordinator.
Basically we don't want to let the coordinator to guess input-to-input links, output-to-output links or input-to-output links. In the first case, we have distributed the input registration requests along the available time before timeout, the same is done for ready to sign and signing requests (actions performed under alices identities). For output-to-output link we don't have that, and it would be good to reintroduce that mechanism.
The fact that we have lots (hundreds in our tests on mainnet) of credential reissuance requests followed by hundreads of output registration requests all in a very short period of time over the network that inherently introduces some delays can make a time analysis pretty hard and unreliable but not impossible (imo).
the protocol is basically unfinished, containing numerous vectors for performing targeted attacks on specific coins with deniability or completely covertly.
I'm pretty sure this makes reference to the previous points. Even if that's not the case it is not specific so, it is impossible to give a response to it.
I am sure there are many many more topics that we can agree and disagree about because the nature of the system is not trivial. However, I hope to have given the readers some extra context that is impossible to express in tweeter.
https://twitter.com/mHaGqnOACyFm0h5/status/1536598718371311616