Bitcoin mixing services have adopted techniques to evade detection and effectively obfuscate user funds.

Threats to these services and their user base exist. In response, the Bitcoin community and academic literature have proposed alternative methods to improve trust and eliminate these threats. In this chapter, we discuss the general architecture of four decentralized and four centralized proposed mixing protocols.

Decentralized

Decentralized mixing protocols strive to avoid the use of a third-party. While drawing inspiration from the mixing network presented , many of these mixing protocols propose shuffling of inputs and outputs to ensure unlinkability. In most of the following protocols, a decentralized method for users to find other participants (bootstrapping method) is assumed. In general, decentralized protocols suffer from limited scalability and long wait times to find mixing peers.

CoinJoin

CoinJoin is a method for multiple transactions, from multiple senders, to be combined into one. Without any modification to the current Bitcoin protocol, this technique makes it difficult for outside entities to identify the corresponding recipient for each input. Since Bitcoin’s inception, it has been generally assumed that all inputs to a transaction belong to the same user. However, CoinJoin transactions prove that this isn’t always the case. Users may collaborate to identify a uniform output amount 12 and combine their transactions into one. In turn, senders face lower transaction fees and lessen the load of transactions on the Bitcoin network. Additionally, participants of CoinJoin transactions do not face the risk of theft. This is due to the requirement that each participant must sign the transaction before it is considered valid.

CoinShuffle

The mixing protocol requires no third party, is compatible with the existing Bitcoin network, and uses CoinJoin to execute transactions. It is important to note that in Section of the authors state that the bootstrapping mechanism for users is a non-goal and the protocol assumes that users have a secure, decentralized method to express their interest in participation.

CoinShuffle is implemented in three phases: Announcement, Shuffling, and Transaction Verification. Figure illustrates a high-level view of the CoinShuffle protocol. In the Announcement phase, each participant generates a short-term encryption decryption key pair and broadcasts their encryption keys. In the Shuffling phase, the participants begin by generating a new Bitcoin address which serves as their output 14 address. Next, they shuffle these output addresses with a method similar to decryption mix networks .

The output of this phase is a shuffled set of output addresses, eliminating linkability between inputs and outputs. In the final Transaction Verification phase, each participant verifies that their generated output address exists in the shuffled list of output addresses. If so, a CoinJoin transaction is created including all of the inputs and the shuffled outputs. Each participant then signs the transaction and broadcasts it to the other users. Without signatures from each participant, the transaction is invalid. After all signatures are received, the transaction is ready to be sent to the network.

The use of a CoinJoin transaction allows for transaction fees to be split between all participants involved. The fee is less for each user and there are no separate mixing fees involved. Additionally, if a participant will require a change transaction, they may include a specific change address in the list of output addresses. Overall, CoinShuffle presents an effective decentralized protocol while making assumptions of methods for user communication. Due to these assumptions, the inclusion of a centralized, trusted authority is not completely ruled out.

CoinParty

Ziegeldorf et al. proposed CoinParty in 2015. The mixing protocol is executed in multiple one-to-one transactions and offers decentralization and security. While being completely compatible with the existing Bitcoin network, CoinParty uses Secure multi-party computation (SMC) for users to collaborate. CoinParty operates in three phases: Commitment, Shuffling, and Transaction. Figure 5.3 depicts the culmination of these phases with three participants. All n users have a specific, agreed upon amount of Bitcoin v at their input address (represented by I1…In). Each participant’s output address is represented by O1…On. At the end 15 of the protocol, each participant receives v Bitcoin to their respective output address. However, only participant i can link Ii and Oi together. To achieve unlinkability, a secret permutation, π is used such that Ii v−→ Oπ(i) .

During the Commitment phase, the participants send the required funds to a temporary escrow address Ti . Ti is created using a threshold ECDSA key pair and is expected to be precomputed by the participants. In order for the funds to leave the escrow address, the majority of mixing peers must collaborate, protecting the funds from theft by a malicious user. Before the next phase begins, all transactions to escrow addresses must have at least six confirmations. In the Address Shuffling phase, the random, secret permutation π is used to shuffle the set of output addresses. Using a process inspired by decryption mixnets, CoinParty maintains anonymity against both outsiders and participants.

The 16 process requires that each mixing peer encrypts and broadcasts their output address Oi . Encryption is done with the public keys of other participants K1…KM such that it results in a layered encryption EK1 (…(EKM (Oi)). This layered encryption is sent to each mixing peer in which they decrypt a layer, apply a permutation, and send to the next participant. After successful shuffling, the link between participants and their corresponding output address should be erased. The addresses are then sorted lexicographically by the final participant and a pseudorandom number generator is used to identify a final random permutation.

Checksums are used at each stage of the shuffling to ensure correctness. In the Transaction phase, the participants create transactions Ii v−→ Oπ(i) . These transactions must be collaboratively signed to be executed. A threshold variant of the ECDSA scheme is employed where transactions can be executed when 2/3 of the participants agree to do so.

Xim

Bissiaset al explore the threats presented by Sybil-based denial-of-service at-tacks to Bitcoin mixing services. In response, they present Xim, a two-party mixing implementation. Unlike the previously described methods, Xim provides a decentralized method for mixing participants to find each other. The complete protocol requires no changes to the existing Bitcoin implementation. The goal of Xim is to provide a method for parties to discover, partner, and exchange funds while providing unlinkability and fairness.The Xim protocol is done in two phases: Discovery and Fair Exchange.

The second phase of the protocol can be done with either Barber’s Fair Exchange Protocol or SMC in Bitcoin . Our analysis of Xim focuses on phase one, the discovery of a mixing partner. This phase depends heavily on an off-blockchain approach to anonymous messaging. 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.In the Discovery phase, participants randomly take on the role of the advertiser A or respondent R.

The advertiser A utilizes the TEXT field in a transaction ofτ/2to post an ad stating the anonymous messaging platform where they can be reached,a unique nonce, and the amount they desire to mix. Any communication sent to A over the messaging platform are encrypted with the public key used for the ad. Any responses by Rwill include the ad, a nonce, and an anonymous method at which they can be reached. When a respondent is selected,A posts a signed message containing their nonce and the hash ofR’s nonce.

This notifies that they have been selected.R then posts an ad via a transaction of sizeτwith the TEXT field containing the message posted by A encrypted with A’s public key. Finally, A publishes a responsead ofτ/2 with the hash ofR’s nonce. At the end of this phase, both parties have confirmed their interest in participating in a fair exchange using protocols outlined in.

Centralized

Centralized mixing protocols aim to secure a scheme in which an untrusted third-party exists. Mix participants meet and send their funds through these centralized services. The following mixing protocols attempt to address some of the threats discussed before.

Obscuro

Tranet al present 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 day-to-day activity of the service.To do so, the mixer code base is isolated from the rest of the system. Users are given the ability to verify the isolated functionalities 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. In [13], the authors use Intel Software Guard Extension (SGX) [25, 26].

Intel SGX allows applications to be run in a special memory region called anenclave. This region is isolated from the rest of the system’s software, including the operating system. Remote attestation is possible with the contents of the enclave to ensure they are performing the expected functionality. In runtime, the contents of the enclave are also encrypted. Thus, Intel SGX offers both integrity and confidentiality.

However, simply including a mixer’s functionality in an enclave does not protect the service from a malicious mixer operator. Mixer operators still have the ability to control the worldview of the service including participants and blockchain information.Obscuro addresses this issue and presents a highly secure TEE-based protocol.The main design goals for Obscuro include indirect deposits, a guaranteed mixing set size, and state-rewind resistance. In addition, this architecture guarantees refunds and resistance to IP-level de-anonymization.

Figure depicts Obscuro’s four phases (represented by 1, 2, 3, 4 respectively): Bootstrang, Indirect Participation,Block Scanning, and Final Announcement. The red fields indicate untrusted regions while green represent trusted regions of the architecture.

In the Bootstrapping phase,Obscuro generates a new public key (pubkeymixer)and address (addressmixer) for the mixer. Then the service postspubkey mixer,address mixer,and some metadata related to remote attestation onto public bulletin board(s). Next,the user retrieves this information from a bulletin board and uses a public remote at-testation service to ensure that the correct functions are loaded into the enclave. Any tampering or false information posted to bulletin boards would lead to a failure in re-mote attestation and bootstrapping to the mixing service. For this reason, Obscuro prevents malicious mixing operators from refusing service or reducing the number of benign users. Any false information would be public and result a self-inflicted Denial of Service attack by the mixing service, since no one would be able to participate.

The service then scans for transactions depositing to address mixer. For these transactions,the service decrypts the output address. In addition, Obscuro verifies the integrity of the scanned blockchain based on a recent checkpoint from the previous round’s scan.

This phase removes the need for interaction between the mixer and the user. In addition, the removal of benign users would require costly selectivity when scanning the blockchain.The Final Announcement phase does not begin until Obscuro receives a specified minimum number of participants.

When this minimum is reached, transaction TX is created including all of the deposits as inputs and output addresses as outputs. To ensure unlinkability, the output addresses are shuffled. Then, TX is broadcast to the network and the next mixing round begins.

Mixcoin

In the Indirect Participation phase, the user sends their deposit funds to addrmixer. The transaction tx also includes the user’s desired output address. In order to ensure the confidentiality of this output address, it is encrypted with pubkey mixer. This deposit is covered by the guaranteed refund mechanism such that if the funds are not mixed by a specific waiting time, the user is guaranteed a refund.During the Block Scanning phase, Obscuro downloads blockchain data. The service then scans for transactions depositing to address mixer. For these transactions,the service decrypts the output address. In addition, Obscuro verifies the integrity of the scanned blockchain based on a recent checkpoint from the previous round’s scan. This phase removes the need for interaction between the mixer and the user. In addition, the removal of benign users would require costly selectivity when scanning the blockchain.The Final Announcement phase does not begin until Obscuro receives a specified minimum number of participants. When this minimum is reached, transaction TX is created including all of the deposits as inputs and output addresses as outputs. To ensure unlinkability, the output addresses are shuffled. Then, TX is broadcast to the network and the next mixing round begins.

Mixcoin Bonneauet 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 like transactions or public keys. Thus, Mixcoin provides an incentive for mixers to operate in a trustworthy manner. The protocol assumes there are various mixers.

Each mixer has a warranty signing key KMiwhich is consistently used to sign warranties with each participant. Thus, the mixer’s reputation relies heavily on the use of their key.

The following parameters from are in the initial warranty that Alice proposes: value to be mixedt 1time by which A is required to sendv BTC to Mt2time by which M is to return funds to AK out out put address where A wants to send her fundsρmixing fee rate for Annonce for randomized feesωnumber of blocks required to confirm A’s payment If M agrees to the contents of the proposed warranty, it generates a new escrow address K esc and adds it to the warranty. M then signs the warranty with KM and sends it back to A (Step 2a). Step 2b depicts the case in which M rejects the terms of the warranty.After receiving the signed warranty from M,A is expected to send funds to K esc before timet1. If A does not, M can simply delete its records. Since, A did not abide by the warranty, there is no proof that M was malicious. If A does send the funds beforet1(Step 3), M is required to send an equal amount of funds to Koutbyt2.

However, there is the possibility that the funds can be retained by Mas a fee. This is done by calculating a random number via a Beacon function. If the random number is less than or equal to the agreed fee rate,M retains the funds. If the random number is greater than the fee rate and M sends the funds to K out beforet2 (Step 4a), both A and M can destroy their records and carry on after a successful mix. However, if M does not send the funds t o K out beforet2or steals the funds,A can publicize the warranty to prove that M is malicious (Step 4b). Although accountability is achieved, M is still able to steal funds from its users and potentially leak permutations between inputs and outputs.

Blindcoin

Valenta and Rowan address Mixcoin’s susceptibility to permutation leak at-tacks 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.Figure depicts the Blindcoin protocol. The protocol includes three entities: the mixer M, Alice A, and an append-only public log. Parametersv,K out, ρ, n, and ωare unchanged from Mixcoin. The following is the list of parameters newly added or redefined from the Mixcoin protocol.

In Step 1,A sends the mix parameters D to M. This offer includesv,t1,t2,t3,t4,ω, andρ. In addition, this initial offer includes a blinded token T which consists of Koutand non cen. The token is encrypted using AC, a commitment function which can only be decrypted by A. In Mixcoin, this blinded token was not included and allowed the mixing service to see K out and n. After receiving the offer,M may accept (Step 2a) and send back a partial warranty.This reply consists of T,D, and a unique escrow address K escall signed by Mpriv. In Mixcoin, the mixer sends the signed warranty back to A.

If M rejects the offer (Step2b), A can delete the output address and carry on. Steps 3a and 3b are unchanged from the Mixcoin protocol in which A is expected to send funds to K esc before timet1.In Step 4a, M completes the warranty by signing the blinded token with M priv and posting it to the public log byt2.

This serves as proof that A has sent funds to Mon time and can be verified by any third-party. However if M fails to complete the warranty, A can publish incriminating information publicly including the partial warranty and the transaction before t1.

Assuming that M successfully published the signed blinded token beforet2, A can use an anonymous identity A′to uncover the blinded token and repost it to the public log (Step 5). This action must be done by timet3orMis allowed to keep the funds. After this post by A′,M now knows K out. However, in this case all M has is a set of un blinded tokens available on the public log. M does not know their corresponding input addresses. Next, M can calculate the Beacon function for each to identify which inputs will be taken as fees. Fee calculation is the same in both Mixcoin and Blind coin. Finally, M is expected to pay to the output address before timet 4if they have passed the Beacon function. If M does not send the funds back in time,A has solid incriminating proof of a breach in protocol. This includes the partial warranty, the commitment function for the blinded token, the input transaction to Kesc, the signed token by M, and proof that the funds were not received byt4. As a result, Blindcoin ensures accountability while keeping the mapping of input to output addresses secret.However, Blindcoin does not prevent coin theft since M can still steal funds from its users.

TumbleBit

In, Heilmanet al. present TumbleBit, a unidirectional, 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 effected by the latency issues in Bitcoin. These payments are essentially off-blockchain puzzles generated through interactions with M.

TumbleBit consists of three phases (depicted in Figure 5.7). In this example, the protocol consists of three entities: Alice A, Bob B, and the Mixer M. During the Escrow phase,A sends her QBTC to an escrow address to open a payment channel with M. Next, for B to create a channel with M,M must first send QBTC to another escrow address. These escrow transactions are 2-of-2 escrow smart contacts,meaning funds can only be accesses by transactions signed by both parties of the payment channel. Next,Band M make use of a puzzle-promise protocol. This protocol creates up to Q puzzles for B.

In addition the puzzle-promise protocol is also a promise from M that B will receive one BTC for each solved puzzle. Each puzzle is an RSA encryption of a value.In the Payment phase, A makes up to Q payments to B. These payments are off-blockchain meaning A must interact with M to learn the solutions to puzzles that have been provided by B. To do so, Bob first chooses a puzzlez and blinds it to be ̄z.Blindingz ensures that M cannot linkzto ̄z. This blinded puzzle is then sent to Athrough M.

Next,A interacts with M to solve ̄z. The puzzle-solver protocol is used to execute a fair exchange such that A gives M one BTC if and only if M provides a valid solution ̄. When obtained, A sends ̄to B through M. This is repeated for Q′puzzles.In the final Cash-out phase Buses his Q′solved puzzles to obtain Q′BTC from M’s escrow address. M then obtains the remaining funds from its escrow and Q′BTC from A’s escrow address, leaving the rest for A to keep. Throughout this scheme,the participants do not need to interact with one an other and the mixer does not lose its initial amount of funds.