Bitcoin is the first widely-adopted digital currency. It enables near-instantaneous payments between any two Bitcoin users anywhere in the world, with negligible fees and no risk of reverted transactions.
Like all electronic payment systems, Bitcoin needs a mechanism to ensure the integrity of the transactions (e.g., to prevent a rogue user from paying the same digital "coin" to multiple merchants). Traditional electronic payment systems achieve this by relying on a trusted central party, such as a bank. Bitcoin avoids such centralized trust (and the overhead associated with it); instead, Bitcoin uses a distributed ledger, known as the block chain, to store users' transactions. The block chain is maintained and updated by consensus across the pool of (mutually-distrustful) participants, using an Internet protocol that is very hard to subvert.
Any user can, at any time, directly pay any other user, by broadcasting a payment transaction in the Bitcoin network. The recipient checks this transaction against prior ones in the block chain, to verify that the sent funds have a valid provenance and are not duplicated (i.e., spent multiple times).
Bitcoin suffers from a major limitation: because the block chain is public, the history of all payment transactions ever made is readily available to anyone. This is problematic because a payment transaction specifies not only the amount paid but also the payment's origin and destination addresses. Some users use a single address, which is revealed to anyone they send a payment to or accept a payment from. This compromises the privacy of consumers and merchants alike:
Many users mitigate the aforementioned problem by generating many different addresses to handle separate payments. However, doing so is not only awkward but also prone to analysis. Indeed, anyone can deduce from the block chain the transaction graph and use it to trace the history of a given payment --- even years after it occurred --- and possibly de-anonymize a user's addresses by linking them to a specific party in the real world. Such fears are not theoretical: an increasing body of research shows that de-anonymization is a real concern. (See, e.g., RM11, BBSU12, RS12, and MPJLMVS13.)
Thus, Bitcoin is, in many ways, less private than a bank account. With a bank, you only disclose your finances to the bank and its designees; with Bitcoin, you disclose them to the whole world.
Would you want to publish your bank statement for everyone to see? Of course not: your bank statement can reveal (besides obvious things like your salary) many other intimate details about your life. For example, your payments to a psychiatrist could reveal that you have a mental health issue.
Bitcoin's privacy problem is that Bitcoin makes precisely this kind of information public for the whole world to see. In fact, once marketing and advertising firms begin data-mining Bitcoin transactions in earnest, we can only imagine what privacy intrusions will arise because of patterns revealed by user spending habits.
Data mining the block chain for user information is not a far-fetched scenario. While Bitcoin's usage is not yet sufficiently widespread to see what one might do with information revealed by the block chain, we can look at what one can already do with purchase histories and get an idea of what is yet to come.
The New York Times reported that Target can predict very personal information from user shopping habits. In one extreme example, data analysts working for the store were able to predict that certain female shoppers were pregnant, even before the women themselves were aware of it. Worse, the resulting coupons for baby products that were sent in the mail could reveal the pregnancy to others. The article mentions a father who discovered his teenage daughter's pregnancy from such coupons.
Of course, Target knew exactly what people were purchasing, which is more than just the charge amount and merchant name that you would get from a bank statement or Bitcoin's block chain. On the other hand, Target's analysts had only data from Target --- the analysts' job would have been easier if, in addition to purchase history at Target, the analysts also saw payments to ultrasound clinics and OBGYNs.
The point is two-fold: (1) seemingly inconsequential data can reveal very private information; and (2) companies have incentives to mine this kind of data and extract that information. Thus, it is very desirable for users to keep their finances private.
The provenance of your money should be kept private to ensure its fungibility.
If your money has a history, it may not be "valid for all debts, public and private", because someone may not like where it came from. To a limited extent this has already become an issue within Bitcoin: a number of Bitcoin exchanges have "blacklisted" certain coins following major wallet thefts. While this form of coin marking seems harmless -- and even beneficial -- it creates an added burden on users to verify the provenance of received payments.
Moreover, marking coins opens the gate to more discretionary, and questionable, practices. Imagine, when purchasing something at a store, that the cashier refuses to accept your money because some previous owner of the currency has used the coin to conduct an illegal (or merely controversial) transaction. Now, through no fault of your own, you find that your money is worth less than you expected. With cash, a credit card, or a debit card, this is not possible because neither the cashier nor the merchant can see where you got the money from. With Bitcoin, this information is easy to look up.
Users with sufficient motivation can make use of mixes (also known as laundries or tumblers) to enhance their own privacy. A mix allows users to entrust a set of coins to a pool operated by a central party and then, after some interval, retrieve different coins (with the same total value) from the pool; this operation further obfuscates transaction history.
Mixes, however, suffer from several limitations. First, users must wait to reclaim their coins, in order to allow enough coins to be mixed in the same pool (because the privacy enhancement is only as good as the pool size). Second, users must trust the mix to not steal or trace their coins. Third, users need to actively participate in a mix in order to ensure continuing privacy enhancement.
While typical legitimate users worry about their own privacy, they are also risk-averse, do not wish to expend continual effort in protecting their privacy, and are often not sufficiently aware that their privacy has been compromised. Mixes in particular are not an adequate solution because they entail substantial costs, ongoing risks and effort. (In contrast, for users with "something to hide", e.g. criminals, using mixes might be worth the risks and inconvenience.)
Thus, to protect their day-to-day privacy, legitimate users need an instant, risk-free, and, most importantly, automatic guarantee that data revealing their spending habits and account balances is not publicly accessible by neighbors, co-workers, and merchants.
Zerocash guarantees users' privacy by providing "Zerocash payment transactions" that do not reveal the payment's origin, destination, or amount of any transaction. Any transaction is recorded in the ledger as a random-looking string that suffices to ensure the monetary invariants, yet is zero-knowledge: it reveals nothing beyond the fact that, somewhere, some valid transaction occurred.
Zerocash improves on Zerocoin, work by some of the same authors, both in functionality (Zerocoin only hides a payment's origin) and in efficiency (Zerocash transactions are less than 1KB and take less than 6ms to verify.)
Zerocash is a novel cryptographic payment scheme that creates a separate anonymous currency, existing alongside a (non-anonymous) base currency, which we refer to as Basecoin. Each user can convert (non-anonymous) basecoins into (anonymous) Zerocash coins, which we call zerocoins. Users can then send zerocoins to other users, and split or merge zerocoins they own in any way that preserves the total value. Users can also convert zerocoins back into basecoins, though in principle this is not necessary: all transactions can be made in terms of zerocoins, if the parties involved support these.
(Note: Basecoin, which is the generic name we use for the non-anonymous currency in an altcoin implementing the Zerocash protocol, should not be confused with Bitcoin, which instead we typically use to denote the Bitcoin protocol and codebase that underlies many altcoins, including the currency with the name "Bitcoin".)
Zerocash's functionality is realized using just two new types of transactions, mint transactions and pour transactions, which are broadcast and appended to the ledger.
Mint transactions. A mint transaction allows a user to convert a specified number of basecoins (from some Basecoin address) into the same number of zerocoins belonging to a specified Zerocash address. The mint transaction itself consists of a cryptographic commitment to a new coin, which specifies its value and owner address.
Pour transactions. A pour transaction allows a user to make a private payment, by consuming some number of coins (owned by this user) in order to produce new coins. Roughly, a pour transaction, for two input coins and two output coins, involves proving, in zero knowledge, that:
The pour transaction consumes the input coins by revealing their serial numbers, but does not reveal any other information such as the values of the input or output coins, or the addresses of their owner.
Optionally, the pour transaction can also output some (non-anoymous) basecoins, subject to the constraint that the total output value equal the total input value.
For a mint transaction, the commitment cointained therein is constructed so that that anyone can verify that the committed coin has the claimed value.
For a pour transaction, anyone can verify that the zero-knowledge proof contained therein is valid (and that a few other simple invariants hold). For efficiency, however, Zerocash does not use "any" zero-knowledge proof, but leverages zero-knowledge Succinct Non-interactive ARguments of Knowledge (zk-SNARK) systems, which are zero-knowledge proofs that are particularly short and easy to verify. Specifically, Zerocash uses zk-SNARKs constructed by SCIPR Lab described in BCTV13; such proofs are less than 300 bytes long and can be verified in only a few milliseconds.
We do not plan to deploy Zerocash in Bitcoin but, rather, we plan to release an altcoin that uses the Zerocash protocol. At present, we are working on finishing a first release of the client software, based on the Bitcoin 0.9.1 codebase. (There is a big difference between research software, and a clean implementation that is working and usable!) Ultimately, we hope to achieve a production-quality client that can be used to create a real privacy-preserving currency.
For updates, follow @ZerocashProject on Twitter or check this website.
Zerocash's privacy guarantees are designed to benefit legitimate users who do not want their financial details made public. There is a concern, as always, that decentralized anonymous payments will facilitate laundering of ill-gotten funds by criminal users. As we now explain, however, Zerocash barely affects the status quo for criminal users, who already have strong incentives to hide their activity, while it provides notable benefits to legitimate users.
First, the main difficulty with money laundering does not typically lie in how to privately transfer money from one person to another, but in how to make the eventual income appear legitimate: for regulatory purposes, one still has to present credible sources to justify the income, regardless of the technical means by which it was transferred. In this respect, Zerocash does not help.
Second, even without the "help" of Zerocash, criminal users can already anonymize their activities via existing financial systems (e.g., by using cash) or Bitcoin (e.g., by using mixes). Thus, the introduction of yet another method to anonymously move money is of little consequence.
Finally, Bitcoin is increasingly subject to regulation that narrows the gap between it and traditional financial systems. For instance, Bitcoin exchanges are required to identify customers conducting sufficiently-large transfers to/from traditional currencies. Presumably such regulations would apply to Zerocash exchanges as well.
Zerocash extensions can accommodate various choices of balance between accountability and privacy.
For instance, there are promising techniques for preventing money laundering without violating the privacy of legitimate users (e.g., CHL06). Roughly, the idea is to build the cryptographic protocol so that, once the total amount paid between any two users (over any number of payments) exceeds some public threshold, the payments are not private. Zerocash could incorporate such techniques (though the initial prototype does not do so).
More generally, the underlying zk-SNARK cryptographic proof machinery is flexible enough to enforce a wide range of policies. It can, for example, let users prove that they paid the taxes due on all transactions, without revealing those transactions, their amounts, or even the amount of taxes paid. As long as the policy can be specified by efficient "nondeterministic" computation, it can (in principle) be enforced using zk-SNARKs and added to Zerocash. This can help to verify and enforce a wide range of compliance and regulatory policies in a manner that is non-invasive to privacy. Morever, once codified, policies will be enforced even in the presence of corrupt employees among the authorities.
This raises intriguing research, policy, and engineering questions over what policies are desirable and practically realizable.
Zerocash requires a trusted entity to conduct a one-time setup of the parameters of the system. During the setup procedure, secret random bits are drawn and used to compute the public parameters; the random bits are then destroyed, and the parameters are broadcast. If done correctly, then no secrets or backdoors remain.
If this setup procedure were to be corrupted, the system would continue to provide anonymity guarantees, but it would be possible to "forge" coins. As long as this setup procedure is conducted honestly, it is not possible to corrupt the public parameters of the system.
A different question is the possibility of bugs in the code. Such bugs need to be found and resolved via extensive review and testing, as in any other software project. To facilitate this, Zerocash will be released as open-source software.