-
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.