Recent discussion on IRC about Joinmarket and it occurs to me that the issue of Wasabi using a server is both subtle and little understood. Even more confusing when you consider Joinmarket also uses servers, for messaging. I'll try to explain in a bit of detail and point out how this may be a material difference in the privacy model (although it's hard to state clearly): (1/n)

So, first off, let's be clear about the basic intent:
A. Wasabi: Chaumian CoinJoin server (CCJS), server cannot link inputs and outputs due to blinding, and cannot steal due to tx signatures. But server does construct the transaction to be signed.
B. Joinmarket - Taker is coordinator, servers for messaging are used as pipes, so utxos and transactions and signatures are passed end to end encrypted. We use multiple redundant IRC servers for this task to avoid possibility of censorship. (2/n)

Will not attempt a full discussion of pros and cons of models, but what I want to point out is the weakness in the CCJS model that exists exactly because the server is the transaction constructor. Often people (and academics included!) assume that because utxos are public information, there can be no harm in having some party "learn" them. But it's more subtle than that. Suppose a utxo is "of considerable interest" to LE agents. Suppose it gets pushed through a CCJS to delink it (3/n)

Now suppose said LE agents coerce the CCJS operator; they tell him to watch for this utxo, when it's queued for join, the server operator is forced/coerced to make fake counterparties for this utxo specifically and sybil this one specifically, so the guy thinks he has anon set but has none vs LE agents.

Not to say this wouldn't be quite tricky to arrange, but it's clearly possible.

You might counter that such type of Sybil is possible in Joinmarket, but it *is* different: (4/n)

... in that there is no server operator to coerce; the IRC servers have no idea which transactions are being coordinated. So you can try to Sybil joinmarket's whole market, but you're constantly racing against honest counterparties (who have an incentive to make coinjoin fees and privacy boost their own coins). Counterintuitively I suspect the deanon- sybil attack is the *least* weak aspect of Joinmarket's model, actually. Its real weakness is maker-taker asymmetry.


In summary, I believe this is a genuine weakness of the CCJS model, albeit it's practically hard (consider the red flags if 50 people turn up to do a coinjoin and all get rejected bar 1, or if there were suspiciously two coinjoins at once when only one was scheduled!), still it exists.

Joinmarket has other weaknesses (it's in a way just less ambitious), but, I argue, it *is* more decentralized.

Also finally don't forget coinshuffle++ which in a way is the best of both worlds. (6/6)

An afterthought: I suspect the example I gave here is not actually correct (consider if the server is required to publish all outputs before inputs are provided). I'll investigate further and think a bit more about it at some point - I guess this just illustrates my original point - it's subtle and complex! :)


Afterthought to the afterthought: according to what I see in ZeroLink/Wasabi docs, the original scenario is in fact correct, because the first stage is "input registration phase" in which the "Alices" give their utxos and proofs of ownership (and blinded outputs), so the coerced server could bifurcate its behaviour at this first phase.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!