Skip to main content

Mixcoin: Anonymity for Bitcoin with Accountable Mixes

Part of the Lecture Notes in Computer Science book series (LNSC,volume 8437)

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.

Keywords

  • Chunk Size
  • Anonymous Communication
  • Block Chain
  • Passive Adversary
  • Honest Behavior

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

This is a preview of subscription content, access via your institution.

Buying options

Chapter
USD   29.95
Price excludes VAT (USA)
  • DOI: 10.1007/978-3-662-45472-5_31
  • Chapter length: 19 pages
  • Instant PDF download
  • Readable on all devices
  • Own it forever
  • Exclusive offer for individuals only
  • Tax calculation will be finalised during checkout
eBook
USD   79.99
Price excludes VAT (USA)
  • ISBN: 978-3-662-45472-5
  • Instant PDF download
  • Readable on all devices
  • Own it forever
  • Exclusive offer for individuals only
  • Tax calculation will be finalised during checkout
Softcover Book
USD   99.99
Price excludes VAT (USA)
Construction 1.

Notes

  1. 1.

    Bitcoin transactions may feature multiple inputs and outputs. Bitcoin also features a limited scripting language allowing more complicated transactions.

  2. 2.

    Some mixing services are only accessible as Tor hidden services.

  3. 3.

    Receiving one’s own coins back from a mix is not necessarily a vulnerability. This will happen with probability \(\frac{1}{N}\) in a random permutation of \(N\) participant’s coins.

  4. 4.

    Deadlines are specified as block numbers in the Bitcoin block chain, rather than clock times, to enable unambiguous auditing.

  5. 5.

    There is no way in Bitcoin to guarantee a transaction will be included in any specific block. Therefore in practice mixes will likely require a safety margin of several blocks to \(t_2\) to ensure they can include the transaction before that time.

  6. 6.

    Our motivation to use randomized fees is different from the case of micropayment systems, which do so to avoid transaction costs from many low-valued payments.

  7. 7.

    A mix might also be a miner, in which case it may attempt to influence the block. However, such an attack is highly uneconomical given the high reward for mining a block compared to mixing fees.

  8. 8.

    Though in practice \(w=6\) is a common standard, we include \(w\) as a negotiable parameter in the warranty to enable flexibility.

  9. 9.

    Some transactions are accepted today without fees, though miners may change this at any time, which may occur as the minting rate decreases.

  10. 10.

    In pipelined sequential mixing, which we will discuss in Sect. 5, most mixes will need only pay one transaction fee.

  11. 11.

    Unlike in traditional communication networks, an onion routing approach doesn’t seem possible due to the interactivity required in Mixcoin.

  12. 12.

    The exchange rate of bitcoins may of course be drastically different in the future. We assume mixes have no private information about the future value of bitcoins and therefore use its current market price in calculating the net present value.

  13. 13.

    This equivalence ignores the effects of compounding interest, though \(r\) and \(\bar{t}\) are both low enough that \((1+r)^{\bar{t}} \sim 1+r \bar{t}\).

  14. 14.

    In practice, absconding may be slightly more appealing due to super-exponential time discounting by the mix or the risk that business may decline.

  15. 15.

    Tor is notably not designed to withstand attack by a global passive adversary, as Tor relays provide no mixing of traffic [11].

  16. 16.

    Allowing different delays per client would open the possibility of free-riding and make anonymity analysis much more complex [12].

  17. 17.

    Non-uniform distributions such as an exponential distribution are possible, but they make it difficult to provide a firm bound on the delay as required by the warranty.

  18. 18.

    Because Alice must have already negotiated her mixing warranty for the next round, each warranty must be delayed by the maximum \(\delta _\text {max}\) blocks.

  19. 19.

    Note that the mixing fee rate \(\rho \) is unobservable and hence should have no impact on anonymity and can be chosen independently by different mixes.

  20. 20.

    For example, if chunk sizes \(\alpha \) and \(\beta \) are common, a user mixing \(x = k_1\alpha + k_2\beta \) will have her anonymity set limited to other users mixing at least \(k_1\) chunks of size \(\alpha \) and at least \(k_2\) of size \(\beta \), instead of all users mixing at least \(x\).

  21. 21.

    Additionally, with randomized mixing fees (see Sect. 4.4) users owning only a small multiple of \(v\) may face unacceptably high variance in their fee rate.

  22. 22.

    The Bitcoin community frowns on creating large numbers of low-value transactions (referred to as dust) because it places a higher verification burden on miners.

  23. 23.

    Network-level side channels are out of scope. As noted earlier, we assume that Mixcoin clients always communicate using a secure anonymity network such as Tor.

  24. 24.

    This is analogous to a packet counting attack in communication mixes.

  25. 25.

    This is analogous to an intersection attack in the mixing literature.

References

  1. NIST Randomness Beacon. http://www.nist.gov/itl/csd/ct/nist_beacon.cfm

  2. Androulaki, E., Karame, G.O., Roeschlin, M., Scherer, T., Capkun, S.: Evaluating user privacy in bitcoin. In: Sadeghi, A.-R. (ed.) FC 2013. LNCS, vol. 7859, pp. 34–51. Springer, Heidelberg (2013)

    CrossRef  Google Scholar 

  3. Barber, S., Boyen, X., Shi, E., Uzun, E.: Bitter to better — how to make bitcoin a better currency. In: Keromytis, A.D. (ed.) FC 2012. LNCS, vol. 7397, pp. 399–414. Springer, Heidelberg (2012)

    CrossRef  Google Scholar 

  4. Ben-Sasson, E., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., Virza, M.: Zerocash: decentralized anonymous payments from Bitcoin. In: IEEE Symposium on Security and Privacy (SP), 2014. IEEE (2014)

    Google Scholar 

  5. Chaum, D.: Untraceable electronic mail, return addresses, and digital pseudonyms. Commun. ACM 24(2), 84–90 (1981)

    CrossRef  Google Scholar 

  6. Chaum, D.: Blind signatures for untraceable payments. In: Chaum, D., Rivest, R.L., Sherman, A.T. (eds.) CRYPTO 1982, pp. 199–203. Springer, New York (1983)

    CrossRef  Google Scholar 

  7. Christin, N.: Traveling the silk road: a measurement analysis of a large anonymous online marketplace. In: Proceedings of the 22nd International Conference on World Wide Web, pp. 213–224. International World Wide Web Conferences Steering Committee (2013)

    Google Scholar 

  8. Clark, J., Hengartner, U.: On the use of financial data as a random beacon. In: Usenix EVT/WOTE (2010)

    Google Scholar 

  9. Danezis, G., Fournet, C., Kohlweiss, M., Parno, B.: Pinocchio coin: building zerocoin from a succinct pairing-based proof system. In: Language Support for Privacy-Enhancing Technologies (PETShop) (2013)

    Google Scholar 

  10. Dingledine, R., Mathewson, N.: Anonymity loves company: usability and the network effect. In: WEIS (2006)

    Google Scholar 

  11. Dingledine, R., Mathewson, N., Syverson, P.: Tor: The second-generation onion router. In: USENIX Security (2004)

    Google Scholar 

  12. Dingledine, R., Serjantov, A., Syverson, P.F.: Blending different latency traffic with alpha-mixing. In: Danezis, G., Golle, P. (eds.) PET 2006. LNCS, vol. 4258, pp. 245–257. Springer, Heidelberg (2006)

    CrossRef  Google Scholar 

  13. Golle, P.: Reputable mix networks. In: Martin, D., Serjantov, A. (eds.) PET 2004. LNCS, vol. 3424, pp. 51–62. Springer, Heidelberg (2005)

    CrossRef  Google Scholar 

  14. Jolly, G.M.: Explicit estimates from capture-recapture data with both death and immigration-stochastic model. Biometrika 52(1/2), 225–247 (1965)

    CrossRef  MATH  MathSciNet  Google Scholar 

  15. Kesdogan, D., Egner, J., Büschkes, R.: Stop-and-go-mixes providing probabilistic anonymity in an open system. In: Aucsmith, D. (ed.) IH 1998. LNCS, vol. 1525, pp. 83–98. Springer, Heidelberg (1998)

    CrossRef  Google Scholar 

  16. Kroll, J.A., Davey, I.C., Felten, E.W.: The economics of bitcoin mining, or bitcoin in the presence of adversaries. In: WEIS, June 2013

    Google Scholar 

  17. Maxwell, G.: CoinJoin: bitcoin privacy for the real world, August 2013. https://bitcointalk.org/index.php?topic=321228

  18. Maxwell, G.: CoinSwap: transaction graph disjoint trustless trading. CoinSwap:Transactiongraphdisjointtrustlesstrading (2013)

    Google Scholar 

  19. Meiklejohn, S., Pomarole, M., Jordan, G., Levchenko, K., McCoy, D., Voelker, G.M., Savage, S.: A fistful of bitcoins: characterizing payments among men with no names. In: IMC (2013)

    Google Scholar 

  20. Miers, I., Garman, C., Green, M., Rubin, A.D.: Zerocoin: anonymous distributed e-cash from bitcoin. In: IEEE Symposium on Security and Privacy (2013)

    Google Scholar 

  21. Möser, M.: Anonymity of bitcoin transactions: an analysis of mixing services. In: Proceedings of Münster Bitcoin Conference (2013)

    Google Scholar 

  22. Nakamoto, S.: Bitcoin: a peer-to-peer electionic cash system (2008)

    Google Scholar 

  23. Raymond, J.-F.: Traffic analysis: protocols, attacks, design issues, and open problems. In: Federrath, H. (ed.) Designing Privacy Enhancing Technologies. LNCS, vol. 2009, pp. 10–29. Springer, Heidelberg (2001)

    CrossRef  Google Scholar 

  24. Reid, F., Harrigan, M.: An analysis of anonymity in the bitcoin system. In: Altshuler, Y., Elovici, Y., Cremers, A.B., Aharony, N., Pentland, A. (eds.) Security and Privacy in Social Networks, pp. 197–223. Springer, New York (2013)

    CrossRef  Google Scholar 

  25. Rivest, R.: Electronic lottery tickets as micropayments. In: Hirschfeld, R. (ed.) FC 1997. LNCS, vol. 1318, pp. 307–314. Springer, Heidelberg (1997)

    CrossRef  Google Scholar 

  26. Ron, D., Shamir, A.: Quantitative analysis of the full bitcoin transaction graph. In: Sadeghi, A.-R. (ed.) FC 2013. LNCS, vol. 7859, pp. 6–24. Springer, Heidelberg (2013)

    CrossRef  Google Scholar 

  27. Sako, K., Kilian, J.: Receipt-free mix-type voting scheme. In: Guillou, L.C., Quisquater, J.-J. (eds.) EUROCRYPT 1995. LNCS, vol. 921, pp. 393–403. Springer, Heidelberg (1995)

    CrossRef  Google Scholar 

  28. Serjantov, A., Dingledine, R., Syverson, P.: From a trickle to a flood: active attacks on several mix types. In: Petitcolas, F.A.P. (ed.) IH 2002. LNCS, vol. 2578, pp. 36–52. Springer, Heidelberg (2003)

    CrossRef  Google Scholar 

Download references

Acknowledgments

We thank our anonymous referees and all who read drafts and contributed valuable suggestions to this work, especially Aaron Johnson, Ian Miers, Roger Dingledine, George Danezis, Peter Eckersley, Peter Todd and Eran Tromer. Joshua Kroll was supported by the National Science Foundation Graduate Research Fellowship Program under grant number DGE-1148900.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Joseph Bonneau .

Editor information

Editors and Affiliations

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.

Rights and permissions

Reprints and Permissions

Copyright information

© 2014 International Financial Cryptography Association

About this paper

Cite this paper

Bonneau, J., Narayanan, A., Miller, A., Clark, J., Kroll, J.A., Felten, E.W. (2014). Mixcoin: Anonymity for Bitcoin with Accountable Mixes. In: Christin, N., Safavi-Naini, R. (eds) Financial Cryptography and Data Security. FC 2014. Lecture Notes in Computer Science(), vol 8437. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-45472-5_31

Download citation

  • DOI: https://doi.org/10.1007/978-3-662-45472-5_31

  • Published:

  • Publisher Name: Springer, Berlin, Heidelberg

  • Print ISBN: 978-3-662-45471-8

  • Online ISBN: 978-3-662-45472-5

  • eBook Packages: Computer ScienceComputer Science (R0)