Bitcoin Mixers
Last updated
Last updated
Bitcoin mixing services provide their users with improved anonymity by leveraging inherent characteristics of both Bitcoin and blockchain technology. The participants send their Bitcoin to the mixer. From its pool of collected Bitcoin, the mixer returns funds to participants’ specified output addresses such that they are not returned their initial deposit.
The intrinsic anonymity in the Bitcoin ecosystem makes trusting a third party that runs a mixing service highly risky. Therefore, mixing protocols strive to avoid the use of a third party. Generally, decentralized protocols suffer from limited scalability and long wait times to find mixing peers (this is why the traditional type of mixer still thrives in most cases).
Centralized mixing protocols aim to secure a scheme where an untrusted third party exists, and participants send their funds through these centralized services. In this particular case, the end user can only rely on the reputation of the centralized mixer.
At the moment, you can count on the fingers of one hand the mixers that have been functioning without failure for more than 5 years (for the most part, these are those that use Jambler software).
CoinJoin is a method for multiple transactions from multiple senders to be combined into one transaction. Without any modification to the current Bitcoin protocol, this technique makes it difficult for outside entities to identify the corresponding recipient for each input. Users may collaborate to identify a uniform output amount and combine their transactions into one. To give you an idea of the theory that makes CoinJoin work, here is a description from Greg Maxwell himself.
Well, there is only one important disadvantage: They are easy targets for law enforcement. Neither of the two lead coordinators of CoinJoin exists anymore (Samurai/Wasabi). There isn’t so much of a technological disadvantage as much as a legal disadvantage.
It is important to note that running a coordinator is completely legal. It’s only when money launderers use your service when the problem comes, as you don’t have the funds or resources to detect that. Besides, that would defeat the entire purpose of CoinJoin which is to make all bitcoins equal. Non-fungible in other words. A few trivial disadvantages for using an enhanced coinjoin wallet:
Bitcoin mixers make less money off of you
There are less bitcoins for the feds to seize if they ever shut down a mixer
Meanwhile, mixers became ever more popular thanks to them spending even more money on ad, especially on Bitcointalk. This would be the subject of a lot of infighting and disagreement.
T. Ruffing presented CoinShuffle in 2014. The mixing protocol requires no third party, is compatible with the existing Bitcoin network, and uses CoinJoin to execute transactions. The protocol assumes that users have a secure, decentralized method to express their interest in participation. Output address shuffling and a final CoinJoin tx eliminate the risk of permutation leak and coin theft attacks.
J. Ziegeldorf proposed CoinParty, a mixing protocol with multiple one-to-one transactions to and from escrow addresses. While compatible with the existing Bitcoin network, CoinParty uses secure multi-party computation for users to collaborate. Temporary threshold ECDSA escrow addresses eliminate the risk of coin theft if 2/3 of the participants are benign users. Similar to CoinShuffle, output addresses are shuffled to avoid permutation leaks.
G. Bissias explored the threats presented by Sybil-based denial-ofservice attacks to Bitcoin mixing services. They present Xim, a two-party mixing implementation. Unlike the previously described methods, Xim provides a decentralized method for finding mixing participants. Joining a mix interaction requires both participants to spend funds. The requirement to pay to advertise and respond to desired mixing partners make Sybil attacks difficult.
M. Tran presented a centralized Bitcoin mixer using Trusted Execution Environments (TEEs). Obscuro addresses the threats posed by mixing operators to lessen the control they have on the functionality and dayto-day activity of the service. To do so, the mixer codebase is isolated from the rest of the system. Users are given the ability to verify the isolated functionalities using remote attestation and are guaranteed a large mixing set size. Obscuro’s implementation requires no changes to the existing Bitcoin network and is generic such that it can be implemented with any TEE technique.
J. Bonneau propose Mixcoin, a Bitcoin mixing protocol that provides accountability to expose malicious centralized mixers. To do so, signed warranties are implemented between the participants and the service. If any wrongdoing occurs on the mixer’s part, users have proof of an agreement between both parties to post on public forums. Warranties can be verified by publicly available information such as transactions or public keys. Thus, Mixcoin provides an incentive for mixers to operate in a trustworthy manner. The protocol assumes there are various mixers Mi, and each mixer has a warranty signing key KMi which is consistently used to sign warranties with each participant.
Thus, the mixer’s reputation relies heavily on the use of their key. Although accountability is achieved, the mixer can steal funds from its users and potentially leak permutations between inputs and outputs.
L. Valenta address Mixcoin’s susceptibility to permutation leak attacks with Blindcoin. Without any changes to the existing Bitcoin protocol, a blind signature scheme and an append-only public log are added onto the Mixcoin protocol. The user includes a blinded token consisting of their output address and a nonce in their initial offer to the mixing service.
The use of this token eliminates the threat of a permutation leak attack by the mixer operator. In addition, the mixing service is required to post this blinded token to an append only public log. As a result, Blindcoin ensures accountability while keeping the mapping of input to output addresses secret. However, Blindcoin does not prevent coin theft since the mixer can still steal funds from its users.
E. Heilman present TumbleBit, a unidirectional and unlinkable payment hub protocol. TumbleBit is completely compatible with the current Bitcoin protocol and relies on an untrusted centralized intermediary M to transfer funds between users. TumbleBit’s transactions are sent off-blockchain and are not affected by the latency issues in Bitcoin. These payments are essentially off-blockchain puzzles generated through interactions with M.
There were also many proposals that were brought up by community members to add a mixing feature directly inside the Bitcoin Core reference client. One of them, by the legendary Casascius, describes a simple relay where wallet-enabled Bitcoin nodes ask peers to send their list of transaction outputs. This is so they can make a CoinJoin transaction that both parties sign and broadcast.
If Bitcoin developers had implemented this idea, nobody would need a bitcoin mixer list because all of the mixing could be done directly on the bitcoin network. This never gained steam though, despite the many people bringing up the topic several times over the years. Now that we have SPV wallets, hardware wallets, and custodial exchanges, this might never come into fruition. Although, that is not really a bad thing, because some altcoins jumped at the chance to integrate it.
