Mixcoin: Anonymity for Bitcoin with Accountable Mixes

Abstract

We propose Mixcoin, a protocol to facilitate anonymous payments in Bitcoin and similar cryptocurrencies. We build on the emergent phenomenon of currency mixes, adding an accountability mechanism to expose theft. We demonstrate that incentives of mixes and clients can be aligned to ensure that rational mixes will not steal. Our scheme is efficient and fully compatible with Bitcoin. Against a passive attacker, our scheme provides an anonymity set of all other users mixing coins contemporaneously. This is an interesting new property with no clear analog in better-studied communication mixes. Against active attackers our scheme offers similar anonymity to traditional communication mixes.

Appendices

A Continual Mixing

A more in-depth defense against some of the side-channel attacks introduced in Sect. 7.7 is continual mixing, which does not require advance notice of payments. In addition to avoiding the timing side channel, it actually increases Alice’s anonymity set. The core idea is that Alice continues mixing her coins until she is ready to spend them, but at a greatly reduced rate (e.g., one round per month). Let $\varDelta _A$ be a time period such that Alice is prepared to keep her coins for time $\varDelta _A$ between receiving them and spending them. Then the continual mixing algorithm for a chunk $c$ for which initial mixing completes at time $t_0$ is as follows:

• generate $\varDelta _{A,c} = U[0, \varDelta _A]$

• mix $c$ at time $\varDelta _{A,c}$ and thereafter at $\varDelta _A$ intervals

• mark $c$ as spendable after the first continual mix round.

It is easy to verify that regardless of the timings of the payments received by Alice, the distribution last mixing times for each of her spendable chunks is always $U[0, \varDelta _A]$. This nullifies the timing channel, except for the matter of picking $\varDelta _A$. If Alice makes a payment with a random subset of her spendable chunks, Eve can infer $\varDelta _A$ with high accuracy.

Picking $\varDelta$ involves a trade-off. From the point of view of a business, if $\varDelta$ is too high, it adds latency to the operating cycle and decreases cash flow. If $\varDelta$ is too low, it leads to a higher depreciation rate of long-term assets due to the mixing fees incurred by continual mixing. Further, clients must consider each others’ choices in picking $\varDelta$, since anonymity loves company and highly unusual values of $\varDelta$ will help Eve.

Given these constraints, we propose several globally fixed values of $\varDelta$: for instance, a day, a week, a month, and a quarter; each client is free to pick the value that best suits their operating patterns. Alice can now expect her anonymity set to be the set of all Mixcoin clients who have the same value of $\varDelta$.

Some inference attacks are hard to prevent with any mixing system. For example, if Alice owes Bob a highly unique amount of money, and neither Alice nor Bob transacts with any other users, this information is sufficient to link Alice’s outflow with Bob’s inflow. Unlikely as such situations are for most users in the real world, they pose a problem for analysis of anonymity of our system.

B Improving Mix Trustworthiness

If a mix cheats, the cheated client can ensure that the mix gets a poor reputation. But how can a mix build a reputation for trustworthiness? Even if there are no theft reports against it, it might simply be because the mix doesn’t have much volume yet. Further, to the extent that more popular mixes may offer better anonymity (Sect. 7.3), clients would like to estimate mix transaction volumes.

In this section we discuss ways to better measure, as well as prove, mix trustworthiness, and even a mechanism for recourse against cheating mixes. These are all “out-of-band” and do not require modifications to the Mixcoin protocol.

1.1 B.1 External Reputation

While some mix operators may choose to be anonymous, others may be comfortable revealing their real-world identity. A bank or trusted community member could leverage their external reputation to increase trust in their mix service.

1.2 B.2 Throttling

Throttling, or rate limiting by the client, lets Alice limit her exposure to a given mix at any given time. If Alice wants her maximum exposure to $M$ to be $E$, she transacts with $M$ at the average rate of $\frac{E}{\delta _\text {max}}$ per block, where $\delta _\text {max}$ is the maximum mix delay that she picks for $M$. If she stops transacting with $M$ as soon as she detects misbehavior, then $M$ can steal at most $E$ of her coins.

1.3 B.3 User Reports

To estimate volume, client users could publish through out-of-band channels, such as forums, logs containing aggregate statistics about their usage of various mixes (e.g., “Alice mixed 10,000 chunks through mix $M_1$ in August”). If these are reputable members of the community (for example, with longstanding active accounts), observers can be reasonably confident that they are not sybils. Such reports provide lower bounds on mix volume.

1.4 B.4 Mark and Recapture

The mark-and-recapture method for estimating wildlife populations (e.g., [14]) could be used to estimate a mix’s escrow reserves and hence its volume. The method involves engaging the mix in $n$ transactions over a short period, and observing what fraction of these get forwarded among the set of corresponding return transactions. If the transaction volume of the mix is $Q$, then at any time the escrow pool contains $Q$ transactions, and the expected number of corresponding returns is approximately $n/Q$ when $n$ is much smaller than $Q$. The mix may attempt to inflate this measurement by simulating transactions of sybil clients and contributing its own funds to the escrow pool. To defeat sybil detection by transacting with other mixes would incur fees proportional to the inflated volume. Thus, to inflate the apparent volume to twice the actual amount, the mix would have to forego its entire profits.