When they hear the word “CoinJoin,” the first things that pop into many relatively-new Bitcoiners’ heads are probably the ZeroLink implementations Wasabi Wallet and Samourai Wallet. In the last few years, these two projects have taken Bitcoin privacy quasi-mainstream, making it much simpler and more accessible.
If you are new to the space though, you might not be aware of the fact that the project JoinMarket has been providing CoinJoin tools to Bitcoin users since 2015.
Collaborative transactions to disrupt common ownership assumptions were an idea posited by Bitcoin developer Greg Maxwell back in January 2013, and later formalized into the concept of CoinJoin in August of that year.
The idea sat around for two years before something was released implementing it, and there was a reason for that: An issue with the overall idea that led to failures with prior attempts, such as Dark Wallet by Amir Taaki, was that of attracting liquidity. CoinJoin can be a very useful tool, but if there is no one willing to CoinJoin with you or no way to find them if they are willing, it does no real good.
The problem was with how to convince people to join that initial pool to help snowball it into a larger pool of liquidity and users. JoinMarket’s solution was pretty simple yet brilliant at the time: provide a market mechanism so that consistent liquidity providers can actually earn money for providing liquidity to CoinJoin pools.
JoinMarket functions around what is effectively an orderbook-driven marketplace, composed of both market makers and market takers buying and selling CoinJoin liquidity to anonymize their activity on chain.
Makers can sit around waiting for however long it takes with open offers until takers arrive seeking to pay for their services. It solves the user problem of sitting around and waiting forever for someone to mix with. Market makers, seeking to earn profits, are incentivized by the fees they charge to simply always be online waiting for the takers; and the takers, seeking privacy, are incentivized to pay these fees. It’s a win-win arrangement for everyone.
In its architecture, as well as its potential for coordination upgrades, JoinMarket offers a potentially more decentralized version of coin mixing in comparison to the better-known ZeroLink. Here’s how.
How Mixing Is Coordinated: ZeroLink Vs. JoinMarket
The overall architecture of ZeroLink, as compared to JoinMarket, is very different.
In the case of Wasabi and Samourai, there is a single coordinator server operated by the wallet maker coded into the wallet. All users participate in the CoinJoin by contacting this central server and “registering” to wait around until enough users have registered to construct the CoinJoin. After the required number of users is present and registered, the coordinator server signs a blinded credential representing the right to create an output in the CoinJoin transaction, and the user disconnects and reconnects through a new Tor connection to register their transaction outputs.
This prevents the coordinator from learning which inputs map to which outputs. Users pay a fee to the coordinator for its role in facilitating the CoinJoin. In this model, there is no incentive to provide liquidity except for the privacy gains, and despite the issues with past attempts like Dark Wallet, this seems to work just fine for Wasabi and Samourai.
JoinMarket, on the other hand, has an orderbook that makers advertise on, allowing takers to pick from the available maker offers (this is currently done over Internet Relay Chat [IRC]).
Makers will connect to the orderbook with a unique ID, then they will post an offer to the orderbook containing the following information: the fee the maker is charging for mixing with takers, the amount the maker will contribute to miner fees and then the minimum and maximum denomination value they will make mix-denominated outputs in. They also post a way for people to privately connect to them directly.
When takers want to CoinJoin, they download the orderbook and their client selects makers to mix with based on their settings. After the client selects a maker, the taker will post a temporary public key for encryption and start communicating with the maker through encrypted messages over IRC (it is worth noting that it is possible for multiple takers to be connected to a single maker at the same time). If all parties agree, they sign the transaction, including the taker’s fee to the maker, and submit it to the network.
Because of how this coordination works, makers do learn the outputs of takers in the process of coordinating the CoinJoin construction. To mitigate this, JoinMarket has a “tumble” feature, where the taker’s client will mix multiple times with different makers until reaching the number of mixes set. This guarantees that no single maker will be able to unwind a single taker’s entire mix history, because each maker along the “tumble route” only learns the connections in that one transaction.
These differences have a lot of overall implications in terms of design architecture for JoinMarket, as we will see going through some of the current state of the project as well as future plans.
How Sybil Attacks Are Mitigated: ZeroLink Vs. JoinMarket
Sybil attacks — in this context, a single user pretending to be many users to undermine privacy by creating a fake “crowd” for others to hide in while they actually constitute the entire “crowd” — are a fundamental problem of any mixing protocol on Bitcoin. If the entire crowd is composed of you and the Sybil attacker, and no one else, the attacker knows all of your coins and you have gained no privacy from their vantage point. At the end of the day, there is no fundamental solution to this problem, all you can do to mitigate it by increasing the cost to perform the attack.
In the case of ZeroLink, the problem is mitigated by the coordinator charging fees. As long as the cost in miner fees is higher than the fee revenue that the coordinator server collects in fees, even the coordinator would incur a net loss in trying to Sybil attack their own users.
For JoinMarket, the issue is a bit more complicated. You have to protect takers, in their case from makers Sybil attacking the orderbook so that a taker only mixes with them and reveals their entire mix history to the malicious maker. But you also have to protect takers from attacking makers by requesting CoinJoins and then dropping out of the protocol after the maker reveals their outputs to the taker.
This allows the malicious taker to separate that maker’s inputs in future transactions from the takers they mix with. Repeating this multiple times in a row against the same maker would allow them to deanonymize the takers that have mixed with them.
There are two mechanisms in this system to offer appropriate defense for each class of attack: The first, to deal with takers spying on makers, is a proof of discrete logarithm equivalence (defense number two in this writeup, also known as PoDLE).
The basic idea is that for a private/public keypair for a Bitcoin UTXO, you can generate a second different public key corresponding to the private key, and create a zero-knowledge proof (ZKP) showing they both share the same private key. After providing the second key and proof to the maker, the taker reveals the first public key(s) corresponding to the output(s) they want to mix.
Now, this setup allows a maker to publish the second public key and ZKP to all other makers without doxxing the taker’s actual outputs — that way, if a taker who is coordinating with the original maker tries to reuse that output to spy on multiple makers at the same time, all of the other makers will see that the taker’s first public key matches the published second key and ZKP. They will then refuse to reveal their own outputs to the malicious taker. This raises the cost of takers spying on makers’ outputs by requiring that a taker has unique outputs for each maker they spy on, instead of being able to reuse the same outputs to attack multiple makers.
The second defense mechanism is to protect takers from malicious makers that pretend to be many different makers in the orderbook, thus allowing the malicious maker to unravel the mixing of takers that wind up only mixing with the attacker.
This mechanism is called a fidelity bond, which is essentially just taking a large amount of bitcoin and time locking it. Makers who do so can then sign and publish messages with that key to prove control over the time-locked coins. Takers’ clients, if they have configured their client to use fidelity bonds, will then weight their selection of makers to use to prefer ones that have higher amounts of value time locked in fidelity bonds. Fidelity bonds are weighted by the square of how many coins are locked up, i.e,. if you lock up four bitcoin, it will be weighted as 16; five will be weighted as 25; six will be weighted as 36, etc.
The rationale here is that you get compounding benefits as a maker with the more coins you lock up (you get chosen by taker clients more often), so if a few honest makers create very large fidelity bonds, they drastically raise the cost for Sybiling makers who would have to replicate that large fidelity bond amount for each of their fake identities in the orderbook. I.e., if three honest makers each put up 10 bitcoin in fidelity bonds, an attacker would have to spend 30 bitcoin in order to have a 50% chance of being chosen to mix with, it would cost 60 bitcoin to have a 66% chance of being chosen, etc.
The more honest makers that use fidelity bonds, the more the cost to Sybil attack compounds for malicious makers.
How The JoinMarket Coordination Mechanism Could Upgrade
In the case of ZeroLink, everyone coordinates through the centralized coordinator server — this is an explicit part of the system design and trust model in terms of reliability. If the coordinator goes down, no one can CoinJoin until it comes back up.
JoinMarket functions on an orderbook system to try and avoid this central point of failure, but as mentioned above, it is currently using IRC as a hosting and communication layer for the orderbook. IRC is a potential central point of failure for JoinMarket, just like the coordinator server is for ZeroLink. As a project built around coordinating CoinJoins in a decentralized manner, in the long term this dependency on IRC needs to be replaced with something more robust.
One of the most developed proposals is to implement some kind of directory server scheme similar to what the Tor Project uses. In the Tor network, clients connect to a set of servers run by Tor contributors that send them all of the nodes on the Tor network that they can construct onion routes through.
The idea with JoinMarket would be to have a similar set of servers that feed clients all of the makers with open offers. These servers would have to be run by someone other than the makers, because every maker would have an incentive to only advertise themselves on their own directory server to collect more fees. It would also have to be hard to join the set of directory servers, otherwise malicious entities could spin up a large number of them and Sybil attack all of the users who only connect to malicious servers.
Fidelity bonds could potentially address the Sybil issue here, as well as create a disincentive for makers to try running directory servers. Locking up coins in a fidelity bond for a directory server would leave them fewer coins to lock up in a maker bond, potentially leading to fewer taker clients selecting them for mixes.
There is also a proof of concept and proposal from Adam Gibson to integrate c-lightning into JoinMarket for use as a messaging layer. In the context of directory servers, this could facilitate a monetization method for them as separate entities using the Lightning Network. Directory servers could charge makers small sums over Lightning to advertise themselves on the directory.
How The JoinMarket Coordination Protocol Could Upgrade
As discussed above, makers learn the outputs of takers during single CoinJoins, this is why the tumbler mode exists, to let takers mix through multiple makers and mitigate that.
There is, however, a better solution, at least in the case when multiple takers are talking to a single maker at the same time, and they can coordinate talking directly to each other instead of only through the maker (if there is only one taker talking to a maker, this will not help because the maker knows every output that isn’t theirs belongs to the taker). CoinShuffle is a protocol to effectively do what blinded credentials accomplish in ZeroLink, to keep things private from the coordinator, except in a decentralized way for a group without a central coordinator.
Imagine that you have Alice, Bob and Charlie, who all want to CoinJoin with each other (they’ve already settled on the denomination for the CoinJoin outputs), and all three of them generate a temporary public key to have messages encrypted to.
Charlie gives his public key to Bob, then Bob gives Alice his own public key as well as Charlie’s. So, we have a situation where Alice has Bob’s and Charlie’s public keys, Bob has Charlie’s public key, and Charlie only has his own.
Alice takes the address she wants her output sent to and encrypts it to Charlie’s key, but then takes that encrypted message and encrypts it to Bob’s public key, nesting it like Russian dolls. She then passes this to Bob, who decrypts his layer only to find an encrypted message to Charlie that he can’t open. Bob then takes the address he wants his output sent to, and encrypts this to Charlie’s key. He passes both messages to Charlie. Charlie now decrypts both messages, and finds the addresses that Alice and Bob want their outputs sent to, but he doesn’t know which address belongs to who (and remember, neither Alice nor Bob learned each other’s addresses either).
Charlie then constructs and signs the CoinJoin, passes it to Alice and Bob to sign, and it’s submitted to the network. Everyone in this process knows their output was constructed properly, but they don’t know who owns which of the other two addresses. This process can be extended for much larger groups, and if takers could communicate with each other directly before approaching makers, this protocol could be used to protect takers’ privacy against individual makers without having to tumble coins many times with different parties.
How The JoinMarket Transaction Structure Could Upgrade
The biggest similarity between ZeroLink and JoinMarket is the reliance on similar denominated outputs to create ambiguity about which inputs map to which outputs in a transaction.
While JoinMarket uses arbitrary amounts as opposed to the pre-defined amounts in ZeroLink, in the scope of a single CoinJoin transaction, all mix denominations have to be the same.
CoinjoinXT is a proposal by Gibson to potentially remove the need to rely on that so strictly (this could be implemented by ZeroLink as well). The basic idea is to take advantage of ECDSA Multiparty Computation, or MuSig now that Taproot is activated, and create a chain of pre-signed transactions using multisig addresses that look like regular single signature addresses.
When someone is watching the blockchain, two big assumptions that are often made are: one, that all inputs in a transaction are owned by one person (the big assumption that CoinJoins break); and two, that a payment means control of funds have been transferred.
So, what if multiple parties collaborated to lock all of their funds up into a multisig address that doesn’t look like one, and pre-sign a long chain of transactions that look like one person slowly spending money over time, but in reality is just peeling off money and giving it back to the original owners in small fragments?
What if some of those payment outputs were actually private Lightning channels between two of the CoinjoinXT participants to make sure that an observer couldn’t track the payment chain and put the amounts together at some point in the future?
This could open a whole new door in terms of flexibility for the types of CoinJoins that people engage in, and the degrees of privacy that they create. If a normal CoinJoin is blatantly screaming to the room “I’m going to leave and disappear now!” then CoinjoinXT could be the equivalent of quietly slipping out of the party unnoticed.
The Decentralized Future
On the whole, JoinMarket has honestly been somewhat of a niche tool in the ecosystem despite being around since 2015, given the necessity to run a full node to use it. It really wasn’t until ZeroLink came to market in the form of Wasabi and Samourai that CoinJoin really became an accessible and more widely used and understood tool.
Both are very valuable tools, but at the end of the day, they are services built around centralized companies — albeit, trustless services built in a way where it’s impossible to lose money interacting with them — but services nonetheless. What happens if the companies shut down? Will development still move forward in the same way, given it is currently funded by these companies?
There is absolutely a place for such tools in this space, and there are also positives to them as well. That same funding dynamic that draws into question the tool’s survival if the company fails guarantees lots of resources behind its development, so long as the company survives. But there is also a place for a decentralized tool not dependent on a single company. Progress might be slower, and problems might be more complicated to solve, but if it succeeds, the end result will be much more robust and adaptable.
There’s nothing wrong with services and companies in this space, but for every service and company where it is possible to build a decentralized alternative, that alternative should exist as another option. Like Bitcoin itself, one day you just might find yourself in dire need of it.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
