Bitcoin Mixing Solutions
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 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 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.
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 encryptiondecryption 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.
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 atleast 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.
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 mixingimplementation. Unlike the previously described methods, Xim provides a decen-tralized method for mixing participants to find each other. The complete protocolrequires no changes to the existing Bitcoin implementation. The goal of Xim is toprovide a method for parties to discover, partner, and exchange funds while providingunlinkability and fairness.The Xim protocol is done in two phases: Discovery and Fair Exchange.
The secondphase 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 discoveryof 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 partnersmake Sybil attacks difficult.In the Discovery phase, participants randomly take on the role of the advertiserAor respondentR.
The advertiserAutilizes 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 toAover the messaging platform are encrypted with the public key used for the ad. Anyresponses byRwill include the ad, a nonce, and an anonymous method at which theycan be reached. When a respondent is selected,Aposts a signed message containingtheir nonce and the hash ofR’s nonce.
This notifies that they have been selected.Rthen posts an ad via a transaction of sizeτwith the TEXT field containing themessage posted byAencrypted withA’s public key. Finally,Apublishes a responsead ofτ/2 with the hash ofR’s nonce. At the end of this phase, both parties haveconfirmed their interest in participating in a fair exchange using protocols outlinedin.
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.
Tranet al present a centralized Bitcoin mixer using Trusted ExecutionEnvironments (TEEs).Obscuroaddresses 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 codebase is isolated from the rest of the system. Users are giventhe ability to verify the isolated functionalities and are guaranteed a large mixing setsize.Obscuro’s implementation requires no changes to the existing Bitcoin networkand is generic such that it can be implemented with any TEE technique. In , theauthors 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 theoperating system. Remote attestation is possible with the contents of the enclave toensure they are performing the expected functionality. In runtime, the contents of theenclave are also encrypted. Thus, Intel SGX offers both integrity and confidentiality.
However, simply including a mixer’s functionality in an enclave does not protectthe service from a malicious mixer operator. Mixer operators still have the ability tocontrol the worldview of the service including participants and blockchain information.Obscuroaddresses this issue and presents a highly secure TEE-based protocol.The main design goals for Obscuroinclude indirect deposits, a guaranteed mixingset size, and state-rewind resistance. In addition, this architecture guarantees refundsand resistance to IP-level de-anonymization.
Figure depictsObscuro’s fourphases (represented by 1, 2, 3, 4 respectively): Bootstrapping, Indirect Participation,Block Scanning, and Final Announcement. The red fields indicate untrusted regionswhile green represent trusted regions of the architecture.
In the Bootstrapping phase,Obscurogenerates a new public key (pubkeymixer)and address (addressmixer) for the mixer. Then the service postspubkeymixer,addressmixer,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. Anytampering 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,Obscuroprevents malicious mixing operators from refusing service or reducing the number ofbenign users. Any false information would be public and result a self-inflicted Denialof Service attack by the mixing service, since no one would be able to participate.
In the Indirect Participation phase, the user sends their deposit funds toaddrmixer.The transactiontxalso includes the user’s desired output address. In order to ensurethe confidentiality of this output address, it is encrypted withpubkeymixer. Thisdeposit is covered by the guaranteed refund mechanism such that if the funds are notmixed by a specific waiting time, the user is guaranteed a refund.During the Block Scanning phase,Obscurodownloads blockchain data.
The service then scans for transactions depositing toaddressmixer. For these transactions,the service decrypts the output address. In addition,Obscuroverifies the integrityof the scanned blockchain based on a recent checkpoint from the previous round’sscan.
This phase removes the need for interaction between the mixer and the user. Inaddition, the removal of benign users would require costly selectivity when scanningthe blockchain.The Final Announcement phase does not begin untilObscuroreceives a specifiedminimum number of participants.
When this minimum is reached, transaction TX iscreated including all of the deposits as inputs and output addresses as outputs. Toensure unlinkability, the output addresses are shuffled. Then, TX is broadcast to thenetwork and the next mixing round begins.
In the Indirect Participation phase, the user sends their deposit funds to addrmixer. The transactiontx also includes the user’s desired output address. In order to ensurethe 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’sscan. This phase removes the need for interaction between the mixer and the user. Inaddition, the removal of benign users would require costly selectivity when scanningthe blockchain.The Final Announcement phase does not begin untilObscuroreceives a specifiedminimum number of participants. When this minimum is reached, transaction TX iscreated including all of the deposits as inputs and output addresses as outputs. Toensure unlinkability, the output addresses are shuffled. Then, TX is broadcast to thenetwork and the next mixing round begins.
Mixcoin Bonneauet propose Mixcoin, a Bitcoin mixing protocol that provide saccountability to expose malicious centralized mixers. To do so, signed warrantiesare implemented between the participants and the service. If any wrongdoing occurson the mixer’s part, users have proof of an agreement between both parties to poston public forums. Warranties can be verified by publicly available information liketransactions or public keys. Thus, Mixcoin provides an incentive for mixers to operatein a trustworthy manner. The protocol assumes there are various mixers.
Each mixer has a warranty signing key KMiwhich is consistently used to sign warrantieswith 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 sendvBTC to Mt2time by which Mis to return funds to AK out out put address where Awants to send her fundsρmixing fee rate forAnnonce for randomized feesωnumber of blocks required to confirm A’s payment If Magrees 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 toA(Step 2a). Step 2b depicts the case in which M rejects the terms of the warranty.After receiving the signed warranty fromM,Ais expected to send funds to Kesc before timet1. If Adoes not,Mcan simply delete its records. Since,Adid not abideby the warranty, there is no proof that Mwas malicious. IfAdoes send the funds beforet1(Step 3),Mis 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,Mretains the funds. If the random number is greater than the fee rate and Msends the funds to Kout beforet2(Step 4a), both A and M can destroy their records and carry on after a successful mix. However, ifMdoes not send the funds t oKout beforet2or steals the funds,A can publicize the warranty to prove that Mis malicious (Step 4b). Although accountability is achieved, Mis still able to steal funds from its users and potentially leak permutations between inputs and outputs.
Valenta and Rowan address Mixcoin’s susceptibility to permutation leak at-tacks with Blindcoin. Without any changes to the existing Bitcoin protocol, a blindsignature scheme and an append-only public log are added onto the Mixcoin protocol.Figure depicts the Blindcoin protocol. The protocol includes three entities: themixerM, AliceA, and an append-only public log. Parametersv,Kout,ρ,n, andωare unchanged from Mixcoin. The following is the list of parametersnewly 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 byA. In Mixcoin, this blinded token was not included andallowed the mixing service to seeKoutandn.After receiving the offer,M may accept (Step 2a) and send back a partial warranty.This reply consists ofT,D, and a unique escrow address K escall signed by Mpriv. In Mixcoin, the mixer sends the signed warranty back to A.
If Mrejects the offer (Step2b),Acan delete the output address and carry on. Steps 3a and 3b are unchangedfrom the Mixcoin protocol in whichAis expected to send funds to Kesc before timet1.In Step 4a, M completes the warranty by signing the blinded token withMprivand 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 Mfails to complete the warranty,Acan publish incriminating information publicly including the partia lwarranty and the transaction before t1.
Assuming that M successfully published the signed blinded token beforet2,Acan use an anonymous identityA′to uncover the blinded token and repost it to the public log (Step 5). This action must be done by timet3orMis allowed to keepthe funds. After this post byA′,M now knowsKout. However, in this case al lMhas is a set of un blinded tokens available on the public log. M does not know their corresponding input addresses. Next,Mcan 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,Mis expected to pay to the output address before timet 4if they have passed the Beacon function. If Mdoes 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 byM, and proof that the funds were not received byt4. As a result, Blindcoinensures 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 itsusers.
In, Heilmanet al. present TumbleBit, a unidirectional, unlinkable payment hub protocol. TumbleBit is completely compatible with the current Bitcoin protocoland 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 areoff-blockchain meaning A must interact with M to learn the solutions to puzzles that have been provided byB. 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 toAthroughM.
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 Mprovidesa valid solution ̄. When obtained,Asends ̄toBthrough M. This is repeated forQ′puzzles.In the final Cash-out phase Buses hisQ′solved puzzles to obtain Q′BTC from M’s escrow address. M then obtains the remaining funds from its escrow andQ′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 another and the mixer does not lose its initial amount of funds.