CoinJoin Explained
First proposed by Gregory Maxwell, CoinJoin is an anonymization method for individuals that are involved in digital currency transactions. Originally intended for Bitcoin, CoinJoin was designed to bring true transactional anonymity to users on the Bitcoin network, which at best can currently now only be characterized as being pseudonymous.
Transactional activity that occurs on the Bitcoin network is publicly recorded on the blockchain, storing information such as: user addresses and balances. User addresses serve as a substitute for user identity, which is what gives Bitcoin its pseudonymity. However, due to the transparent nature of Bitcoin, it is possible to track the flow of funds moving in and out of an address to determine a user’s transactional activity. Blockchain analysis, Anti-Money Laundering (AML) regulation and Know Your Customer (KYC) policy are all factors that can be used to reveal a user’s identity. This is in contrast to existing distributed payment systems such as Zcash and Monero, which arguably provide much stronger privacy features for users transacting on their network.
Bitcoin’s limited privacy protection also has ramifications for the digital currency’s fungibility. Fungibility is a concept that describes a good or commodity whose individual units are directly interchangeable. For example, the U.S. dollar can be described as being fungible because one U.S. dollar is directly interchangeable for another U.S. dollar.
The ease with which an individual can exchange one bitcoin for another might be problematic given Bitcoin’s rudimentary privacy features. A lack of privacy might encourage merchants and individuals to assemble centralized lists of good coins and bad coins (coins used for illegal activity). Bitcoin’s fungibility could be severely affected if merchants and individuals refuse to accept coins that have been used in illegal activity on grounds that they are ‘tainted’. Robust privacy features would prevent such a scenario from occurring, as merchants and individuals are more likely to accept a digital currency in exchange for a good or service if they cannot identify the currency’s transactional history.
CoinJoin and The UTXO Model
Understanding CoinJoin firstly requires a brief overview of how transactions are executed on the Bitcoin network. Transactions on Bitcoin operate using the UTXO (Unspent Transaction Output) model. Using this model, nodes track all available spendable transaction outputs on the Bitcoin network. These spendable transaction outputs are also known as unspent transaction outputs or UTXOs. After the network identifies an available spendable output, it is then used in the formation of a new transaction.
As shown above, each transaction that is executed possesses at least one input and one output, with the input deriving from the output of a previous transaction. The output, now recognized as a UTXO by the network, sits in the UTXO set until it is spent by a later input.
CoinJoin enhances user privacy by combining all inputs and outputs from separate transactions to form a single unified transaction. An individual who wishes to use CoinJoin would first seek out another individual who also wishes to combine their inputs for a transaction, and then initiate a joint and singular CoinJoin transaction. Because the CoinJoin transaction combines numerous inputs, it would become difficult for a third-party to determine which recipient received which output. The recipient themselves would be unable to determine which address the received funds came from.
As the image above demonstrates, Bob and Alice are individuals who wish to enhance their user privacy when transacting on the Bitcoin network. To do this, they both use a CoinJoin service that combines their inputs. In this case, Bob’s input is 20 BTC and Alice’s input is 10 BTC. The CoinJoin service then sends those funds to the intended recipient addresses, which in this case is to Ted and Carol (the transaction change is also returned back to Bob and Alice). A larger pool of individuals who wish to use a CoinJoin service and combine their inputs would enjoy a greater level of privacy, as there would be more inputs to combine to form the single CoinJoin transaction.
Following Maxwell’s proposal about CoinJoin, we have seen several implementations of the technology. The most popular implementation of CoinJoin is arguably within the Dash cryptocurrency. Dash has taken the core mixing function proposed by Maxwell and innovated on it by incorporating what is known as the denomination and chaining approach.
Dash builds on Maxwell’s core mixing functionality by breaking down user transaction inputs in common denominations, such as 0.01DASH, 0.1DASH, 1DASH, and 10DASH. The act of mixing user transactions on the Dash network is known as a mixing session or round. Dash’s chaining approach describes the process in which user transaction inputs undergo multiple mixing sessions in order to increase user anonymity.
Other implementations of CoinJoin include:
CoinJoin FAQ
Maxwell conducted a FAQ in 2013 about CoinJoin, and it can be found below:
Don't you need tor or something to prevent everyone from learning everyone's IP?
“Any transaction privacy system that hopes to hide user's addresses should start with some kind of anonymity network. This is no different. Fortunately networks like Tor, I2P, Bitmessage, and Freenet all already exist and could all be used for this. (Freenet would result in rather slow transactions, however).”
“However, gumming up “taint analysis” and reducing transaction sizes doesn't even require that the users be private from each other. So even without things like tor this would be no worse than regular transactions.”
Don't the users learn which inputs match up to which outputs?
“In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.”
“More complicated implementations are possible where even the server doesn't learn the mapping.”
“E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.”
“Similar things can be accomplished with various zero-knowledge proof systems.”
Does the totally private version need to have a server at all? What if it gets shut down?
“No. The same privacy can be achieved in a decentralized manner where all users act as blind-signing servers. This ends up needing n^2 signatures, and distributed systems are generally a lot harder to create. I don't know if there is, or ever would be, a reason to bother with a fully distributed version with full privacy, but it's certainly possible.”
What about DOS attacks? Can't someone refuse to sign even if the transaction is valid?
“Yes, this can be DOS attacked in two different ways: someone can refuse to sign a valid joint transaction, or someone can spend their input out from under the joint transaction before it completes.”
“However, if all the signatures don't come in within some time limit, or a conflicting transaction is created, you can simply leave the bad parties and try again. With an automated process any retries would be invisible to the user. So the only real risk is a persistent DOS attacker.”
“In the non-decentralized (or decentralized but non-private to participants) case, gaining some immunity to DOS attackers is easy: if someone fails to sign for an input, you blacklist that input from further rounds. They are then naturally rate-limited by their ability to create more confirmed Bitcoin transactions.”
“Gaining DOS immunity in a decentralized system is considerably harder, because it's hard to tell which user actually broke the rules. One solution is to have users perform their activity under a zero-knowledge proof system, so you could be confident which user is the cheater and then agree to ignore them.”
“In all cases you could supplement anti-DOS mechanisms with proof of work, a fidelity bond, or other scarce resource usage. But I suspect that it's better to adapt to actual attacks as they arise, as we don't have to commit to a single security mechanism in advance and for all users. I also believe that bad input exclusion provides enough protection to get started.”
Isn't the anonymity set size limited by how many parties you can get in a single transaction?
“Not quite. The anonymity set size of a single transaction is limited by the number of parties in it, obviously. And transaction size limits as well as failure (retry) risk mean that really huge joint transactions would not be wise. But because these transactions are cheap, there is no limit to the number of transactions you can cascade.”
“In particular, if you have can build transactions with m participants per transaction you can create a sequence of m*3 transactions which form a three-stage switching network that permits any of m^2 final outputs to have come from any of m^2 original inputs (e.g. using three stages of 32 transactions with 32 inputs each 1024 users can be joined with a total of 96 transactions). This allows the anonymity set to be any size, limited only by participation.”
“In practice I expect most users only want to prevent nosy friends (and thieves) from prying into their financial lives, and to recover some of the privacy they lost due to bad practices like address reuse. These users will likely be happy with only a single pass; other people will just operate opportunistically, while others may work to achieve many passes and big anonymity sets. All can coexist.”
How does this compare to Zerocoin?
“As a crypto and computer science geek I'm super excited by Zerocoin: the technology behind it is fascinating and important. But as a Bitcoin user and developer the promotion of it as the solution to improved privacy disappoints me.”
“Zerocoin has a number of serious limitations:”
“It uses cutting-edge cryptography which may turn out to be insecure, and which is understood by relatively few people (compared to ECDSA, for example).”
“It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage).”
“It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto).”
“Validation is very slow (can process about 2tx per second on a fast CPU), which is a major barrier to deployment in Bitcoin as each full node must validate every transaction.”
“The large transactions and slow validation also means costly transactions, which will reduce the anonymity set size and potentially make ZC usage unavailable to random members of the public who are merely casually concerned about their privacy.”
“Uses an accumulator which grows forever and has no pruning. In practice this means we'd need to switch accumulators periodically to reduce the working set size, reducing the anonymity set size. And potentially creating big UTXO bloat problems if the horizon on an accumulator isn't set in advance.”
“Some of these things may improve significantly with better math and software engineering over time.”
“But above all: Zerocoin requires a soft-forking change to the Bitcoin protocol, which all full nodes must adopt, which would commit Bitcoin to a particular version of the Zerocoin protocol. This cannot happen fast—probably not within years, especially considering that there is so much potential for further refinement to the algorithm to lower costs. It would be politically contentious, as some developers and Bitcoin businesses are very concerned about being overly associated with “anonymity”. Network-wide rule changes are something of a suicide pact: we shouldn't, and don't, take them lightly.”
“CoinJoin transactions work today, and they've worked since the first day of Bitcoin. They are indistinguishable from normal transactions and thus cannot be blocked or inhibited except to the extent that any other Bitcoin transaction could be blocked.”
“(As an aside: ZC could potentially be used externally to Bitcoin in a decentralized CoinJoin as a method of mutually blinding the users in a DOS attack resistant way. This would allow ZC to mature under live fire without taking its costs or committing to a specific protocol network-wide).”
“The primary argument I can make for ZC over CoinJoin, beyond it stoking my crypto-geek desires, is that it may potentially offer a larger anonymity set. But with the performance and scaling limits of ZC, and the possibility to construct sorting network transactions with CJ, or just the ability to use hundreds of CJ transactions with the storage and processing required for one ZC transactions, I don't know which would actually produce bigger anonymity sets in practice. E.g. To join 1024 users, just the ZC redemptions would involve 20k * 1024 bytes of data compared to less than 3% of that for a complete three-stage cascade of 32 32-way joint transactions. Though the ZC anonymity set could more easily cross larger spans of time.”
“The anonymity sets of CoinJoin transactions could easily be big enough for common users to regain some of their casual privacy and that's what I think is most interesting.”
How does this compare to CoinWitness?
“CoinWitness is even rocket-sciency than Zerocoin, it also shares many of the weaknesses as a privacy-improver: Novel crypto, computational cost, and the huge point of requiring a soft fork and not being available today. It may have some scaling advantages if it is used as more than just a privacy tool. But it really is overkill for this problem, and won't be available anytime real soon.”
Sounds great! Where is it?
“Theres the rub: There exist no ready made, easy-to-use software for doing this. You can make the transactions by hand using bitcoin-qt and the raw transactions API, as we did in that “taint rich” thread, but to make this into a practical reality we need easy-to-use automated tools.”
“Luke has written up some sketches a protocol which would enable establishing joint transactions over the regular Bitcoin network.”
“The Bitcoin-qt RPC system provides everything someone needs to write a side-car applet (including the ability to lock txouts to prevent them from being spent out from from under it) that participants in such a system. But the fact that so many users use centralized webwallets today which can spy on them will ultimately limit the userbase for these tools.”
“Personally, most of my coding brain capacity is spent on other things which are even more important to me. And what I could spare on Bitcoin is spent on more core and security things— if I work on anything wallet related anytime soon it will likely be improving the privacy behavior of coin selection… But moreover:”
“Anyone who builds this is going to be accused of enabling criminal activity, it doesn't matter if any actual criminals use this or not: Criminal activity sells headlines. Being a Bitcoin core developer already fills my quota for accusations of this kind, especially my quota for risk that I'm not even paid for.”
“In reality, real criminals don't need CoinJoin if they have even the slightest clue: They can afford to buy privacy in a way that regular users cannot, it's just a cost of their (often lucrative) business.”
“Joe-criminal can go out and buy 120% PPS mining to get brand new coins, or run his money through a series of semi-sham high cashflow gambling businesses for a 50% cut, they can afford the cost of seeking out and interfacing with these seedy services… Joe and Jane doe? Their names are up in neon on blockchain.info. It might not seem great to them, but if there a high cost of fixing it they simply won't, because the cost of fixing it is very concrete and the cost or privacy loss is speculative and distant. They might just need to give up bitcoin and switch to something almost totally private: cash… Regular users need efficient and inexpensive privacy if it is to help them at all.”
“I know that making such a tool doesn't fit into the get-rich-quick mold of many Bitcoin businesses, but the importance is self-apparent and the simplest versions of this don't require very deep technical wizardry. I think the “political” risk of improving people's privacy is a real one that you should carefully consider, but around these parts I see people sticking their names on some rather outrageously risky stuff. I'd hoped the “taint rich” thread would be enough to inspire some community action, but perhaps this will be.”
“So, instead, I ask you: Where is it?”
Maxwell’s BitcoinTalk thread describing the CoinJoin implementation can be found below:
