Zerocoin: Anonymous Distributed E-Cash from Bitcoin

Ian Miers, Christina Garman, Matthew Green, Aviel D. RubinThe Johns Hopkins University Department of Computer Science, Baltimore, USA

{imiers, cgarman, mgreen, rubin}@cs.jhu.edu

AbstractBitcoin is the first e-cash system to see widespreadadoption. While Bitcoin offers the potential for new types offinancial interaction, it has significant limitations regardingprivacy. Specifically, because the Bitcoin transaction log iscompletely public, users privacy is protected only through theuse of pseudonyms. In this paper we propose Zerocoin, a crypto-graphic extension to Bitcoin that augments the protocol to allowfor fully anonymous currency transactions. Our system usesstandard cryptographic assumptions and does not introducenew trusted parties or otherwise change the security model ofBitcoin. We detail Zerocoins cryptographic construction, itsintegration into Bitcoin, and examine its performance both interms of computation and impact on the Bitcoin protocol.

I. INTRODUCTION

Digital currencies have a long academic pedigree. As ofyet, however, no system from the academic literature hasseen widespread use. Bitcoin, on the other hand, is a viabledigital currency with a market capitalization valued at morethan $100 million [1] and between $2 and $5 million USDin transactions a day [2]. Unlike many proposed digitalcurrencies, Bitcoin is fully decentralized and requires nocentral bank or authority. Instead, its security depends on adistributed architecture and two assumptions: that a majorityof its nodes are honest and that a substantive proof-of-work can deter Sybil attacks. As a consequence, Bitcoinrequires neither legal mechanisms to detect and punish doublespending nor trusted parties to be chosen, monitored, orpoliced. This decentralized design is likely responsible forBitcoins success, but it comes at a price: all transactionsare public and conducted between cryptographically bindingpseudonyms.

While relatively few academic works have considered theprivacy implications of Bitcoins design [2, 3], the preliminaryresults are not encouraging. In one example, researcherswere able to trace the spending of 25,000 bitcoins that wereallegedly stolen in 2011 [3, 4]. Although tracking stolen coinsmay seem harmless, we note that similar techniques couldalso be applied to trace sensitive transactions, thus violatingusers privacy. Moreover, there is reason to believe thatsophisticated results from other domains (e.g., efforts to de-anonymize social network data using network topology [5])will soon be applied to the Bitcoin transaction graph.

Since all Bitcoin transactions are public, anonymoustransactions are necessary to avoid tracking by third partieseven if we do not wish to provide the absolute anonymity

typically associated with e-cash schemes. On top of suchtransactions, one could build mechanisms to partially orexplicitly identify participants to authorized parties (e.g.,law enforcement). However, to limit this information toauthorized parties, we must first anonymize the underlyingpublic transactions.

The Bitcoin community generally acknowledges theprivacy weaknesses of the currency. Unfortunately, theavailable mitigations are quite limited. The most commonrecommendation is to employ a laundry service whichexchanges different users bitcoins. Several of these are incommercial operation today [6, 7]. These services, however,have severe limitations: operators can steal funds, track coins,or simply go out of business, taking users funds with them.Perhaps in recognition of these risks, many services offershort laundering periods, which lead to minimal transactionvolumes and hence to limited anonymity.

Our contribution. In this paper we describe Zerocoin, adistributed e-cash system that uses cryptographic techniquesto break the link between individual Bitcoin transactionswithout adding trusted parties. To do this, we first definethe abstract functionality and security requirements of a newprimitive that we call a decentralized e-cash scheme. We nextpropose a concrete instantiation and prove it secure understandard cryptographic assumptions. Finally, we describethe specific extensions required to integrate our protocolinto the Bitcoin system and evaluate the performance of aprototype implementation derived from the original open-source bitcoind client.

We are not the first to propose e-cash techniques forsolving Bitcoins privacy problems. However, a commonproblem with many e-cash protocols is that they relyfundamentally on a trusted currency issuer or bank, whocreates electronic coins using a blind signature scheme.One solution (attempted unsuccessfully with Bitcoin [8])is to simply appoint such a party. Alternatively, one candistribute the responsibility among a quorum of nodes usingthreshold cryptography. Unfortunately, both of these solutionsintroduce points of failure and seem inconsistent with theBitcoin network model, which consists of many untrustednodes that routinely enter and exit the network. Moreover, theproblem of choosing long-term trusted parties, especially inthe legal and regulatory grey area Bitcoin operates in, seemslike a major impediment to adoption. Zerocoin eliminates

Block N

Block N

Block 1 Block 2 ... Block N

Block 1 Block 2 ... Block N

Bitcoin Zerocoin Mint Zerocoin Spend

(a)

(b)

Figure 1: Two example block chains. Chain (a) illustrates a normal Bitcoin transaction history, with each transaction linkedto a preceding transaction. Chain (b) illustrates a Zerocoin chain. The linkage between mint and spend (dotted line) cannotbe determined from the block chain data.

the need for such coin issuers by allowing individual Bitcoinclients to generate their own coins provided that theyhave sufficient classical bitcoins to do so.

Intuition behind our construction. To understand the intuitionbehind Zerocoin, consider the following pencil and paperprotocol example. Imagine that all users share access toa physical bulletin board. To mint a zerocoin of fixeddenomination $1, a user Alice first generates a random coinserial number S, then commits to S using a secure digitalcommitment scheme. The resulting commitment is a coin,denoted C, which can only be opened by a random numberr to reveal the serial number S. Alice pins C to the publicbulletin board, along with $1 of physical currency. All userswill accept C provided it is correctly structured and carriesthe correct sum of currency.

To redeem her coin C, Alice first scans the bulletin boardto obtain the set of valid commitments (C1, . . . , CN ) thathave thus far been posted by all users in the system. She nextproduces a non-interactive zero-knowledge proof pi for thefollowing two statements: (1) she knows a C (C1, . . . , CN )and (2) she knows a hidden value r such that the commitmentC opens to S. In full view of the others, Alice, using adisguise to hide her identity,1 posts a spend transactioncontaining (S, pi). The remaining users verify the proof piand check that S has not previously appeared in any otherspend transaction. If these conditions are met, the users allow

1Of course, in the real protocol Alice will emulate this by using ananonymity network such as Tor [9].

Alice to collect $1 from any location on the bulletin board;otherwise they reject her transaction and prevent her fromcollecting the currency.

This simple protocol achieves some important aims. First,Alices minted coin cannot be linked to her retrieved funds:in order to link the coin C to the the serial number S usedin her withdrawal, one must either know r or directly knowwhich coin Alice proved knowledge of, neither of which arerevealed by the proof. Thus, even if the original dollar billis recognizably tainted (e.g., it was used in a controversialtransaction), it cannot be linked to Alices new dollar bill.At the same time, if the commitment and zero-knowledgeproof are secure, then Alice cannot double-spend any coinwithout re-using the serial number S and thus being detectedby the network participants.

Of course, the above protocol is not workable: bulletinboards are a poor place to store money and critical informa-tion. Currency might be stolen or serial numbers removedto allow double spends. More importantly, to conduct thisprotocol over a network, Alice requires a distributed digitalbacking currency.2

The first and most basic contribution of our work isto recognize that Bitcoin answers all of these concerns,providing us with a backing currency, a bulletin board, anda conditional currency redemption mechanism. Indeed, thecore of the Bitcoin protocol is the decentralized calculation

2One could easily imagine a solution based on existing payment networks,e.g., Visa or Paypal. However, this would introduce the need for trustedparties or exchanges.

of a block chain which acts as a trusted, append-onlybulletin board that can both store information and processfinancial transactions. Alice can add her commitments andescrow funds by placing them in the block chain whilebeing assured that strict protocol conditions (and not hercolleagues scruples) determine when her committed fundsmay be accessed.

Of course, even when integrated with the Bitcoin blockchain, the protocol above has another practical challenge.Specifically, it is difficult to efficiently prove that a commit-ment C is in the set (C1, . . . , CN ). The naive solution is toprove the disjunction (C = C1) (C = C2) . . . (C =CN ). Unfortunately such OR proofs have size O(N),which renders them impractical for all but small values ofN .

Our second contribution is to solve this problem, producinga new construction with proofs that do not grow linearly asN increases. Rather than specifying an expensive OR proof,we employ a public one-way accumulator to reduce thesize of this proof. One-way accumulators [10, 11, 12, 13, 14],first proposed by Benaloh and de Mare [10], allow parties tocombine many elements into a constant-sized data structure,while efficiently proving that one specific value is containedwithin the set. In our construction, the Bitcoin network com-putes an accumulator A over the commitments (C1, . . . , CN ),along with the appropriate membership witnesses for eachitem in the set. The spender need only prove knowledge ofone such witness. In practice, this can reduce the cost of thespenders proof to O(log N) or even constant size.

Our application requires specific properties from theaccumulator. With no trusted parties, the accumulator andits associated witnesses must be publicly computable andverifiable (though we are willing to relax this requirementto include a single, trusted setup phase in which parametersare generated). Moreover, the accumulator must bind eventhe computing party to the values in the set. Lastly, theaccumulator must support an efficient non-interactive witness-indistinguishable or zero-knowledge proof of set membership.Fortunately such accumulators do exist. In our concreteproposal of Section IV we use a construction based on theStrong RSA accumulator of Camenisch and Lysyanskaya [12],which is in turn based on an accumulator of Baric andPfitzmann [11] and Benaloh and de Mare [10].

Outline of this work. The rest of this paper proceeds asfollows. In Section II we provide a brief technical overviewof the Bitcoin protocol. In Section III we formally definethe notion of decentralized e-cash and provide correctnessand security requirements for such a system. In Section IVwe give a concrete realization of our scheme based onstandard cryptographic hardness assumptions including theDiscrete Logarithm problem and Strong RSA. Finally, inSections V, VI, and VII, we describe how we integrate oure-cash construction into the Bitcoin protocol, discuss the

security and anonymity provided, and detail experimentalresults showing that our solution is practical.

II. OVERVIEW OF BITCOIN

In this section we provide a short overview of the Bitcoinprotocol. For a more detailed explanation, we refer the readerto the original specification of Nakamoto [15] or to thesummary of Barber et al. [2].

The Bitcoin network. Bitcoin is a peer-to-peer network ofnodes that distribute and record transactions, and clients usedto interact with the network. The heart of Bitcoin is theblock chain, which serves as an append-only bulletin boardmaintained in a distributed fashion by the Bitcoin peers.The block chain consists of a series of blocks connected ina hash chain.3 Every Bitcoin block memorializes a set oftransactions that are collected from the Bitcoin broadcastnetwork.

Bitcoin peers compete to determine which node willgenerate the next canonical block. This competition requireseach node to solve a proof of work based on identifyingspecific SHA-256 preimages, specifically a block B suchthat SHA256(SHA256(B)) = (0`||{0, 1}256`).4 The value` is selected by a periodic network vote to ensure that onaverage a block is created every 10 minutes. When a peergenerates a valid solution, a process known as mining, itbroadcasts the new block to all nodes in the system. If theblock is valid (i.e., all transactions validate and a valid proofof work links the block to the chain thus far), then the newblock is accepted as the head of the block chain. The processthen repeats.

Bitcoin provides two separate incentives to peers that minenew blocks. First, successfully mining a new block (whichrequires a non-trivial computational investment) entitles thecreator to a reward, currently set at 25 BTC.5 Second, nodeswho mine blocks are entitled to collect transaction fees fromevery transaction they include. The fee paid by a giventransaction is determined by its author (though miners mayexclude transactions with insufficient fees or prioritize highfee transactions).

Bitcoin transactions. A Bitcoin transaction consists of a setof outputs and inputs. Each output is described by the tuple(a, V ) where a is the amount, denominated in Satoshi (onebitcoin = 109 Satoshi), and V is a specification of who isauthorized to spend that output. This specification, denotedscriptPubKey, is given in Bitcoin script, a stack-based non-Turing-complete language similar to Forth. Transaction inputs

3For efficiency reasons, this chain is actually constructed using a hashtree, but we use the simpler description for this overview.

4Each block includes a counter value that may be incremented until thehash satisfies these requirements.

5The Bitcoin specification holds that this reward should be reduced everyfew years, eventually being eliminated altogether.

Input: Previous tx: 030b5937d9f4aaa1a3133b... Index: 0 scriptSig: 0dcd253cdf8ea11cdc710e5e92af7647...

Output: Value: 5000000000 scriptPubKey: OP_DUP OP_HASH160 a45f2757f94fd2337ebf7ddd018c11a21fb6c283 OP_EQUALVERIFY OP_CHECKSIG

Figure 2: Example Bitcoin transaction. The output scriptspecifies that the redeeming party provide a public key thathashes to the given value and that the transaction be signedwith the corresponding private key.

are simply a reference to a previous transaction output,6

as well as a second script, scriptSig, with code and datathat when combined with scriptPubKey evaluates to true.Coinbase transactions, which start off every block and payits creator, do not include a transaction input.

To send d bitcoins to Bob, Alice embeds the hash7 ofBobs ECDSA public key pk b, the amount d, and some scriptinstructions in scriptPubKey as one output of a transactionwhose referenced inputs total at least d bitcoins (see Figure 2).Since any excess input is paid as a transaction fee to the nodewho includes it in a block, Alice typically adds a secondoutput paying the surplus change back to herself. Once thetransaction is broadcasted to the network and included ina block, the bitcoins belong to Bob. However, Bob shouldonly consider the coins his once at least five subsequentblocks reference this block.8 Bob can spend these coins ina transaction by referencing it as an input and including inscriptSig a signature on the claiming transaction under sk band the public key pk b.

Anonymity. Anonymity was not one of the design goalsof Bitcoin [3, 15, 17]. Bitcoin provides only pseudonymitythrough the use of Bitcoin identities (public keys or theirhashes), of which a Bitcoin user can generate an unlimitednumber. Indeed, many Bitcoin clients routinely generate newidentities in an effort to preserve the users privacy.

Regardless of Bitcoin design goals, Bitcoins user baseseems willing to go through considerable effort to maintaintheir anonymity including risking their money and payingtransaction fees. One illustration of this is the existence oflaundries that (for a fee) will mix together different usersfunds in the hopes that shuffling makes them difficult totrace [2, 6, 7]. Because such systems require the users to trustthe laundry to both (a) not record how the mixing is done

6This reference consists of a transaction hash identifier as well as anindex into the transactions output list.

7A 34 character hash that contains the double SHA-256 hash of the keyand some checksum data.

8Individual recipients are free to disregard this advice. However, thiscould make them vulnerable to double-spending attacks as described byKarame et al. [16].

and (b) give the users back the money they put in to the pot,use of these systems involves a fair amount of risk.

III. DECENTRALIZED E-CASH

Our approach to anonymizing the Bitcoin network uses aform of cryptographic e-cash. Since our construction does notrequire a central coin issuer, we refer to it as a decentralizede-cash scheme. In this section we define the algorithmsthat make up a decentralized e-cash scheme and describethe correctness and security properties required of such asystem.

Notation. Let represent an adjustable security parameter,let poly() represent some polynomial function, and let ()represent a negligible function. We use C to indicate the setof allowable coin values.

Definition 3.1 (Decentralized E-Cash Scheme): A decen-tralized e-cash scheme consists of a tuple of possiblyrandomized algorithms (Setup,Mint,Spend,Verify). Setup(1) params. On input a security parameter,

output a set of global public parameters params and adescription of the set C.

Mint(params) (c, skc). On input parametersparams, output a coin c C, as well as a trapdoorskc.

Spend(params, c, skc,R,C) (pi, S). Givenparams, a coin c, its trapdoor skc, some transactionstring R {0, 1}, and an arbitrary set of coins C,output a coin spend transaction consisting of a proof piand serial number S if c C C. Otherwise output.

Verify(params, pi, S,R,C) {0, 1}. Given params,a proof pi, a serial number S, transaction information R,and a set of coins C, output 1 if C C and (pi, S,R)is valid. Otherwise output 0.

We note that the Setup routine may be executed by atrusted party. Since this setup occurs only once and does notproduce any corresponding secret values, we believe that thisrelaxation is acceptable for real-world applications. Someconcrete instantiations may use different assumptions.

Each coin is generated using a randomized mintingalgorithm. The serial number S is a unique value releasedduring the spending of a coin and is designed to preventany user from spending the same coin twice. We willnow formalize the correctness and security properties ofa decentralized e-cash scheme. Each call to the Spendalgorithm can include an arbitrary string R, which is intendedto store transaction-specific information (e.g., the identity ofa transaction recipient).

Correctness. Every decentralized e-cash scheme must satisfythe following correctness requirement. Let params Setup(1) and (c, skc) Mint(params). Let C Cbe any valid set of coins, where |C| poly(), and

assign (pi, S) Spend(params, c, skc,R,C). The schemeis correct if, over all C, R, and random coins used inthe above algorithms, the following equality holds withprobability 1 ():

Verify(params, pi, S,R,C {c}) = 1Security. The security of a decentralized e-cash system isdefined by the following two games: Anonymity and Balance.We first describe the Anonymity experiment, which ensuresthat the adversary cannot link a given coin spend transaction(pi, S) to the coin associated with it, even when the attackerprovides many of the coins used in generating the spendtransaction.

Definition 3.2 (Anonymity): A decentralized e-cashscheme = (Setup,Mint,Spend,Verify) satisfies theAnonymity requirement if every probabilistic polynomial-time (p.p.t.) adversary A = (A1,A2) has negligibleadvantage in the following experiment.

Anonymity(,A, )params Setup(1)For i {0, 1}: (ci, skci) Mint(params)(C, R, z) A1(params, c0, c1); b {0, 1}(pi, S) Spend(params, cb, skcb, R,C {c0, c1})Output: b A2(z, pi, S)

We define As advantage in the above game as|Pr [ b = b ] 1/2|.

The Balance property requires more consideration. Intu-itively, we wish to ensure that an attacker cannot spend morecoins than she mints, even when she has access to coins andspend transactions produced by honest parties. Note that tostrengthen our definition, we also capture the property thatan attacker might alter valid coins, e.g., by modifying theirtransaction information string R.

Our definition is reminiscent of the one-more forgerydefinition commonly used for blind signatures. We providethe attacker with a collection of valid coins and an oracleOspend that she may use to spend any of them.9 UltimatelyA must produce m coins and m+ 1 valid spend transactionssuch that no transaction duplicates a serial number or modifiesa transaction produced by the honest oracle.

Definition 3.3 (Balance): A decentralized e-cash scheme = (Setup,Mint,Spend,Verify) satisfies the Balanceproperty if N poly() every p.p.t. adversary A hasnegligible advantage in the following experiment.

Balance(,A, N, )params Setup(1)For i = 1 to N : (ci, skci) Mint(params)Output: (c1, . . . , c

m,S1, . . . ,Sm,Sm+1)

AOspend(,,)(params, c1, . . . , cN )9We provide this functionality as an oracle to capture the possibility that

the attacker can specify arbitrary input for the value C.

The oracle Ospend operates as follows: on the jthquery Ospend(cj ,Cj , Rj), the oracle outputs ifcj / {c1, . . . , cN}. Otherwise it returns (pij , Sj) Spend(params, cj , skcj , Rj ,Cj) to A and records (Sj , Rj)in the set T .

We say that A wins (i.e., she produces more spendsthan minted coins) if s {S1, . . . ,Sm,Sm+1} wheres = (pi, S, R,C): Verify(params, pi, S, R,C) = 1. C {c1, . . . , cN , c1, . . . , cm}. (S, R) / T . S appears in only one tuple from {S1, . . . ,Sm,Sm+1}.We define As advantage as the probability that A wins

the above game.

IV. DECENTRALIZED E-CASH FROM STRONG RSA

In this section we describe a concrete instantiation of adecentralized e-cash scheme. We first define the necessarycryptographic ingredients.

A. Cryptographic Building Blocks

Zero-knowledge proofs and signatures of knowledge. Ourprotocols use zero-knowledge proofs that can be instantiatedusing the technique of Schnorr [18], with extensions due toe.g., [19, 20, 21, 22]. We convert these into non-interactiveproofs by applying the Fiat-Shamir heuristic [23]. In thelatter case, we refer to the resulting non-interactive proofsas signatures of knowledge as defined in [24].

When referring to these proofs we will use the notation ofCamenisch and Stadler [25]. For instance, NIZKPoK{(x, y) :h = gx c = gy} denotes a non-interactive zero-knowledgeproof of knowledge of the elements x and y that satisfy bothh = gx and c = gy. All values not enclosed in ()s areassumed to be known to the verifier. Similarly, the extensionZKSoK[m]{(x, y) : h = gx c = gy} indicates a signatureof knowledge on message m.

Accumulators. Our construction uses an accumulator basedon the Strong RSA assumption. The accumulator we usewas first proposed by Benaloh and de Mare [10] and laterimproved by Baric and Pfitzmann [11] and Camenisch andLysyanskaya [12]. We describe the accumulator using thefollowing algorithms: AccumSetup() params. On input a security param-

eter, sample primes p, q (with polynomial dependence onthe security parameter), compute N = pq, and sample aseed value u QRN , u 6= 1. Output (N, u) as params.

Accumulate(params,C) A. On input params(N, u) and a set of prime numbers C ={c1, . . . , ci | c [A ,B]},10 compute the accumulator Aas uc1c2cn mod N .

10See Appendix A for a more precise description.

GenWitness(params, v,C) w. On input params(N, u), a set of prime numbers C as described above,and a value v C, the witness w is the accumu-lation of all the values in C besides v, i.e., w =Accumulate(params,C \ {v}).

AccVerify(params,A, v, ) {0, 1}. On inputparams (N, u), an element v, and witness , computeA v mod N and output 1 if and only if A = A,v is prime, and v [A ,B] as defined previously.

For simplicity, the description above uses the full calculationof A. Camenisch and Lysyanskaya [12] observe that theaccumulator may also be incrementally updated, i.e., givenan existing accumulator An it is possible to add an elementx and produce a new accumulator value An+1 by computingAn+1 = A

xn mod N . We make extensive use of this

optimization in our practical implementation.Camenisch and Lysyanskaya [12] show that the accumu-

lator satisfies a strong collision-resistance property if theStrong RSA assumption is hard. Informally, this ensuresthat no p.p.t. adversary can produce a pair (v, ) such thatv / C and yet AccVerify is satisfied. Additionally, theydescribe an efficient zero-knowledge proof of knowledge thata committed value is in an accumulator. We convert this intoa non-interactive proof using the Fiat-Shamir transform andrefer to the resulting proof using the following notation:

NIZKPoK{(v, ) : AccVerify((N, u), A, v, ) = 1}.B. Our Construction

We now describe a concrete decentralized e-cash scheme.Our scheme is secure assuming the hardness of the StrongRSA and Discrete Logarithm assumptions, and the existenceof a zero-knowledge proof system.

We now describe the algorithms: Setup(1) params. On input a security parameter,

run AccumSetup(1) to obtain the values (N, u). Nextgenerate primes p, q such that p = 2wq + 1 for w 1.Select random generators g, h such that G = g =h and G is a subgroup of Zq . Output params =(N, u, p, q, g, h).

Mint(params) (c, skc). Select S, r Zq andcompute c gShr mod p such that {c prime | c [A ,B]}.11 Set skc = (S, r) and output (c, skc).

Spend(params, c, skc,R,C) (pi, S). If c / Coutput . Compute A Accumulate((N, u),C) and GenWitness((N, u), c,C). Output (pi, S) where picomprises the following signature of knowledge:12

pi = ZKSoK[R]{(c, w, r) :AccVerify((N, u), A, c, w) = 1 c = gShr}

Verify(params, pi, S,R,C) {0, 1}. Given a proof pi,a serial number S, and a set of coins C, first compute

11See Appendix A for a more precise description.12See Appendix B for the construction of the ZKSoK.

A Accumulate((N, u),C). Next verify that pi is theaforementioned signature of knowledge on R using theknown public values. If the proof verifies successfully,output 1, otherwise output 0.

Our protocol assumes a trusted setup process for generatingthe parameters. We stress that the accumulator trapdoor(p, q) is not used subsequent to the Setup procedure andcan therefore be destroyed immediately after the parametersare generated. Alternatively, implementers can use thetechnique of Sander for generating so-called RSA UFOsfor accumulator parameters without a trapdoor [26].

C. Security Analysis

We now consider the security of our construction.Theorem 4.1: If the zero-knowledge signature of knowl-

edge is computationally zero-knowledge in the random oraclemodel, then = (Setup,Mint,Spend,Verify) satisfies theAnonymity property.

We provide a proof sketch for Theorem 4.1 in Appendix A.Intuitively, the security of our construction stems from the factthat the coin commitment C is a perfectly-hiding commitmentand the signature proof pi is at least computationally zero-knowledge. These two facts ensure that the adversary has atmost negligible advantage in guessing which coin was spent.

Theorem 4.2: If the signature proof pi is sound in therandom oracle model, the Strong RSA problem is hard, andthe Discrete Logarithm problem is hard in G, then =(Setup,Mint,Spend,Verify) satisfies the Balance property.

A proof of Theorem 4.1 is included in Appendix A.Briefly, this proof relies on the binding properties of the coincommitment, as well as the soundness and unforgeabilityof the ZKSoK and collision-resistance of the accumulator.We show that an adversary who wins the Balance gamewith non-negligible advantage can be used to either find acollision in the commitment scheme (allowing us to solvethe Discrete Logarithm problem) or find a collision in theaccumulator (which leads to a solution for Strong RSA).

V. INTEGRATING WITH BITCOIN

While the construction of the previous section gives anoverview of our approach, we have yet to describe how ourtechniques integrate with Bitcoin. In this section we addressthe specific challenges that come up when we combine adecentralized e-cash scheme with the Bitcoin protocol.

The general overview of our approach is straightfor-ward. To mint a zerocoin c of denomination d, Alice runsMint(params) (c, skc) and stores skc securely.13 Shethen embeds c in the output of a Bitcoin transaction thatspends d+ fees classical bitcoins. Once a mint transactionhas been accepted into the block chain, c is included in the

13In our implementation all bitcoins have a single fixed value. However,we can support multiple values by running distinct Zerocoin instantiationssimultaneously, all sharing the same set of public parameters.

global accumulator A, and the currency cannot be accessedexcept through a Zerocoin spend, i.e., it is essentially placedinto escrow.

To spend c with Bob, Alice first constructs a partialtransaction ptx that references an unclaimed mint transactionas input and includes Bobs public key as output. Shethen traverses all valid mint transactions in the blockchain, assembles the set of minted coins C, and runsSpend(params, c, skc, hash(ptx),C) (pi, S). Finally,she completes the transaction by embedding (pi, S) in thescriptSig of the input of ptx. The output of this transactioncould also be a further Zerocoin mint transaction afeature that may be useful to transfer value between multipleZerocoin instances (i.e., of different denomination) runningin the same block chain.

When this transaction appears on the network, nodes checkthat Verify(params, pi, S, hash(ptx),C) = 1 and check thatS does not appear in any previous transaction. If thesecondition hold and the referenced mint transaction is notclaimed as an input into a different transaction, the networkaccepts the spend as valid and allows Alice to redeem dbitcoins.

Computing the accumulator. A naive implementation ofthe construction in Section IV requires that the verifier re-compute the accumulator A with each call to Verify(. . .). Inpractice, the cost can be substantially reduced.

First, recall that the accumulator in our construction canbe computed incrementally, hence nodes can add new coinsto the accumulation when they arrive. To exploit this, werequire any node mining a new block to add the zerocoins inthat block to the previous blocks accumulator and store theresulting new accumulator value in the coinbase transactionat the start of the new block.14 We call this an accumulatorcheckpoint. Peer nodes validate this computation beforeaccepting the new block into the blockchain. Provided thatthis verification occurs routinely when blocks are added tothe chain, some clients may choose to trust the accumulatorin older (confirmed) blocks rather than re-compute it fromscratch.

With this optimization, Alice need no longer compute theaccumulator A and the full witness w for c. Instead she canmerely reference the current blocks accumulator checkpointand compute the witness starting from the checkpointpreceding her mint (instead of starting at T0), since computingthe witness is equivalent to accumulating C \ {c}.New transaction types. Bitcoin transactions use a flexiblescripting language to determine the validity of each transac-tion. Unfortunately, Bitcoin script is (by design) not Turing-complete. Moreover, large segments of the already-limited

14The coinbase transaction format already allows for the inclusion ofarbitrary data, so this requires no fundamental changes to the Bitcoinprotocol.

script functionality have been disabled in the Bitcoin produc-tion network due to security concerns. Hence, the existingscript language cannot be used for sophisticated calculationssuch as verifying zero-knowledge proofs. Fortunately forour purposes, the Bitcoin designers chose to reserve severalscript operations for future expansion.

We extend Bitcoin by adding a new instruction: ZERO-COIN MINT. Minting a zerocoin constructs a transactionwith an output whose scriptPubKey contains this instructionand a coin c. Nodes who receive this transaction shouldvalidate that c is a well-formed coin. To spend a zerocoin,Alice constructs a new transaction that claims as inputsome Zerocoin mint transaction and has a scriptSig fieldcontaining (pi, S) and a reference to the block containing theaccumulator used in pi. A verifier extracts the accumulatorfrom the referenced block and, using it, validates the spendas described earlier.

Finally, we note that transactions must be signed to preventan attacker from simply changing who the transaction ispayed to. Normal Bitcoin transactions include an ECDSAsignature by the key specified in the scriptPubKey of thereferenced input. However, for a spend transaction on anarbitrary zerocoin, there is no ECDSA public key. Instead, weuse the ZKSoK pi to sign the transaction hash that normallywould be signed using ECDSA.15

Statekeeping and side effects. Validating a zerocoin changesBitcoins semantics: currently, Bitcoins persistent stateis defined solely in terms of transactions and blocks oftransactions. Furthermore, access to this state is done viaexplicit reference by hash. Zerocoin, on the other hand,because of its strong anonymity requirement, deals withexistentials: the coin is in the set of thus-far-minted coinsand its serial number is not yet in the set of spent serialnumbers. To enable these type of qualifiers, we introduceside effects into Bitcoin transaction handling. Processing amint transaction causes a coin to be accumulated as a sideeffect. Processing a spend transaction causes the coin serialnumber to be added to a list of spent serial numbers held bythe client.

For coin serial numbers, we have little choice but to keepa full list of them per client and incur the (small) overheadof storing that list and the larger engineering overhead ofhandling all possible ways a transaction can enter a client.The accumulator state is maintained within the accumulatorcheckpoints, which the client verifies for each received block.

Proof optimizations. For reasonable parameter sizes, theproofs produced by Spend(. . .) exceed Bitcoins 10KBtransaction size limits. Although we can simply increase thislimit, doing so has two drawbacks: (1) it drastically increasesthe storage requirements for Bitcoin since current transactions

15In practice, this modification simply requires us to include the transactiondigest in the hash computation of the challenge for the Fiat-Shamir proofs.See Appendix A for details.

are between 1 and 2 KB and (2) it may increase memorypressure on clients that store transactions in memory.16

In our prototype implementation we store our proofs ina separate, well-known location (a simple server). A fullimplementation could use a Distributed Hash Table or nonblock-chain backed storage in Bitcoin. While we recommendstoring proofs in the block chain, these alternatives do notincrease the storage required for the block chain.17

A. Suggestions for Optimizing Proof Verification

The complexity of the proofs will also lead to longerverification times than expected with a standard Bitcointransaction. This is magnified by the fact that a Bitcointransaction is verified once when it is included by a blockand again by every node when that block is accepted intothe block chain. Although the former cost can be accountedfor by charging transaction fees, it would obviously be idealfor these costs to be as low as possible.

One approach is to distribute the cost of verification overthe entire network and not make each node verify the entireproof. Because the ZKSoK we use utilizes cut-and-choosetechniques, it essentially consists of n repeated iterationsof the same proof (reducing the probability of forgery toroughly 2n). We can simply have nodes randomly selectwhich iterations of the proofs they verify. By distributing thisprocess across the network, we should achieve approximatelythe same security with less duplication of effort.

This optimization involves a time-space tradeoff, sincethe existing proof is verified by computing a series of (at aminimum) 1024 bit values T1, . . . , Tn and hashing the result.A naive implementation would require us to send T1, . . . , Tnfully computed greatly increasing the size of the proof since the client will only compute some of them but needsall of them to verify the hash. We can avoid this issue byreplacing the standard hash with a Merkel tree where theleaves are the hashed Ti values and the root is the challengehash used in the proof. We can then send the 160 bit or256 bit intermediate nodes instead of the 1024 bit Ti values,allowing the verifier to compute only a subset of the Tivalues and yet still validate the proof against the challengewithout drastically increasing the proof size.

B. Limited Anonymity and Forward Security

A serious concern in the Bitcoin community is the lossof wallets due to poor endpoint security. In traditionalBitcoin, this results in the theft of coins [4]. However, inthe Zerocoin setting it may also allow an attacker to de-anonymize Zerocoin transactions using the stored skc. The

16The reference bitcoind client stores transactions as STL Vectors,which require contiguous segments of memory. As such, storing Zerocoinproofs in the transaction might cause memory issues far faster than expected.

17Furthermore, this solution allows for the intriguing possibility thatproofs be allowed to vanish after they have been sufficiently verified by thenetwork and entombed in the block chain. However, it is not clear how thisinteracts with Bitcoin in theory or practice.

obvious solution is to securely delete skc immediately aftera coin is spent. Unfortunately, this provides no protection ifskc is stolen at some earlier point.

One solution is to generate the spend transaction imme-diately (or shortly after) the coin is minted, possibly usingan earlier checkpoint for calculating C. This greatly reducesthe users anonymity by decreasing the number of coins inC and leaking some information about when the coin wasminted. However, no attacker who compromises the walletcan link any zerocoins in it to their mint transactions.

C. Code Changes

For our implementation, we chose to modify bitcoind,the original open-source Bitcoin C++ client. This requiredseveral modifications. First, we added instructions to theBitcoin script for minting and spending zerocoins. Next,we added transaction types and code for handling thesenew instructions, as well as maintaining the list of spentserial numbers and the accumulator. We used the Charmcryptographic framework [27] to implement the cryptographicconstructions in Python, and we used Boosts Python utilitiesto call that code from within bitcoind. This introducessome performance overhead, but it allowed us to rapidly pro-totype and leave room for implementing future constructionsas well.

D. Incremental Deployment

As described above, Zerocoin requires changes to theBitcoin protocol that must happen globally: while transactionscontaining the new instructions will be validated by updatedservers, they will fail validation on older nodes, potentiallycausing the network to split when a block is produced thatvalidates for some, but not all, nodes. Although this is notthe first time Bitcoin has faced this problem, and there isprecedent for a flag day type upgrade strategy [28], it isnot clear how willing the Bitcoin community is to repeatit. As such, we consider the possibility of an incrementaldeployment.

One way to accomplish this is to embed the above protocolas comments in standard Bitcoin scripts. For non Zerocoinaware nodes, this data is effectively inert, and we can useBitcoins n of k signature support to specify that suchcomment embedded zerocoins are valid only if signed bysome subset of the Zerocoin processing nodes. Such Zerocoinaware nodes can parse the comments and charge transactionfees for validation according to the proofs embedded in thecomments, thus providing an incentive for more nodes toprovide such services. Since this only changes the validationmechanism for Zerocoin, the Anonymity property holds asdoes the Balance property if no more than n 1 Zerocoinnodes are malicious.

Some care must be taken when electing these nodes toprevent a Sybil attack. Thankfully, if we require that such anode also produce blocks in the Bitcoin block chain, we have

a decent deterrent. Furthermore, because any malfeasanceof these nodes is readily detectable (since they signed aninvalid Zerocoin transaction), third parties can audit thesenodes and potentially hold funds in escrow to deter fraud.

VI. REAL WORLD SECURITY AND PARAMETER CHOICE

A. Anonymity of Zerocoin

Definition 3.2 states that given two Zerocoin mints and onespend, one cannot do much better than guess which mintedcoin was spent. Put differently, an attacker learns no morefrom our scheme than they would from observing the mintsand spends of some ideal scheme. However, even an idealscheme imposes limitations. For example, consider a casewhere N coins are minted, then all N coins are subsequentlyspent. If another coin is minted after this point, the size ofthe anonymity set for the next spend is k = 1, not k = 11,since it is clear to all observers that the previous coins havebeen used. We also stress that as in many anonymitysystems privacy may be compromised by an attacker whomints a large fraction of the active coins. Hence, a lowerbound on the anonymity provided is the number of coinsminted by honest parties between a coins mint and its spend.An upper bound is the total set of minted coins.

We also note that Zerocoin reveals the number of mintedand spent coins to all users of the system, which providesa potential source of information to attackers. This is incontrast to many previous e-cash schemes which reveal thisinformation primarily to merchants and the bank. However,we believe this may be an advantage rather than a loss,since the bank is generally considered an adversarial party inmost e-cash security models. The public model of Zerocoinactually removes an information asymmetry by allowing usersto determine when such conditions might pose a problem.

Lastly, Zerocoin does not hide the denominations used ina transaction. In practice, this problem can be avoided bysimply fixing one or a small set of coin denominations andexchanging coins until one has those denominations, or bysimply using Zerocoin to anonymize bitcoins.

B. Parameters

Generally, cryptographers specify security in terms of asingle, adjustable security parameter . Indeed, we haveused this notation throughout the previous sections. In reality,however, there are three distinct security choices for Zerocoinwhich affect either the systems anonymity, its resilience tocounterfeiting, or both. These are:

1) The size of the Schnorr group used in the coincommitments.

2) The size of the RSA modulus used in the accumulator.3) zkp, the security of the zero-knowledge proofs.

Commitments. Because Pedersen commitments are informa-tion theoretically hiding for any Schnorr group whose orderis large enough to fit the committed values, the size of

the group used does not affect the long term anonymityof Zerocoin. The security of the commitment scheme does,however, affect counterfeiting: an attacker who can breakthe binding property of the commitment scheme can mint azerocoin that opens to at least two different serial numbers,resulting in a double spend. As a result, the Schnorr groupmust be large enough that such an attack cannot be feasiblymounted in the lifetime of a coin. On the other hand, thesize of the signature of knowledge pi used in coin spendsincreases linearly with the size of the Schnorr group.

One solution is to minimize the group size by announcingfresh parameters for the commitment scheme periodicallyand forcing old zerocoins to expire unless exchanged fornew zerocoins minted under the fresh parameters.18 Sinceall coins being spent on the network at time t are spentwith the current parameters and all previous coins can beconverted to fresh ones, this does not decrease the anonymityof the system. It does, however, require users to convert oldzerocoins to fresh ones before the old parameters expire.For our prototype implementation, we chose to use 1024 bitparameters on the assumption that commitment parameterscould be regenerated periodically. We explore the possibilityof extensions to Zerocoin that might enable smaller groupsin Section IX.

Accumulator RSA key. Because generating a new accumulatorrequires either a new trusted setup phase or generating anew RSA UFO [26], we cannot re-key very frequently. As aresult, the accumulator is long lived, and thus we truly needlong term security. Therefore we currently propose an RSAkey of at least 3072 bits. We note that this does not greatlyaffect the size of the coins themselves, and, because the proofof accumulator membership is efficient, this does not havea large adverse effect on the overall coin spend proof size.Moreover, although re-keying the accumulator is expensive,it need not reduce the anonymity of the system since the newparameters can be used to re-accumulate the existing coinset and hence anonymize spends over that whole history.

Zero-knowledge proof security zkp. This parameter affectsthe anonymity and security of the zero-knowledge proof. Italso greatly affects the size of the spend proof. Thankfully,since each proof is independent, it applies per proof andtherefore per spend. As such, a dishonest party would haveto expend roughly 2zkp effort to forge a single coin or couldlink a single coin mint to a spend with probability roughly

1

2zkp. As such we pick zkp = 80 bits.

VII. PERFORMANCE

To validate our results, we conducted several experimentsusing the modified bitcoind implementation describedin Section V. We ran our experiments with three different

18Note that this conversion need not involve a full spend of the coins.The user may simply reveal the trapdoor for the old coin, since the newzerocoin will still be unlinkable when properly spent.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8

1024 2048 3072

Time (

sec)

Modulus Size (bits)

Performance of Zerocoin AlgorithmsMintSpendVerify

(a) Times for a single Zerocoin operation measured in seconds. Theseoperations do not include the time required to compute the accumulator.

0 5000

10000 15000 20000 25000 30000 35000 40000 45000 50000

1024 2048 3072

Proof

Size (

bytes

)

Modulus Size (bits)

Zerocoin Spend Proof Size

(b) Zerocoin proof sizes measured in bytes as a function of RSAmodulus size.

0 100 200 300 400 500 600 700 800 900

0 10000 20000 30000 40000 50000

Time (

sec)

Number of Elements Accumulated

Accumulation TimeN=1024N=2048N=3072

(c) Time required to accumulate x elements. Note, this cost is amortizedwhen computing the global accumulator.

0 200 400 600 800

1000 1200 1400

0 20 40 60 80 100Tra

nsacti

ons p

er mi

nute

Percentage of Zerocoins

Zerocoin Block Verication PerformanceN = 1024N = 2048N = 3072

(d) Transaction verifications per minute as a function of the percentageof Zerocoin transactions in the network (where half are mints and halfare spends). Note, since we plot the reciprocal of transaction time, thisgraph appears logarithmic even though Zerocoin scales linearly.

Figure 3: Zerocoin performance as a function of parameter size.

parameter sizes, where each corresponds to a length of theRSA modulus N : 1024 bits, 2048 bits, and 3072 bits.19

We conducted two types of experiments: (1) microbench-marks that measure the performance of our cryptographicconstructions and (2) tests of our whole modified Bitcoinclient measuring the time to verify Zerocoin carrying blocks.The former gives us a reasonable estimate of the cost ofminting a single zerocoin, spending it, and verifying theresulting transaction. The latter gives us an estimate ofZerocoins impact on the existing Bitcoin network and thecomputational cost that will be born by each node that verifiesZerocoin transactions.

All of our experiments were conducted on an Intel XeonE3-1270 V2 (3.50GHz quad-core processor with hyper-threading) with 16GB of RAM, running 64-bit Ubuntu Server11.04 with Linux kernel 2.6.38.

19These sizes can be viewed as roughly corresponding to a discretelogarithm/factorization security level of 280, 2112, and 2128 respectively.Note that the choice of N determines the size of the parameter p. We select|q| to be roughly twice the estimated security level.

A. Microbenchmarks

To evaluate the performance of our Mint, Spend, andVerify algorithms in isolation, we conducted a series ofmicrobenchmarks using the Charm (Python) implementation.Our goal in these experiments was to provide a direct estimateof the performance of our cryptographic primitives.

Experimental setup. One challenge in conducting our mi-crobenchmarks is the accumulation of coins in C for thewitness in Spend(. . .) or for the global accumulator in bothSpend(. . .) and Verify(. . .). This is problematic for tworeasons. First, we do not know how large C will be inpractice. Second, in our implementation accumulations areincremental. To address these issues we chose to break ourmicrobenchmarks into two separate experiments. The firstexperiment simply computes the accumulator for a number ofpossible sizes of C, ranging from 1 to 50,000 elements. Thesecond experiment measures the runtime of the Spend(. . .)and Verify(. . .) routines with a precomputed accumulatorand witness (A,).

We conducted our experiments on a single thread of theprocessor, using all three parameter sizes. All experiments

were performed 500 times, and the results given representthe average of these times. Figure 3a shows the measuredtimes for computing the coin operations, Figure 3b showsthe resulting proof sizes for each security parameter, andFigure 3c shows the resulting times for computing theaccumulator. We stress that accumulation in our system isincremental, typically over at most the 200500 transactionsin a block (which takes at worst eight seconds), and hencethe cost of computing the global accumulator is thereforeamortized. The only time one might accumulate 50,000 coinsat one time would be when generating the witness for a veryold zerocoin.

B. Block Verification

How Zerocoin affects network transaction processing de-termines its practicality and scalability. Like all transactions,Zerocoin spends must be verified first by the miner to makesure he is not including invalid transactions in a block andthen again by the network to make sure it is not including aninvalid block in the block chain. In both cases, this entailschecking that Verify(. . .) = 1 for each Zerocoin transactionand computing the accumulator checkpoint.

We need to know the impact of this for two reasons. First,the Bitcoin protocol specifies that a new block should becreated on average once every 10 minutes.20 If verificationtakes longer than 10 minutes for blocks with a reasonablenumber of zerocoins, then the network cannot function.21

Second, while the cost of generating these blocks andverifying their transactions can be offset by transactionfees and coin mining, the cost of verifying blocks prior toappending them to the block chain is only offset for miningnodes (who can view it as part of the cost of mining a newblock). This leaves anyone else verifying the block chainwith an uncompensated computational cost.

Experimental setup. To measure the effect of Zerocoin onblock verification time, we measure how long it takes ourmodified bitcoind client to verify externally loaded testblocks containing 200, 400, and 800 transactions where 0,10, 25, 75, or 100 percent of the transactions are Zerocointransactions (half of which are mints and half are spends).We repeat this experiment for all three security parameters.

Our test data consists of two blocks. The first contains zZerocoin mints that must exist for any spends to occur. Thesecond block is our actual test vector. It contains, in a randomorder, z Zerocoin spends of the coins in the previous block,z Zerocoin mints, and s standard Bitcoin sendToAddresstransactions. We measure how long the processblockcall of the bitcoind client takes to verify the secondblock containing the mix of Zerocoin and classical Bitcoin

20This rate is maintained by a periodic network vote that adjusts thedifficulty of the Bitcoin proof of work.

21For blocks with unreasonable numbers of Zerocoin transaction we cansimply extend bitcoinds existing anti-DoS mechanisms to reject theblock and blacklist its origin.

transactions. For accuracy, we repeat these measurements100 times and average the results. The results are presentedin Figure 3d.

C. Discussion

Our results show that Zerocoin scales beyond currentBitcoin transaction volumes. Though we require significantcomputational effort, verification does not fundamentallythreaten the operation of the network: even with a blockcontaining 800 Zerocoin transactions roughly double theaverage size of a Bitcoin block currently verificationtakes less than five minutes. This is under the unreasonableassumption that all Bitcoin transactions are supplanted byZerocoin transactions.22 In fact, we can scale well beyondBitcoins current average of between 200 and 400 transactionsper block [29] if Zerocoin transactions are not the majorityof transactions on the network. If, as the graph suggests, weassume that verification scales linearly, then we can supporta 50% transaction mix out to 350 transactions per minute(3,500 transactions per block) and a 10% mixture out to 800transactions per minute (8,000 per block).

One remaining question is at what point we start running arisk of coin serial number collisions causing erroneous doublespends. Even for our smallest serial numbers 160 bits the collision probability is small, and for the 256 bit serialnumbers used with the 3072 bit accumulator, our collisionprobability is at worst equal to the odds of a collision on anormal Bitcoin transaction which uses SHA-256 hashes.

We stress several caveats about the above data. First, ourprototype system does not exploit any parallelism either forverifying multiple Zerocoin transactions or in validating anindividual proof. Since the only serial dependency for eitherof these tasks is the (fast) duplicate serial number check, thisoffers the opportunity for substantial improvement.

Second, the above data is not an accurate estimate ofthe financial cost of Zerocoin for the network: (a) it is anoverestimate of a mining nodes extra effort when verifyingproposed blocks since in practice many transactions in areceived block will already have been received and validatedby the node as it attempts to construct its own contributionto the block chain; (b) execution time is a poor metric inthe context of Bitcoin, since miners are concerned withactual monetary operating cost; (c) since mining is typicallyperformed using GPUs and to a lesser extent FPGAs andASICs, which are far more efficient at computing hashcollisions, the CPU cost measured here is likely insignificant.

Finally, our experiment neglects the load on a node bothfrom processing incoming transactions and from solvingthe proof of work. Again, we contend that most nodes willprobably use GPUs for mining, and as such the latter isnot an issue. The former, however, remains an unknown. At

22In practice we believe Zerocoin will be used to anonymize bitcoins thatwill then be spent in actual transactions, resulting in far lower transactionvolumes.

the very least it seems unlikely to disproportionately affectZerocoin performance.

VIII. PREVIOUS WORK

A. E-Cash and Bitcoin

Electronic cash has long been a research topic for cryp-tographers. Many cryptographic e-cash systems focus onuser privacy and typically assume the existence of a semi-trusted coin issuer or bank. E-cash schemes largely breakdown into online schemes where users have contact witha bank or registry and offline schemes where spending canoccur even without a network connection. Chaum introducedthe first online cryptographic e-cash system [30] based onRSA signatures, later extending this work to the offlinesetting [31] by de-anonymizing users who double-spent.Many subsequent works improved upon these techniqueswhile maintaining the requirement of a trusted bank: forexample, by making coins divisible [32, 33] and reducingwallet size [34]. One exception to the rule above comesfrom Sander and Ta-Shma [35] who presciently developedan alternative model that is reminiscent of our proposal: thecentral bank is replaced with a hash chain and signatureswith accumulators. Unfortunately the accumulator was notpractical, a central party was still required, and no real-worldsystem existed to compute the chain.

Bitcoins primary goal, on the other hand, is not anonymity.It has its roots in a non-academic proposal by Wei Daifor a distributed currency based on solving computationalproblems [36]. In Dais original proposal anyone could createcurrency, but all transactions had to be broadcast to all clients.A second variant limited currency generation and transactionbroadcast to a set of servers, which is effectively the approachBitcoin takes. This is a marked distinction from most, if notall, other e-cash systems since there is no need to select oneor more trusted parties. There is a general assumption thata majority of the Bitcoin nodes are honest, but anyone canjoin a node to the Bitcoin network, and anyone can get theentire transaction graph. An overview of Bitcoin and someof its shortcomings was presented by Barber et. al. in [2].

B. Anonymity

Numerous works have shown that pseudonymized graphscan be re-identified even under passive analysis. Narayananand Shmatikov [5] showed that real world social networkscan be passively de-anonymized. Similarly, Backstrom etal. [37] constructed targeted attacks against anonymizedsocial networks to test for relationships between vertices.Previously, Narayanan and Shmatikov de-anonymized usersin the Netflix prize data set by correlating data fromIMDB [38].

Bitcoin itself came into existence in 2009 and is nowbeginning to receive scrutiny from privacy researchers. De-anonymization techniques were applied effectively to Bitcoineven at its relatively small 2011 size by Reid and Harrigan [3].

Ron and Shamir examined the general structure of the Bitcoinnetwork graph [1] after its nearly 3-fold expansion. Finally,we have been made privately aware of two other early-stageefforts to examine Bitcoin anonymity.

IX. CONCLUSION AND FUTURE WORK

Zerocoin is a distributed e-cash scheme that providesstrong user anonymity and coin security under the assumptionthat there is a distributed, online, append-only transactionstore. We use Bitcoin to provide such a store and thebacking currency for our scheme. After providing generaldefinitions, we proposed a concrete realization based on RSAaccumulators and non-interactive zero-knowledge signaturesof knowledge. Finally, we integrated our construction intoBitcoin and measured its performance.

Our work leaves several open problems. First, although ourscheme is workable, the need for a double-discrete logarithmproof leads to large proof sizes and verification times. Wewould prefer a scheme with both smaller proofs and greaterspeed. This is particularly important when it comes toreducing the cost of third-party verification of Zerocointransactions. There are several promising constructions in thecryptographic literature, e.g., bilinear accumulators, mercurialcommitments [13, 39]. While we were not able to find ananalogue of our scheme using alternative components, it ispossible that further research will lead to other solutions.Ideally such an improvement could produce a drop-inreplacement for our existing implementation.

Second, Zerocoin currently derives both its anonymityand security against counterfeiting from strong cryptographicassumptions at the cost of substantially increased computa-tional complexity and size. As discussed in section VI-B,anonymity is relatively cheap, and this cost is principallydriven by the anti-counterfeiting requirement, manifestingitself through the size of the coins and the proofs used.

In Bitcoin, counterfeiting a coin is not computationallyprohibitive, it is merely computationally costly, requiring theuser to obtain control of at least 51% of the network. Thisprovides a possible alternative to our standard cryptographicassumptions: rather than the strong assumption that com-puting discrete logs is infeasible, we might construct ourscheme on the weak assumption that there is no financialincentive to break our construction as the cost of computinga discrete log exceeds the value of the resulting counterfeitcoins.

For example, if we require spends to prove that freshand random bases were used in the commitments for thecorresponding mint transaction (e.g., by selecting the basesfor the commitment from the hash of the coin serial numberand proving that the serial number is fresh), then it appearsthat an attacker can only forge a single zerocoin per discretelog computation. Provided the cost of computing such adiscrete log is greater than the value of a zerocoin, forging acoin is not profitable. How small this allows us to make

the coins is an open question. There is relatively littlework comparing the asymptotic difficulty of solving multipledistinct discrete logs in a fixed group,23 and it is not clearhow theory translates into practice. We leave these questions,along with the security of the above proposed construction,as issues for future work.

Finally, we believe that further research could lead todifferent tradeoffs between security, accountability, andanonymity. A common objection to Bitcoin is that it canfacilitate money laundering by circumventing legally bindingfinancial reporting requirements. We propose that additionalprotocol modifications (e.g., the use of anonymous creden-tials [40]) might allow users to maintain their anonymitywhile demonstrating compliance with reporting requirements.

Acknowledgements. We thank Stephen Checkoway, GeorgeDanezis, and the anonymous reviewers for their helpfulcomments. The research in this paper was supported in partby the Office of Naval Research under contract N00014-11-1-0470, and DARPA and the Air Force Research Laboratory(AFRL) under contract FA8750-11-2-0211.

REFERENCES

[1] D. Ron and A. Shamir, Quantitative Analysis of the FullBitcoin Transaction Graph, Cryptology ePrint Archive, Report2012/584, 2012, http://eprint.iacr.org/.

[2] S. Barber, X. Boyen, E. Shi, and E. Uzun, Bitter to better how to make bitcoin a better currency, in FinancialCryptography 2012, vol. 7397 of LNCS, 2012, pp. 399414.

[3] F. Reid and M. Harrigan, An analysis of anonymity in theBitcoin system, in Privacy, security, risk and trust (PASSAT),2011 IEEE Third Internatiojn Conference on Social Computing(SOCIALCOM). IEEE, 2011, pp. 13181326.

[4] T. B. Lee, A risky currency? Alleged $500,000 Bitcoin heistraises questions, Available at http://arstechnica.com/, June2011.

[5] A. Narayanan and V. Shmatikov, De-anonymizing social net-works, in Security and Privacy, 2009 30th IEEE Symposiumon. IEEE, 2009, pp. 173187.

[6] Bitcoin fog company, http://www.bitcoinfog.com/.

[7] The Bitcoin Laundry, http://www.bitcoinlaundry.com/.

[8] Blind Bitcoin, Information at https://en.bitcoin.it/wiki/BlindBitcoin Transfers.

[9] [Online]. Available: https://www.torproject.org/

[10] J. Benaloh and M. de Mare, One-way accumulators: adecentralized alternative to digital signatures, in EUROCRYPT

93, vol. 765 of LNCS, 1994, pp. 274285.

[11] N. Baric and B. Pfitzmann, Collision-free accumulators andfail-stop signature schemes without trees, in EUROCRYPT

97, vol. 1233 of LNCS, 1997, pp. 480494.

23We note that both SSH and the Internet Key Exchange protocol usedin IPv6 use fixed Diffie-Hellman parameters.

[12] J. Camenisch and A. Lysyanskaya, Dynamic accumulatorsand application to efficient revocation of anonymous creden-tials, in CRYPTO 02, 2002, pp. 6176.

[13] L. Nguyen, Accumulators from bilinear pairings and appli-cations, in Topics in Cryptology CT-RSA 2005, 2005, vol.3376 LNCS, pp. 275292.

[14] J. Camenisch, M. Kohlweiss, and C. Soriente, An accumulatorbased on bilinear maps and efficient revocation for anonymouscredentials, in PKC 09, vol. 5443 of LNCS, 2009, pp. 481500.

[15] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system,2009, 2012. [Online]. Available: http://www.bitcoin.org/bitcoin.pdf

[16] G. O. Karame, E. Androulaki, and S. Capkun, Two bitcoinsat the price of one? double-spending attacks on fast paymentsin bitcoin, Cryptology ePrint Archive, Report 2012/248, 2012,http://eprint.iacr.org/.

[17] European Central Bank, Virtual currency schemes,Available at http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf, October 2012.

[18] C.-P. Schnorr, Efficient signature generation for smart cards,Journal of Cryptology, vol. 4, no. 3, pp. 239252, 1991.

[19] R. Cramer, I. Damgard, and B. Schoenmakers, Proofs ofpartial knowledge and simplified design of witness hidingprotocols, in CRYPTO 94, vol. 839 of LNCS, 1994, pp.174187.

[20] J. Camenisch and M. Michels, Proving in zero-knowledge thata number n is the product of two safe primes, in EUROCRYPT

99, vol. 1592 of LNCS, 1999, pp. 107122.

[21] J. L. Camenisch, Group signature schemes and paymentsystems based on the discrete logarithm problem, Ph.D.dissertation, ETH Zurich, 1998.

[22] S. Brands, Rapid demonstration of linear relations connectedby boolean operators, in EUROCRYPT 97, vol. 1233 ofLNCS, 1997, pp. 318333.

[23] A. Fiat and A. Shamir, How to prove yourself: Practicalsolutions to identification and signature problems, in CRYPTO

86, vol. 263 of LNCS, 1986, pp. 186194.

[24] M. Chase and A. Lysyanskaya, On signatures of knowledge,in CRYPTO06, vol. 4117 of LNCS, 2006, pp. 7896.

[25] J. Camenisch and M. Stadler, Efficient group signatureschemes for large groups, in CRYPTO 97, vol. 1296 ofLNCS, 1997, pp. 410424.

[26] T. Sander, Efficient accumulators without trapdoor extendedabstract, in Information and Communication Security, vol.1726 of LNCS, 1999, pp. 252262.

[27] J. A. Akinyele, C. Garman, I. Miers, M. W. Pagano,M. Rushanan, M. Green, and A. D. Rubin, Charm:A framework for rapidly prototyping cryptosystems, Toappear, Journal of Cryptographic Engineering, 2013. [Online].Available: http://dx.doi.org/10.1007/s13389-013-0057-3

[28] [Online]. Available: https://en.bitcoin.it/wiki/BIP 0016

[29] [Online]. Available: http://blockchain.info/charts/n-transactions-per-block

[30] D. Chaum, Blind signatures for untraceable payments, inCRYPTO 82. Plenum Press, 1982, pp. 199203.

[31] D. Chaum, A. Fiat, and M. Naor, Untraceable electroniccash, in CRYPTO 88, 1990, vol. 403 of LNCS, pp. 319327.

[32] T. Okamoto and K. Ohta, Universal electronic cash, inCRYPTO 91, 1992, vol. 576 of LNCS, pp. 324337.

[33] T. Okamoto, An efficient divisible electronic cash scheme,in Crypt 95, 1995, vol. 963 of LNCS, pp. 438451.

[34] J. Camenisch, S. Hohenberger, and A. Lysyanskaya, Compacte-cash, in EUROCRYPT 05, 2005, vol. 3494 of LNCS, pp.566566.

[35] T. Sander and A. Ta-Shma, Auditable, anonymous electroniccash (extended abstract), in CRYPTO 99, vol. 1666 of LNCS,1999, pp. 555572.

[36] W. Dai. B-money proposal. [Online]. Available: http://www.weidai.com/bmoney.txt

[37] L. Backstrom, C. Dwork, and J. Kleinberg, Wherefore artthou r3579x?: Anonymized social networks, hidden patterns,and structural steganography, in Proceedings of the 16thinternational conference on World Wide Web, ser. WWW 07.New York, NY, USA: ACM, 2007, pp. 181190.

[38] A. Narayanan and V. Shmatikov, Robust de-anonymizationof large sparse datasets, in IEEE Symposium on Security andPrivacy. IEEE, 2008, pp. 111125.

[39] M. Chase, A. Healy, A. Lysyanskaya, T. Malkin, and L. Reyzin,Mercurial commitments with applications to zero-knowledgesets, in EUROCRYPT 05, vol. 3494, 2005, pp. 422439.

[40] J. Camenisch and A. Lysyanskaya, An efficient systemfor non-transferable anonymous credentials with optionalanonymity revocation, in EUROCRYPT 01, vol. 2045 ofLCNS, 2001, pp. 93118.

[41] , Dynamic accumulators and application to efficientrevocation of anonymous credentials, in CRYPTO 02, 2002,extended Abstract. [Online]. Available: http://cs.brown.edu/anna/papers/camlys02.pdf

[42] D. Pointcheval and J. Stern, Provably secure blind signatureschemes, in ASIACRYPT 96, vol. 1163 of LNCS, 1996, pp.252265.

APPENDIX A.SECURITY PROOFS

A. Proof Sketch of Theorem 4.1

Proof sketch. Consider the following simulation. First, thesimulation generates params Setup(1) and two primesC0, C1 that are uniformly sampled from the set of primenumbers in the range [A ,B].24 A1 takes these values asinput and outputs a set C and transaction string R using

24Where A and B can be chosen with arbitrary polynomial dependenceon the security parameter, as long as 2 < A and B < A2. [41] For a fulldescription, see [41, 3.2 and 3.3].

any strategy it wishes. Next the simulation runs A2 with asimulated25 zero-knowledge signature of knowledge pi and arandom coin serial number S sampled from Zq . Note that ifpi is at least computationally zero-knowledge then with all butnegligible probability, all values provided to A are distributedas in the real protocol. Moreover, all are independent of thebit b. By implication, Pr [ b = b ] = 1/2 + () and Asadvantage is negligible. 2

B. Proof of Theorem 4.2

Proof: Let A be an adversary that wins the Balance gamewith non-negligible advantage . We construct an algorithmB that takes input (p, q, g, h), where G = g = h is asubgroup of Zp of order q, and outputs x Zq such thatgx h (mod p). B works as follows:

On input (p, q, g, h), first generate accumulator param-eters N, u as in the Setup routine and set params (N, u, p, q, g, h). For i = 1 to K, compute (ci, skci) Mint(params), where skci = (Si, ri), and runA(params, c1, . . . , cK). Answer each of As queries toOspend using the appropriate trapdoor information. Let(S1, R1), . . . , (Sl, Rl) be the set of values recorded by theoracle.

At the conclusion of the game, A outputs a set of Mcoins (c1, . . . , c

M ) and a corresponding set of M + 1 valid

tuples (pii, Si, Ri,C

i). For j = 1 to M+1, apply the ZKSoK

extractor to the jth zero-knowledge proof pij to extract thevalues (cj , r

j ) and perform the following steps:

1) If the extractor fails, abort and signal EVENTEXT.2) If cj / Cj , abort and signal EVENTACC.3) If cj {c1, . . . , cK}:

a) If for some i, (Sj , rj ) = (Si, ri) and R

j 6= Ri,

abort and signal EVENTFORGE.b) Otherwise if for some i, (Sj , r

j ) = (Si, ri), abort

and signal EVENTCOL.c) Otherwise set (a, b) = (Si, ri).

4) If for some i, cj = ci , set (a, b) = (S

i, ri ).

If the simulation did not abort, we now have(cj , r

j , S

j , a, b) where (by the soundness of pi) we know

that cj gSjhr

j gahb (mod p). To solve for logg h,

output (Sj a) (b rj)1 mod q.Analysis. Let us briefly explain the conditions behind thisproof. When the simulation does not abort, we are able toextract (c1, . . . , c

M+1) where the win conditions enforce that

j [1,M + 1], cj Cj {c1, . . . , cK , c1, . . . , cM} andeach Sj is distinct (and does not match any serial numberoutput by Ospend). Since A has produced M coins and yetspent M + 1, there are only two possibilities:

1) A has spent one of the challengers coins but hasprovided a new serial number for it. For some (i, j),

25Our proofs assume the existence of an efficient simulator and extractorfor the ZKSoK. See Appendix B.

cj = ci {c1, . . . , cK}. Observe that in cases wherethe simulation does not abort, the logic of the simu-lation always results in a pair (a, b) = (Si, ri) wheregahb gSjhrj cj (mod p) and (a, b) 6= (Sj , rj ).

2) A has spent the same coin twice. For some (i, j),cj = c

i and yet (S

j 6= Si). Thus again we identify

a pair (a, b) = (Si, ri ) that satisfies g

ahb cj(mod p) where (a, b) 6= (Sj , rj ).

Finally, we observe that given any such pair (a, b) we cansolve for x = logg h using the equation above.

Abort probability. It remains only to consider the probabilitythat the simulation aborts. Let 1() be the (negligible)probability that the extractor fails on input pi. By sum-mation, Pr [ EVENTEXT ] (M + 1)1(). Next considerthe probability of EVENTCOL. This implies that for somei, A has produced a pair (Sj , rj ) = (Si, ri) where Sjhas not been produced by Ospend. Observe that there arel distinct pairs (S, r) that satisfy cj = g

Shr mod p andAs view is independent of the specific pair chosen. ThusPr [ EVENTCOL ] 1/l.

Next, we argue that under the Strong RSA and Dis-crete Log assumptions, Pr [ EVENTACC ] 2() andPr [ EVENTFORGE ] 3(). We show this in Lemmas A.1and A.2 below. If A succeeds with advantage , then bysumming the above probabilities we show that B succeedswith probability ((M+1)1()+2()+3()+1/l).We conclude with the remaining Lemmas.

Lemma A.1: Under the Strong RSA assumption,Pr [ EVENTACC ] 2().Proof sketch. The basic idea of this proof is that an A whoinduces EVENTACC with non-negligible probability can beused to find a witness to the presence of a non-member in agiven accumulator. Given this value, we apply the techniqueof [12, 3] to solve the Strong RSA problem. For the completedetails we refer the reader to [12, 3] and simply outline theremaining details of the simulation.

Let A be an adversary that induces EVENTACC with non-negligible probability in the simulation above. We useA to construct a Strong RSA solver B that succeeds withnon-negligible probability. On input a Strong RSA instance(N, u), B selects (p, q, g, h) as in Setup and sets params =(N, u, p, q, g, h). It generates (c1, . . . , cK) as in the previoussimulation and runs A. To induce EVENTACC, A producesvalid output (pi,C) and (by extraction from pi) a c / C.B now extracts from pi using the technique describedin [12, 3] and uses the resulting value to compute a solutionto the Strong RSA instance. 2

Lemma A.2: Under the Discrete Logarithm assumption,Pr [ EVENTFORGE ] 3().Proof sketch. We leave a proof for the full version of thispaper, but it is similar to those used by earlier schemes,

e.g., [25]. Let A be an adversary that induces EVENTFORGEwith non-negligible probability in the simulation above.On input a discrete logarithm instance, we run A as inthe main simulation except that we do not use the trapdoorinformation to answer As oracle queries. Instead we selectrandom serial numbers and simulate the ZKSoK responsesto A by programming the random oracle. When A outputsa forgery on a repeated serial number but a different stringR than used in any previous proof, we rewind A to extractthe pair (Sj , r

j ) and solve for the discrete logarithm as in

the main simulation. 2

APPENDIX B.ZERO-KNOWLEDGE PROOF CONSTRUCTION

The signature of knowledge

pi = ZKSoK[R]{(c, w, r) :AccVerify((N, u), A, c, w) = 1 c = gShr}

is composed of two proofs that (1) a committed value cis accumulated and (2) that c is a commitment to S. Theformer proof is detailed in [41, 3.3 and Appendix A]. Thelatter is a double discrete log signature of knowledge that,although related to previous work [21, 5.3.3], is new (atleast to us). A proof of its security can be found in the fullversion of this paper. It is constructed as follows:

Given y1 = gaxbzhw.

Let l k be two security parameters and H :{0, 1} {0, 1}k be a cryptographic hash func-tion. Generate 2l random numbers r1, . . . , rl andv1, . . . , vl. Compute, for 1 i l, ti = gaxbrihvi .The signature of knowledge on the message m is(c, s1, s2, . . . , sl, s

1, s2, . . . , s

l), where:

c = H(my1abghxt1 . . . tl)and

if c[i] = 0 then si = ri, si = vi;else si = ri z, si = vi wbriz;

To verify the signature it is sufficient to compute:

c = H(my1abghxt1 . . . tl)with

if c[i] = 0 then ti = gaxbsihs

i ;

else ti = ybsi

1 hsi ;

and check whether c = c.

Simulating and extracting. Our proofs in Appendix A assumethe existence of an efficient simulator and extractor for thesignature of knowledge. These may be constructed using well-understood results in the random oracle model, e.g., [25, 42].We provide further details in the full version of this work.