Navigating Bitcoin CoinJoin - Bitcoin Magazine

This is an opinion editorial by Thibaud Maréchal, a contributor to privacy-focused Bitcoin wallet project Wasabi Wallet.

“Divide and conquer” is a battle-tested military strategy to fracture a group of people by making them disagree and fight each other instead of joining together against a common enemy. Wasabi and Samourai, two popular bitcoin wallets with different CoinJoin implementations have been fighting for many years. JoinMarket, a third CoinJoin implementation, has also been involved in colorful debates with other privacy developers.

Learning about bitcoin privacy and CoinJoins has become quite hard with ongoing drama. Who to trust? How can one verify for themselves? It’s all very unclear. What does it bring for precoiners, casual bitcoiners and purists alike? Confusion, fear, uncertainty and doubt (FUD). The state of bitcoin privacy is embarrassing with all this perpetual drama scaring away new users. Precious time is wasted by developers, educators and regular users who would probably be better off doing anything but trying to keep up with the drama.

It is obvious that no one agrees on “how to do CoinJoins right,” let alone, how CoinJoins should be implemented to optimize user privacy and block space efficiency on the Bitcoin network? What are the tradeoffs between different implementations? Are some implementations outright flawed? How do CoinJoins “cross the chasm” from early adopters to mainstream users when billions of people will turn to bitcoin in the coming years?

Let’s now take a look at CoinJoins by asking fundamental questions and raising some assumptions to build some sort of mental models, which will be useful in evaluating different implementations in future articles.

Not All CoinJoins Are Made Equal

Blockspace efficiency should be considered to make sure CoinJoin transactions scale as Bitcoin gets used by more people across the world. This is rarely discussed as a top priority. Any CoinJoin design that ignores blockspace scarcity is unnecessarily spamming the block chain while accumulating technical debt, which will be difficult to pay back as more users CoinJoin in the future. Having a minimal footprint on the block chain is one goal that seems very reasonable to aim for: a small number of transactions to get to an acceptable level of anonymity sounds ideal.

What is an acceptable level of anonymity?
What does anonymity even mean in the context of bitcoin privacy?
How are particular CoinJoin designs dealing with blockspace scarcity?

Reclaim Your Privacy

Anonymity in bitcoin would mean that there are no outstanding or unusual features that would make a given transaction remarkable from other transactions on the ledger. That, of course, is not by design on the Bitcoin network, which is a pseudonymous system where coins (UTXOs, which stands for Unspent Transaction Output in technical terms) are by default not fungible due to having unique transaction histories.

CoinJoins add a level of anonymity to the bitcoin network by breaking links between transaction inputs and outputs primarily making resulting UTXOs indistinguishable from each other. There are other heuristics that chain analysis companies use to watch the bitcoin network, such as common input ownership, self-spending, round amounts or timing analysis to name a few, which may or may not be obscured by CoinJoins.

CoinJoins help bitcoiners reclaim their privacy but are not the solution to everything. If privacy is understood as the choice to share information about oneself, great privacy can be achieved through CoinJoins but picking the right implementation is essential.

What is my privacy goal using CoinJoins?
Which heuristics does a CoinJoin implementation protect me against?
What are the risks that I want to avoid?

Number Of Participants

Existing CoinJoin implementations have very different ways of improving privacy. Irrespective of each CoinJoin implementation design, the anonymity set (one measure for the level of anonymity) seems to be the most traditional way to evaluate how much privacy one gets from a CoinJoin. There are other ways that will be discussed in other articles. The assumptions are that either a high anonymity set is achieved with a large CoinJoin transaction or that it is achieved over multiple smaller CoinJoin transactions. These two parameters are both important, but is there one that is more important than the other?

In terms of blockspace efficiency, the assumption would be that achieving a large anonymity set with a single very large transaction that has many participants is better than multiple very small transactions with a few participants.

Is one single large CoinJoin or multiple small CoinJoins better for privacy?
How can that be verified truthfully and rigorously? How small is too small for a CoinJoin?
What is the right metric to evaluate how much privacy you can get from a CoinJoin?
What is the most blockspace efficient when it comes to the size and number of CoinJoins to reclaim your privacy?
Is it realistic to expect coins to participate in multiple CoinJoins over time as more people start using CoinJoins? How many CoinJoin rounds is enough or too much?

In simple terms, CoinJoins allow bitcoiners to reclaim their privacy by giving them plausible deniability. Plausibility is a measure of probability. How likely is it that your bitcoins were spent or simply moved to another address you still control? How likely is it that one input is linked to a given output?

Obviously, the smaller the probabilities across many options, the better plausible deniability you get as a hodler. Plausible deniability is hard to preserve because errors are easy to make. Change outputs are often problematic for bitcoiners who care about privacy and are often a source of contentious discussions and criticism. Why is change output such a controversial topic in CoinJoins?

Change Output

It’s all about deterministic links. If bitcoin transactions had a spectrum of privacy, on one end would be a transaction with absolute plausible deniability, meaning 0% chance of knowing the link between inputs and outputs. This is also referred to as randomness or entropy in a CoinJoin. The assumption is that the more random or higher the entropy, the better. On the other end would be a transaction with 100% deterministic links between its only input and single output.

Unintuitively, a high entropy doesn’t necessarily mean that a transaction provides good privacy. A transaction with three inputs and three outputs of equal amounts technically has 100% entropy, meaning there is no way to distinguish each output from each other; and yet, there is a 33.33% chance that each input is linked to a particular output. High entropy does not necessarily mean good plausible deniability.

Change almost always has a very high deterministic link to its previous transaction. In other words, there is little doubt that a change output is not tied to the previous transaction that spent it. That can be a considerable privacy issue if a given change output were to be co-spent with other anonymous inputs following CoinJoins (though exceptions may apply in certain cases). This is usually referred to as UTXO consolidation and can be fatal to your privacy if done naïvely.

Change outputs can de-anonymize outputs that have gained some plausible deniability from CoinJoins if spent together. Errors are commonplace for bitcoiners and sometimes the realization comes too late, undoing years of diligent privacy enhancements in one single spend. How to get rid of this change output problem?

Existing CoinJoin implementations have three ways of dealing with change outputs: isolate the change into another wallet that is not CoinJoining, include the change output in the same wallet that is CoinJoining or get rid of the change output by not having change outputs at all. The latter seems to be the most advisable in terms of privacy and blockspace efficiency but further digging is required to validate or reject this assumption.

Is a high entropy score enough to qualify a CoinJoin as good for your privacy?
Is it better to isolate change outputs in another wallet or should it be removed entirely?
Is a change output always bad for your privacy?

Coin Denominations

Getting rid of change outputs in CoinJoins requires that coin denominations be variable in a CoinJoin. In other words, the inputs registered in a given CoinJoin cannot have a fixed size like 0.1 BTC, otherwise it becomes impossible (or at least very hard) to consume inputs without creating change outputs as most UTXOs don’t have round numbers (i.e. 0.19572394 BTC where 0.09572394 BTC would be the change in a 0.1 BTC fixed coin denomination CoinJoin).

Change outputs can be dangerous for your privacy, remember? Having multiple sizes for inputs and outputs in a CoinJoin seems to be a bad idea as it brings us closer to deterministic links between inputs and outputs, right? Well, yes and no. It depends. If a CoinJoin has a small number of participants (meaning few inputs and few outputs), then different denominations are a bad idea. But what if a large number of inputs and outputs are included in a given CoinJoin?

In a large CoinJoin, multiple denominations can bring a high level of plausible deniability to each resulting output without creating change outputs and requiring additional transactions, which is a highly efficient use of blockspace. It seems that many boxes could be ticked at this point.

Is it better to have fixed or variable coin denominations in a CoinJoin?
How big should a CoinJoin be for variable denominations to make sense?
Are variable coin denominations the best way to get rid of change output in CoinJoins?

It goes without saying that CoinJoin rounds interconnectivity should not be tolerable in any circumstances regardless of whether coin denominations are different or if the CoinJoin is a large or small transaction, right? Well, here again, there is an important nuance to understand.

Coinjoin Rounds Interconnectivity

It is claimed that registering inputs from past shared CoinJoins into new CoinJoins is ill-advised in all cases. Participants from mutually shared past CoinJoins do not seem to benefit from mixing together in other CoinJoins. It seems harmful to privacy, and is often criticized.

What if a CoinJoin is large and some registered inputs come from multiple other CoinJoins, each being also downstream from multiple other CoinJoins? In such a case, participants remixing together are still improving their privacy despite coming from a shared past CoinJoin. If each CoinJoin is large enough, the participants are not required to remix multiple times, though they can if they want to further increase their anonymity sets.

If many large intertwined CoinJoins are involved, the resulting anonymity set should provide plenty of plausible deniability, despite sharing past CoinJoins as origin of funds.

Is CoinJoin rounds interconnectivity, which is sharing mutual past CoinJoins, a bad thing on its own?
How large should a CoinJoin be for remixing with other past inputs to be considered safe?

Personal Full Node

Should you run your own bitcoin full node when participating in CoinJoins? On the surface, it seems like a great idea, and it usually is. Some CoinJoin implementations allow that, while others outright require it. Others won’t allow you to even use your own full node. Is that to condemn absolutely? If you’ve read until now, you should know that the answer is nuanced and opens up a deep rabbit hole to be explored later.

Running your own full node comes with usability tradeoffs, and may not add much privacy protection if not all users do it. Running your own node may even give you a false sense of security and privacy if few CoinJoin participants do it, which can be deeply harmful. If Tor is used as an anonymous way to CoinJoin (and we’ll leave it as that for now), then using a trusted full node to broadcast the CoinJoin transaction can be fine as the default. Lots of nuances, and of course, don’t trust, verify.

There are some essential questions to ask so as to not fall in the trap of privacy virtue signaling.

Does the CoinJoin implementation allow to run full nodes, require them by default or don’t allow them?
If personal full nodes are not mandatory, what are the privacy shields in place? i.e. Tor, block filters, etc…
If I run my own full node, but expect most users to use a default trusted node to CoinJoin, how does that affect my privacy? Can the coordinator de-anonymize me?

With privacy concerns, it is always important to understand what you’re trying to protect, and against whom. Running a full node and using it with your own wallet is the right way to use bitcoin as it allows you to verify your wallet balance and broadcast transactions to the network without trusting anyone. But when it comes to CoinJoins, there is usually a coordinator in charge. What does the coordinator do and how is it selected? Read on.

The Coordinator

The CoinJoin coordinator is in charge of having every participant register their inputs and outputs, and sign the collaborative transaction before broadcasting it. Most CoinJoin implementations default on a central coordinator, which is a single point of failure. Up until now, this has been an accepted tradeoff in most bitcoin communities. Can a central CoinJoin coordinator fail? Absolutely. Other implementations allow anyone to be a coordinator for each different CoinJoin, though there are other sets of trade offs here that will be discussed later.

Coinjoins being non-custodial, no loss of funds could occur if any coordinator would fail. The coordinator should never know more than what everyone knows publicly on the bitcoin network. Why? If a coordinator knows more than what is publicly available, a CoinJoin coordinator becomes a honeypot with highly sensitive data that can be exploited against bitcoiners trusting the service.

You should never trust a CoinJoin coordinator. If a CoinJoin coordinator cannot be evil, good. If it can be evil, it will be eventually, out of errors, omissions, coercion or outright dishonesty.

An example of sensitive user data would be XPUBs, which undeniably leak all the information about a wallet, its addresses, including past, current and future bitcoin transactions. Another example would be the ratio between users running their own full nodes and users trusting the coordinator’s full node to broadcast CoinJoins, as it could de-anonymize users running their own nodes, and therefore deterministically know the links between their inputs and outputs. This is yet another nuanced topic, which would require further investigation and discussion.

Does the coordinator know more than what is publicly available on the bitcoin network?
Do users leak sensitive data to the coordinator, such as their XPUB or whether or not they run their own full nodes?
Does the coordinator claim that users should trust them using legal defense mechanisms? (i.e. warrant canaries, regulatory arbitrage, etc…)

Fees

Bottom line, who pays for what in CoinJoins? These bitcoin transactions can be expensive and sometimes fee structures are unclear for bitcoiners. It’s hard to know how much good privacy will cost you or even if you are getting any privacy out of it. Some CoinJoin implementations allow a single input to buy its privacy from other inputs who only participate for free to increase their own anonymity set. Getting paid to CoinJoin? With patience, yes.

Some models rely on shared fees where only some UTXOs pay fees while others don’t. Other models rely on inviting an ever growing number of new clear inputs (not mixed yet) to fund the existing CoinJoins for remixing inputs that do not have high enough anonymity levels. Some models seem unsustainable over the long term while others are naïve, or way too expensive for most users.

And what fees are we talking about? Well usually, inputs participating in CoinJoins pay both a coordinator fee or taker fee, (the service fee to get some level of anonymity) and the bitcoin network fees. In particular CoinJoin models, these fees get waived in certain circumstances. The economics of CoinJoins is a deep rabbit hole which requires further investigation for a much deeper understanding.