Bitcoin right now is not really anonymous. While Bitcoin addresses aren’t necessarily linked to real-world identities, they can be. Monitoring the unencrypted peer-to-peer network, analysis of the public blockchain, and Know Your Customer (KYC) policy or Anti-Money Laundering (AML) regulation can reveal a lot about who’s using Bitcoin, and for what.
This is not great from a privacy perspective. Bitcoin users might not necessarily want the world to know where they spend their money, what they earn or how much they own, while businesses may not want to leak transaction details to competitors – to name some examples.
Additionally, bitcoins being traceable, possibly “tainted,” and potentially worth less than other bitcoins is at odds with fungibility. This could even challenge Bitcoin’s value proposition as money.
But there are potential solutions to increase privacy, and improve fungibility.
A solution that has been around for a while is CoinJoin.
At its heart, the Bitcoin protocol consists of transactions. All these transactions are completely public on the blockchain, which means that anyone can see which addresses sent bitcoins to which addresses. If some of these addresses are linked to real world identities, it can reveal who transacted with whom ‒ or what for. This is at odds with privacy and – in particular ‒ fungibility.
Additionally, each particular transaction spends one or several “inputs,” referring to the addresses bitcoins are sent from. (These inputs are spent to “outputs,” referring to the addresses bitcoins are sent to.) This poses another challenge to privacy and fungibility, since all input-addresses would typically belong to the same user: the sender of the transaction. If even one of all clustered input-addresses can be linked to a real-world identity, all of them are.
CoinJoin – proposed in 2013 by Bitcoin Core and Blockstream developer Gregory Maxwell – is designed to solve both these problems. It obfuscates the trail of bitcoins and breaks the assumption that all input-addresses belong to the same user.
The CoinJoin concept is fairly straightforward.
Essentially, CoinJoin lets multiple users combine all inputs and outputs from several transactions into a single, big transaction. This single transaction spends bitcoins from different addresses to different addresses – and since none of the sending addresses pay none of the receiving addresses specifically; there’s no link between any of them.
(This can be compared to a group of people who throw their cash together and go shopping. While everyone could make sure no one spends more than they should, the shoppers wouldn’t necessarily spend the exact bills they originally put into the shared wallet themselves.)
In Bitcoin, this can be accomplished perfectly securely. All inputs require a corresponding signature from their respective owner, while the content of a transaction cannot be changed after a signature is added. As such, participants of a CoinJoin transaction simply announce which inputs and outputs they want to include in the transaction, and sign the aggregate only if these inputs and outputs are correctly included. Once all participants have signed (and only once they have signed), the transaction is broadcast.
A key feature of CoinJoin: once the transaction is broadcast and included on the blockchain, there is no way of knowing which bitcoins went where; not even the recipients of the transaction will know from which addresses they got paid.
Additionally, CoinJoin improves privacy even of those who don’t use it at all. Since a combination of inputs no longer necessarily means that all of the input-addresses belong to the same user, clustering has become a less powerful analytics tool in general.
CoinJoin does not require any changes to the Bitcoin protocol, and there are several implementations of it already. The main difference between some of the versions out there is how the CoinJoin transaction is created.
The easiest way to create a CoinJoin transaction is through a dedicated server. Anyone who wants to use CoinJoin would simply connect to the server to indicate which inputs and outputs the transaction should include. The server then creates a big aggregate transaction, and sends this back for all participants to sign. DarkWallet – the privacy-focused Bitcoin wallet that seems stuck in its alpha phase – employs a server-based model, as does the popular Blockchain web wallet, though its effectiveness has been questioned in the past.
The main problem with the server-based model, is that whoever controls the server would typically have access to the data provided by the individual participants. As such, this server presents a single point of failure from a privacy and fungibility perspective. There are potential solutions to cryptographically mask transaction data even from the server, but this is still theoretical for now.
There are also decentralized CoinJoin solutions, that construct CoinJoin-transactions peer-to-peer, or at least without any particular central intermediary. There have been several attempts in this direction, including Coinmux, Coinjumble, CoinJoiner and former DarkWallet developer Amir Taaki’s CoinJoin tool. But none of these are widely used, and therefore not very useful – “coinjoining” makes sense only when there’s someone to join with.
A more recent take on the CoinJoin strategy that intends to tackle this problem is JoinMarket: a marketplace for CoinJoin transactions. Users can offer a spot in a CoinJoin transaction in return for a small fee – or buy access to a CoinJoin transaction themselves. The creators of JoinMarket believe that the incentive to mix coins in return for fees should generate enough liquidity to make the market a success – while the competitive nature of it should keep fees low. Indeed, JoinMarket is relatively well used compared to alternatives, and the order book (at the time of writing) offers thousands of bitcoins to mix with.
Lastly, another privacy-focused wallet, Samourai Wallet, currently includes a type of CoinJoin imitation, designed to throw off whoever is analyzing blockchain data. This option makes transactions appear like CoinJoin-transactions, while in reality all inputs and outputs belong to the same user. (Samourai Wallet plans to expand build-in and cross-wallet mixing options later this year, which might also utilize CoinJoin functionality.)
Downsides and Trade-Offs
While CoinJoin can be useful – it’s not perfect.
Most important, while CoinJoin does a great job at mixing inputs and outputs, this is not sufficient if the amounts are revealing. If one input sends 4.9 bitcoins, another input sends 2.7 bitcoins and a third inputs sends 0.8 bitcoins, while one output receives 4.9 bitcoins, one receives 2.7 bitcoins and a third receives 0.8 bitcoins, then it’s simple to connect inputs to outputs.
A potential solution to this problem, of course, are Confidential Transactions. Since Confidential Transactions mask the amounts sent (but not the inputs and outputs), CoinJoin and Confidential Transactions are a potentially powerful combination.
Another risk is that of Sybil attacks. Seemingly multiple participants in a CoinJoin transaction can really be one and the same entity, monitoring a particular participant.
(If nine-of-ten inputs and outputs belong to a single NSA-agent sending bitcoins to himself, he would know which remaining output sent bitcoins to which remaining output.)
There is no easy solution for the problem of Sybil attacks, but as more genuine users mix their coins, it does become significantly harder to pull off successfully.
Which brings us to the next point: CoinJoin is still a hassle. Almost no wallets have it built in, and those that do aren’t used a lot (and rely on a central server.) JoinMarket is probably the most successful implementation to date, but still requires special software and additional fees (though small).
But an interesting development on the horizon might skew these incentives: Schnorr signatures. Enabled by Segregated Witness, Schnorr signatures could allow for the aggregation of all signatures in a CoinJoin transaction into a single signature. This efficiency should result into lower transaction fees per input, and perhaps stimulate use of the most private and fungibility-friendly solution.
Thanks to Gregory Maxwell for added feedback.