Multiverse 2.357

Bitcoin is hitting new all-time highs, and lots of people are suddenly interested. When they start asking general questions, I either explain what I can or point them to an “Intro to Bitcoin” podcast I did. Some questions require more elaborate answers – one of those topics is Coinjoin.

Coinjoin is an idea that goes way back, to at least 2014. The basic idea is to combine transaction inputs and outputs in order to obscure the source of those transactions. So instead of n number of users creating separate transactions, all n inputs and outputs are combined into a single transaction. If you look at the transaction detail, you’ll see a transaction where one input is no longer associated with a one set of inputs and outputs. Now those inputs are associated with the true outputs only with a certain probability.

Coinjoin was implemented as a service historically, but this is risky, since users need to extend trust to that service. The operators of that service can steal the Bitcoin. Hence the appeal of implementing this feature in wallet software, but that comes with its own set of challenges.

It should be obvious how conjoins can help hide a user’s activity. For example, consider a user who wants to send 1 BTC to an opposition candidate for office in an authoritarian state, which entails risk for the user. Using conjoin provides that user with plausible deniability.

Now suppose that same user spends 1 BTC in a conjoin transaction with nine other users. What can be deduced from observing the transaction detail on the blockchain? This user sent 1 BTC to the first transaction recipient with a probability of 0.1, and an observer knows that there is a probability of .1 that they sent 1 BTC to the second recipient, and so on.

What’s not to like?

Sounds great, right? Well, not so fast. There are drawbacks too, some related to conjoin itself, some related to wallet software, and still other concerns related to the Bitcoin protocol itself.

The most obvious concern is something called a Sybil attack. Suppose we have the same transaction example from before, only this time an adversary provides five of the ten inputs. Now the likelihood that a given output is linked to that user’s inputs is 20% instead of 10%.

Another set of concerns involves managing the UTXOs used as inputs and outputs. Using multiple UTXOs as inputs to a single transaction links them together. So one way a user could lose the benefit of conjoin is to reuse a conjoin output along with unrelated UTXOs to reach a certain amount required by the conjoin. It’s desirable for a conjoin transaction to only use inputs of a specific amount, like 1 BTC. That’s because the outputs also need to be the same amount in order to not stand out. Even re-using a conjoin output in a subsequent conjoin means associating the other inputs with the previous conjoin outputs. The whole purpose was to break associations like this.

There is another set of concerns related to the wallet software used to construct these conjoin transactions. The principal issue is that different wallet software will implement coinjoins differently, giving away information about the user as a side effect. There was a case last year where a wallet was using predictable fees, which narrows down the possible users to those using a specific wallet software. There could be other subtleties like that involving timing, the ordering of outputs, handling of change, or the variety of amounts used in coinjoins that distinguish one wallet software from another or reduce the possibilities for determining which user was involved in a mix.

The bottom line is that coinjoin is just a shell game, and a considerably weaker version of it than the modified ring signatures that Monero uses, let alone than strategies other privacy coins use such as ZKsnarks and Mimblewimble-Lelantis.