Zerocash: Decentralized Anonymous Payments from Bitcoin

Eli Ben-Sasson∗, Alessandro Chiesa†, Christina Garman‡, Matthew Green‡, Ian Miers‡, Eran Tromer§, Madars Virza† ∗Technion, [email protected] †MIT, {alexch, madars}@mit.edu ‡Johns Hopkins University, {cgarman, imiers, mgreen}@cs.jhu.edu §Tel Aviv University, [email protected]

Abstract—Bitcoin is the first digital currency to see widespread party and then, after some interval, retrieve different coins adoption. While payments are conducted between pseudonyms, (with the same total value) from the pool. Yet, mixes suffer Bitcoin cannot offer strong privacy guarantees: payment trans- from three limitations: (i) the delay to reclaim coins must be actions are recorded in a public decentralized ledger, from which much information can be deduced. Zerocoin (Miers et large to allow enough coins to be mixed in; (ii) the mix can 1 al., IEEE S&P 2013) tackles some of these privacy issues by trace coins; and (iii) the mix may steal coins. For users with unlinking transactions from the payment’s origin. Yet, it still “something to hide,” these risks may be acceptable. But typical reveals payments’ destinations and amounts, and is limited in legitimate users (1) wish to keep their spending habits private functionality. from their peers, (2) are risk-averse and do not wish to expend In this paper, we construct a full-fledged ledger-based digital currency with strong privacy guarantees. Our results leverage continual effort in protecting their privacy, and (3) are often recent advances in zero-knowledge Succinct Non-interactive AR- not sufficiently aware of their compromised privacy. guments of Knowledge (zk-SNARKs). To protect their privacy, users thus need an instant, risk-free, First, we formulate and construct decentralized anonymous and, most importantly, automatic guarantee that data revealing payment schemes (DAP schemes). A DAP scheme enables users to their spending habits and account balances is not publicly directly pay each other privately: the corresponding transaction hides the payment’s origin, destination, and transferred amount. accessible by their neighbors, co-workers, and merchants. We provide formal definitions and proofs of the construction’s Anonymous transactions also guarantee that the market value security. of a coin is independent of its history, thus ensuring legitimate Second, we build Zerocash, a practical instantiation of our users’ coins remain fungible.2 DAP scheme construction. In Zerocash, transactions are less than 1 kB and take under 6 ms to verify — orders of magnitude more Zerocoin: a decentralized mix. Miers et al. [8] proposed efficient than the less-anonymous Zerocoin and competitive with Zerocoin, which extends Bitcoin to provide strong anonymity plain Bitcoin. guarantees. Like many e-cash protocols (e.g., [2]), Zerocoin employs zero-knowledge proofs to prevent transaction graph Keywords: Bitcoin, decentralized electronic cash, zero knowledge analyses. Unlike earlier practical e-cash protocols, however, Zerocoin does not rely on digital signatures to validate coins, I. INTRODUCTION nor does it require a central bank to prevent double spending. Instead, Zerocoin authenticates coins by proving, in zero- Bitcoin is the first digital currency to achieve widespread knowledge, that they belong to a public list of valid coins adoption. The currency owes its rise in part to the fact that, (which can be maintained on the block chain). Yet, rather than unlike traditional e-cash schemes [1, 2, 3], it requires no trusted a full-fledged anonymous currency, Zerocoin is a decentralized parties. Instead of appointing a central bank, Bitcoin leverages a mix, where users may periodically “wash” their bitcoins via distributed ledger known as the block chain to store transactions the Zerocoin protocol. Routine day-to-day transactions must made between users. Because the block chain is massively be conducted via Bitcoin, due to reasons that we now review. replicated by mutually-distrustful peers, the information it The first reason is performance. Redeeming zerocoins contains is public. requires double-discrete-logarithm proofs of knowledge, which While users may employ many identities (or pseudonyms) have size that exceeds 45 kB and require 450 ms to verify (at to enhance their privacy, an increasing body of research shows the 128-bit security level).3 These proofs must be broadcast that anyone can de-anonymize Bitcoin by using information in the block chain [4, 5, 6], such as the structure of the transaction 1CoinJoin [7], an alternative proposal, replaces the central party of a mix graph as well as the value and dates of transactions. As a result, with multi-signature transactions that involve many collaborating Bitcoin users. Bitcoin fails to offer even a modicum of the privacy provided CoinJoin can thus only mix small volumes of coins amongst users who are currently online, is prone to denial-of-service attacks by third parties, and by traditional payment systems, let alone the robust privacy of requires effort to find mixing partners. anonymous e-cash schemes. 2While the methods we detail in this paper accomplish this, the same While Bitcoin is not anonymous itself, those with sufficient techniques open the door for privacy preserving accountability and oversight motivation can obfuscate their transaction history with the help (see Section X). 3These published numbers [8] actually use a mix of parameters at both of mixes (also known as laundries or tumblers). A mix allows 128-bit and 80-bit security for different components of the construction. The users to entrust a set of coins to a pool operated by a central cost is higher if all parameters are instantiated at the 128-bit security level. through the network, verified by every node, and permanently is succinct, i.e., for which proofs are very short and easy to stored in the ledger. The entailed costs are higher, by orders verify. More precisely, let L be an NP language, and let C be a of magnitude, than those in Bitcoin and can seriously tax a nondeterministic decision circuit for L on a given instance size Bitcoin network operating at normal scale. n.Azk-SNARK can be used to prove and verify membership The second reason is functionality. While Zerocoin consti- in L, for instances of size n, as follows. After taking C as tutes a basic e-cash scheme, it lacks critical features required input, a trusted party conducts a one-time setup phase that of full-fledged anonymous payments. First, Zerocoin uses results in two public keys: a proving key pk and a verification coins of fixed denomination: it does not support payments key vk. The proving key pk enables any (untrusted) prover of exact values, nor does it provide a means to make change to produce a proof π attesting to the fact that x ∈L, for an following a transaction (i.e., divide coins). Second, Zerocoin instance x (of size n) of his choice. The non-interactive proof has no mechanism for one user to pay another one directly π is zero knowledge and a proof of knowledge. Anyone can in “zerocoins.” And third, while Zerocoin provides anonymity use the verification key vk to verify the proof π; in particular by unlinking a payment transaction from its origin address, it zk-SNARK proofs are publicly verifiable: anyone can verify π, does not hide the amount or other metadata about transactions without ever having to interact with the prover that generated occurring on the network. π. Succinctness requires that (for a given security level) π has Our contribution. In this work we address the aforemen- constant size and can be verified in time that is linear in |x| tioned issues via two main contributions. (rather than linear in |C|). (1) We introduce the notion of a decentralized anonymous B. Decentralized anonymous payment schemes payment scheme, which formally captures the functionality and We construct a decentralized anonymous payment (DAP) security guarantees of a full-fledged decentralized electronic scheme, which is a decentralized e-cash scheme that allows currency with strong anonymity guarantees. We provide a con- direct anonymous payments of any amount. See Section III for struction of this primitive and prove its security under specific a formal definition. Here, we outline our construction in six cryptographic assumptions. The construction leverages recent incremental steps; the construction details are in Section IV. advances in the area of zero-knowledge proofs. Specifically, it Our construction functions on top of any ledger-based base uses zero-knowledge Succinct Non-interactive ARguments of currency, such as Bitcoin. At any given time, a unique valid Knowledge (zk-SNARKs) [9, 10, 11, 12, 13, 14, 15, 16]. snapshot of the currency’s ledger is available to all users. (2) We achieve an implementation of the above primitive, via The ledger is a sequence of transactions and is append- a system that we call Zerocash. Compared to Zerocoin, our only. Transactions include both the underlying currency’s system (at 128 bits of security): transactions, as well as new transactions introduced by our • Reduces the size of transactions spending a coin by 97.7%. construction. For concreteness, we focus the discussion below • Reduces the spend-transaction verification time by 98.6%. on Bitcoin (though later definitions and constructions are • Allows for anonymous transactions of variable amounts. stated abstractly). We assume familiarity with Bitcoin [20] • Hides transaction amounts and the values of coins held by and Zerocoin [8]. users. Step 1: user anonymity with fixed-value coins. We first • Allows for payments to be made directly to a user’s fixed describe a simplified construction, in which all coins have address (without user interaction). the same value of, e.g., 1 BTC. This construction, similar To validate our system, we measured its performance and to the Zerocoin protocol, shows how to hide a payment’s established feasibility by conducting experiments in a test origin. In terms of tools, we make use of zk-SNARKs (recalled 1 network of 1000 nodes (approximately 16 of the unique IPs above) and a commitment scheme. Let COMM denote a 1 in the Bitcoin network and 3 of the nodes reachable at any statistically-hiding non-interactive commitment scheme (i.e., given time [17]). This inspires confidence that Zerocash can given randomness r and message m, the commitment is be deployed as a fork of Bitcoin and operate at the same c := COMMr(m); subsequently, c is opened by revealing scale. Thus, due to its significantly improved functionality and r and m, and one can verify that COMMr(m) equals c). performance, Zerocash makes it possible to entirely replace In the simplified construction, a new coin c is minted as traditional Bitcoin payments with anonymous alternatives. follows: a user u samples a random serial number sn and a r Concurrent work. The idea of using zk-SNARKs in the trapdoor , computes a coin commitment cm := COMMr(sn), c r, , setting of Bitcoin was first presented by one of the authors and sets := ( sn cm). A corresponding mint transaction r at Bitcoin 2013 [18]. In concurrent work, Danezis et al. [19] txMint, containing cm (but not sn or ), is sent to the ledger; u suggest using zk-SNARKs to reduce proof size and verification txMint is appended to the ledger only if has paid 1 BTC time in Zerocoin; see Section IX for a comparison. to a backing escrow pool (e.g., the 1 BTC may be paid via plaintext information encoded in txMint). Mint transactions A. zk-SNARKs are thus certificates of deposit, deriving their value from the We now sketch in more technical terms the definition of backing pool. a zk-SNARK; see Section II for more details. A zk-SNARK Subsequently, letting CMList denote the list of all coin is a non-interactive zero-knowledge proof of knowledge that commitments on the ledger, u may spend c by posting a spend transaction txSpend that contains (i) the coin’s serial number commitment, and using pseudorandom functions to target sn; and (ii) a zk-SNARK proof π of the NP statement “I know payments and to derive serial numbers, as follows. We use three r such that COMMr(sn) appears in the list CMList of coin pseudorandom functions (derived from a single one). For a addr sn pk commitments”. Assuming that sn does not already appear on seed x these are denoted PRFx (·), PRFx (·), and PRFx (·). sn the ledger (as part of a past spend transaction), u can redeem We assume that PRF is moreover collision-resistant. the deposited amount of 1 BTC, which u can either keep for To provide targets for payments, we use addresses: each himself, transfer to someone else, or immediately deposit into user u generates an address key pair (apk,ask). The coins of a new coin. (If sn does already appear on the ledger, this is u contain the value apk and can be spent only with knowledge considered double spending, and the transaction is discarded.) of ask. A key pair (apk,ask) is sampled by selecting a random User anonymity is achieved because the proof π is zero- a a addr seed sk and setting pk := PRFask (0). A user can generate knowledge: while sn is revealed, no information about r and use any number of address key pairs. is, and finding which of the numerous commitments in Next, we re-design minting to allow for greater functionality. CMList corresponds to a particular spend transaction txSpend is To mint a coin c of a desired value v, the user u first samples ρ, f x equivalent to inverting ( ):=COMMx(sn), which is assumed which is a secret value that determines the coin’s serial number to be infeasible. Thus, the origin of the payment is anonymous. sn as sn := PRFa (ρ). Then, u commits to the tuple (apk,v,ρ) in sku k a ρ Step 2: compressing the list of coin commitments. In the two phases: (a) computes := COMMr( pk ) for a random above NP statement, CMList is specified explicitly as a list of r; and then (b) u computes cm := COMMs(vk) for a random s c a ,v,ρ,r,s, coin commitments. This naive representation severely limits . The minting results in a coin := ( pk cm) and a v, k, s, scalability because the time and space complexity of most mint transaction txMint := ( cm). Crucially, due to the protocol algorithms (e.g., the proof verification algorithm) nested commitment, anyone can verify that cm in txMint is grows linearly with CMList. Moreover, coin commitments a coin commitment of a coin of value v (by checking that corresponding to already spent coins cannot be dropped from COMMs(vk) equals cm) but cannot discern the owner (by a CMList to reduce costs, since they cannot be identified (due to learning the address key pk) or serial number (derived from ρ k the same zero-knowledge property that provides anonymity). ) because these are hidden in . As before, txMint is accepted As in [3], we rely on a collision-resistant hash function CRH by the ledger only if u deposits the correct amount, in this to avoid an explicit representation of CMList. We maintain case v BTC. an efficiently updatable append-only CRH-based Merkle tree Coins are spent using the pour operation, which takes a set Tree(CMList) over the (growing) list CMList. Letting rt denote of input coins, to be consumed, and “pours” their value into a the root of Tree(CMList), it is well-known that updating rt to set of fresh output coins — such that the total value of output account for insertion of new leaves can be done with time and coins equals the total value of the input coins. Suppose that u aold,aold space proportional to the tree depth. Hence, the time and space , with address key pair ( pk sk ), wishes to consume his cold aold,vold,ρold,rold,sold, old complexity is reduced from linear in the size of CMList to coin =( pk cm ) and produce two new new new new old logarithmic. With this in mind, we modify the NP statement to new coins c1 and c2 , with total value v1 + v2 = v , r r anew anew the following one: “I know such that COMM (sn) appears as respectively targeted at address public keys pk,1 and pk,2. anew anew u a leaf in a CRH-based Merkle tree whose root is rt”. Compared (The addresses pk,1 and pk,2 may belong to or to some with the naive data structure for CMList, this modification other user.) The user u, for each i ∈{1, 2}, proceeds as follows: new increases exponentially the size of CMList which a given (i) u samples serial number randomness ρi ; (ii) u computes new new new new zk-SNARK implementation can support (concretely, using trees ki := COMMrnew (a ,iρi ) for a random ri ; and (iii) u 64 i pk new new vnewknew snew of depth 64, Zerocash supports 2 coins). computes cmi := COMMsi ( i i ) for a random i . cnew anew ,vnew,ρnew,rnew,snew, Step 3: extending coins for direct anonymous payments. This yields the coins 1 := ( pk,1 1 1 1 1 new cnew anew ,vnew,ρnew,rnew,snew, new So far, the coin commitment cm of a coin c is a commitment cm1 ) and 2 := ( pk,2 2 2 2 2 cm2 ). u π to the coin’s serial number sn. However, this creates a problem Next, produces a zk-SNARK proof POUR for the following when transferring c to another user. Indeed, suppose that a user NP statement, which we call POUR: u c u c u A created , and A sends to another user B. First, since old u c u “Given the Merkle-tree root rt, serial number sn , A knows sn, the spending of by B is both not anonymous new, new u c and coin commitments cm1 cm2 , I know coins (since A sees when is spent, by recognizing sn) and risky cold, cnew, cnew aold 1 2 , and address secret key sk such that: uA c uB (since could still spend first). Thus, must immediately • cold kold c c The coins are well-formed: for it holds that = spend and mint a new coin to protect himself. Second, if aoldρold old voldkold u u COMMrold ( pk ) and cm = COMMsold ( ); A in fact wants to transfer to B, e.g., 100 BTC, then doing new new and similarly for c1 and c2 . so is both unwieldy (since it requires 100 transfers) and not • aold The address secret key matches the public key: pk = anonymous (since the amount of the transfer is leaked). And addr PRFaold (0). third, transfers in amounts that are not multiples of 1 BTC (the sk old fixed value of a coin) are not supported. Thus, the simplified • The serial number is computed correctly: sn := sn old PRFaold (ρ ). construction described is inadequate as a payment scheme. sk We address this by modifying the derivation of a coin • The coin commitment cmold appears as a leaf of a Merkle- tree with root rt. equation in the NP statement POUR is changed accordingly: new new old new new old old • The values add up: v1 + v2 = v .” “v1 + v2 + vpub = v ”. Thus, of the input value v , a part v is publicly declared, and its target is specified, A resulting pour transaction , old, new, pub txPour := (rt sn cm1 somehow, by the string info. The string info can be used to new,π cm2 POUR) is appended to the ledger. (As before, the specify the destination of these redeemed funds (e.g., a Bitcoin transaction is rejected if the serial number appears in a sn wallet public key).4 Both v and info are now included in the previous transaction.) pub resulting pour transaction tx . (The public output is optional, Now suppose that u does not know, say, the address secret Pour as the user u can set v .) anew anew u pub =0 key sk,1 that is associated with the public key pk,1. Then, cnew anew Step 6: non-malleability. To prevent malleability attacks on cannot spend 1 because he cannot provide sk,1 as part of the witness of a subsequent pour operation. Furthermore, when a pour transaction txPour (e.g., embezzlement by re-targeting anew cnew u the public output of the pour by modifying info), we further a user that knows sk,1 does spend 1 , the user cannot track it, because he knows no information about its revealed modify the NP statement POUR and use digital signatures. new sn new u serial number, which is sn1 := PRFanew (ρ1 ). Specifically, during the pour operation, the user (i) samples sk,1 , Also observe that tx reveals no information about how a key pair (pksig sksig) for a one-time signature scheme; Pour h the value of the consumed coin was divided among the two (ii) computes Sig := CRH(pksig); (iii) computes the two values h pk h h pk h new fresh coins, nor which coin commitment corresponds to 1 := PRFaold ( Sig) and 2 := PRFaold ( Sig), which act as sk,1 sk,2 the consumed coin, nor the address public keys to which the MACs to “tie” hSig to both address secret keys; (iv) modifies two new fresh coins are targeted. The payment was conducted POUR to include the three values hSig,h1,h2 and prove that in full anonymity. the latter two are computed correctly; and (v) uses sksig to sign More generally, a user may pour N old ≥ 0 coins into N new ≥ every value associated with the pour operation, thus obtaining N old N new σ 0 coins. For simplicity we consider the case = =2, a signature , which is included, along with pksig,intxPour. N old < aold h without loss of generality. Indeed, for 2, the user can Since the sk,i are secret, and with high probability Sig changes mint a coin with value 0 and then provide it as a “null” input, for each pour transaction, the values h1,h2 are unpredictable. and for N new < 2, the user can create (and discard) a new Moreover, the signature on the NP statement (and other values) coin with value 0. For N old > 2 or N new > 2, the user can binds all of these together. compose log N old +logN new of the 2-input/2-output pours. anew Step 4: sending coins. Suppose that pk,1 is the address public This ends the outline of the construction, which is summarized key of u1. In order to allow u1 to actually spend the new coin in part in Figure 1. We conclude by noting that, due to new c1 produced above, u must somehow send the secret values the zk-SNARK, our construction requires a one-time trusted new in c1 to u1. One way is for u to send u1 a private message, setup of public parameters. The trust affects soundness of the but the requisite private communication channel necessitates proofs, though anonymity continues to hold even if the setup additional infrastructure or assumptions. We avoid this “out- is corrupted by a malicious party. of-band” channel and instead build this capability directly into our construction by leveraging the ledger as follows. C. Zerocash We modify the structure of an address key pair. Each We outline Zerocash, a concrete implementation, at 128 user now has a key pair (addrpk, addrsk), where addrpk = a , a , a ,a bits of security, of our DAP scheme construction; see Sec- ( pk pkenc) and addrsk =(sk skenc). The values ( pk sk) , tion V for details. Zerocash entails carefully instantiating are generated as before. In addition, (pkenc skenc) is a key pair for a key-private encryption scheme [21]. the cryptographic ingredients of the construction to ensure that the zk-SNARK, the “heaviest” component, is efficient Then, u computes the ciphertext C1 that is the encryption vnew,ρnew,rnew,snew new enough in practice. In the construction, the zk-SNARK is of the plaintext ( 1 1 1 1 ), under pkenc,1 (which new used to prove/verify a specific NP statement: POUR. While is part of u1’s address public key addr ,1), and includes C1 sk zk-SNARKs are asymptotically efficient, their concrete effi- in the pour transaction txPour. The user u1 can then find and new ciency depends on the arithmetic circuit C that is used to decrypt this message (using his sk ,1) by scanning the pour enc decide the NP statement. Thus, we seek instantiations for which transactions on the public ledger. Again, note that adding C1 we can design a relatively-small arithmetic circuit CPOUR for to txPour leaks neither paid amounts, nor target addresses due to the key-private property of the encryption scheme. (The verifying the NP statement POUR. new Our approach is to instantiate all of the necessary cryp- user u does the same with c2 and includes a corresponding tographic ingredients (commitment schemes, pseudorandom ciphertext C2 in txPour.) functions, and collision-resistant hashing) based on SHA256. Step 5: public outputs. The construction so far allows users We first design a hand-optimized circuit for verifying SHA256 to mint, merge, and split coins. But how can a user redeem computations (or, more precisely, its compression function, one of his coins, i.e., convert it back to the base currency

(Bitcoin)? For this, we modify the pour operation to include a 4 u These public outputs can be considered as an “input” to a Bitcoin-style public output. When spending a coin, the user also specifies transaction, where the info string contains the Bitcoin output scripts. This a nonnegative vpub and an arbitrary string info. The balance mechanism also allows us to support Bitcoin’s public transaction fees. rt = Merkle-tree root (a) Merke tree over (cm1,cm2,…) (b) coin cm = coin commitment rt c = ((a ,pk ), v, ρ, r, s, cm) pk enc sn = serial number CRH (c) coin commitment (d) serial number v = coin value cm sn r, s = commitment rand. CRH CRH ρ = serial number rand. sn COMM PRF (apk,pkenc) = address public key s  CRH (ask,skenc) = address secret key v CRH CRH COMM r ρ CRH CRH CRH CRH addr  PRF
 cm1 cm2 cm3 cm4cm5 cm6 cm7 cm8 … 

Fig. 1: (a) Illustration of the CRH-based Merkle tree over the list CMList of coin commitments. (b) A coin c. (c) Illustration of the structure of a coin commitment cm. (d) Illustration of the structure of a coin serial number sn. which suffices for our purposes).5 Then, we use this circuit in A. Informal definition C constructing POUR, which verifies all the necessary checks for We informally define zk-SNARKs for arithmetic circuit C satisfying the NP statement POUR. satisfiability. We refer the reader to, e.g., [11] for a formal This, along with judicious parameter choices, and a state-of- definition. the-art implementation of a zk-SNARK for arithmetic circuits For a field F,anF-arithmetic circuit takes inputs that are [16] (see Section II-C), results in a zk-SNARK prover running elements in F, and its gates output elements in F. We naturally time of few minutes and zk-SNARK verifier running time of associate a circuit with the function it computes. To model few milliseconds. This allows the DAP scheme implementation nondeterminism we consider circuits that have an input x ∈ to be practical for deployment, as our experiments show. Fn and an auxiliary input a ∈ Fh, called a witness. The Zerocash can be integrated into Bitcoin or forks of it circuits we consider only have bilinear gates.6 Arithmetic (commonly referred to as “altcoins”); we later describe how circuit satisfiability is defined analogously to the boolean case, this is done. as follows.

D. Paper organization Definition II.1. The arithmetic circuit satisfiability problem of an F-arithmetic circuit C : Fn × Fh → Fl is captured by the n h l The remainder of this paper is organized as follows. relation RC = {(x, a) ∈ F ×F : C(x, a)=0}; its language n h l Section II provides background on zk-SNARKs. We define is LC = {x ∈ F : ∃ a ∈ F s.t. C(x, a)=0}. DAP schemes in Section III, and our construction thereof in F Section IV. Section V discusses the concrete instantiation in Given a field , a (publicly-verifiable preprocessing) F Zerocash. Section VI describes the integration of Zerocash zk-SNARK for -arithmetic circuit satisfiability is a triple , , into existing ledger-based currencies. Section VII provides of polynomial-time algorithms (KeyGen Prove Verify): λ microbenchmarks for our prototype implementation, as well • KeyGen(1 ,C) → (pk, vk). On input a security parameter as results based on full-network simulations. Section VIII λ (presented in unary) and an F-arithmetic circuit C, the describes optimizations. We discuss concurrent work in Sec- key generator KeyGen probabilistically samples a proving tion IX and summarize our contributions and future directions key pk and a verification key vk. Both keys are published as in Section X. public parameters and can be used, any number of times, to prove/verify membership in LC . II. BACKGROUND ON ZK-SNARKS • Prove(pk,x,a) → π. On input a proving key pk and any (x, a) ∈RC , the prover Prove outputs a non-interactive The main cryptographic primitive used in this paper is proof π for the statement x ∈LC . a special kind of Succinct Non-interactive ARgument of • Verify(vk,x,π) → b. On input a verification key vk, an input Knowledge (SNARK). Concretely, we use a publicly-verifiable x, and a proof π, the verifier Verify outputs b =1if he is preprocessing zero-knowledge SNARK, or zk-SNARK for short. convinced that x ∈LC . In this section we provide basic background on zk-SNARKs, A zk-SNARK satisfies the following properties. provide an informal definition, and recall known constructions and implementations. Completeness. For every security parameter λ,anyF- arithmetic circuit C, and any (x, a) ∈RC , the honest prover 5Alternatively, we could have opted to rely on the circuit generators [13, 14, 6 16], which support various classes of C programs, by writing C code expressing A gate with inputs y1,...,ym ∈ F is bilinear if the output is m+1 the POUR checks. However, as discussed later, these generic approaches are a, (1,y1,...,ym)·b, (1,y1,...,ym) for some a, b ∈ F . These more expensive than our hand-optimized construction. include addition, multiplication, negation, and constant gates. can convince the verifier. Namely, b =1with probabil- that supports programs that modify their own code (e.g., for ity 1 − negl(λ) in the following experiment: (pk, vk) ← runtime code generation); their implementation also reduces KeyGen(1λ,C); π ← Prove(pk,x,a); b ← Verify(vk,x,π). costs for programs of larger size and allows for universal key Succinctness. An honestly-generated proof π has Oλ(1) bits pairs. and Verify(vk,x,π) runs in time Oλ(|x|). (Here, Oλ hides a Each of the works above also achieves zk-SNARKs for fixed polynomial factor in λ.) arithmetic circuit satisfiability as a stepping stone towards their respective higher-level efforts. In this paper we are only Proof of knowledge (and soundness). If the verifier accepts interested in a zk-SNARK for arithmetic circuit satisfiability, a proof output by a bounded prover, then the prover “knows” and we rely on the implementation of [16] for such a a witness for the given instance. (In particular, soundness zk-SNARK.9 The implementation in [16] is itself based on the holds against bounded provers.) Namely, for every poly(λ)- protocol of Parno et al. [13]. We thus refer the interested reader size adversary A, there is a poly(λ)-size extractor E such that to [13] for details of the protocol, its intuition, and its proof of Verify(vk,x,π)=1and (x, a) ∈RC with probability negl(λ) security; and to [16] for the implementation and its performance. in the following experiment: (pk, vk) ← KeyGen(1λ,C); In terms of concrete parameters, the implementation of [16] (x, π) ←A(pk, vk); a ←E(pk, vk). provides 128 bits of security, and the field F is of a 256-bit Perfect zero knowledge. An honestly-generated proof is per- prime order p. fect zero knowledge.7 Namely, there is a poly(λ)-size simulator Sim such that for all stateful poly(λ)-size distinguishers D the III. DEFINITION OF A DECENTRALIZED ANONYMOUS following two probabilities are equal: PAYMENT SCHEME • The probability that D(π)=1on an honest proof. ⎡  ⎤ We introduce the notion of a decentralized anonymous  (pk, vk) ← KeyGen(C) (x, a) ∈R  payment scheme (DAP scheme), extending the notion of Pr ⎣ C  (x, a) ←D(pk, vk) ⎦ D(π)=1  decentralized e-cash [8]. Later, in Section IV, we provide  π ← Prove(pk,x,a) a construction. • The probability that D(π)=1on a simulated proof. ⎡  ⎤ A. Data structures  (pk, vk, trap) ← Sim(C) (x, a) ∈R  Pr ⎣ C  (x, a) ←D(pk, vk) ⎦ We begin by describing, and giving intuition about, the data D(π)=1   π ← Sim(pk,x,trap) structures used by a DAP scheme. The algorithms that use and produce these data structures are introduced in Section III-B. B. Known constructions and security Basecoin ledger. Our protocol is applied on top of a ledger- There are many zk-SNARK constructions in the literature based base currency such as Bitcoin; for generality we refer T [9, 10, 11, 12, 13, 14, 15, 16]. We are interested in zk-SNARKs to this base currency as Basecoin. At any given time , all L T for arithmetic circuit satisfiability, and the most efficient ones users have access to T , the ledger at time , which is a sequence of transactions. The ledger is append-only (i.e., T< for this language are based on quadratic arithmetic programs T L L  10 [12, 11, 13, 14, 16]; such constructions provide a linear-time implies that T is a prefix of T ). The transactions in KeyGen, quasilinear-time Prove, and linear-time Verify. the ledger include both Basecoin transactions as well as two Security of zk-SNARKs is based on knowledge-of-exponent new transaction types described below. assumptions and variants of Diffie–Hellman assumptions in Public parameters. A list of public parameters pp is available bilinear groups [9, 22, 23]. While knowledge-of-exponent to all users in the system. These are generated by a trusted party assumptions are fairly strong, there is evidence that such at the “start of time” and are used by the system’s algorithms. assumptions may be inherent for constructing zk-SNARKs Addresses. Each user generates at least one address key [24, 25]. pair (addrpk, addrsk). The public key addrpk is published and C. zk-SNARK implementations enables others to direct payments to the user. The secret key addr is used to receive payments sent to addr . A user may There are three published implementations of zk-SNARKs: sk pk generate any number of address key pairs. (i) Parno et al. [13] present an implementation of zk-SNARKs c for programs having no data dependencies;8 (ii) Ben-Sasson Coins. A coin is a data object , to which we associate the et al. [14] present an implementation of zk-SNARKs for following: arbitrary programs (with data dependencies); and (iii) Ben- • A coin commitment, denoted cm(c): a string that appears Sasson et al. [16] present an implementation of zk-SNARKs on the ledger once c is minted.

7While most zk-SNARK descriptions in the literature only mention statistical 9In [16], one optimization to the verifier’s runtime requires preprocessing zero knowledge, all zk-SNARK constructions can be made perfect zero the verification key vk; for simplicity, we do not use this optimization. knowledge by allowing for a negligible error probability in completeness. 10In reality, the Basecoin ledger (such as the one of Bitcoin) is not perfect 8They only support programs where array indices are restricted to be known and may incur temporary inconsistencies. In this respect our construction is compile-time constants; similarly, loop iteration counts (or at least upper as good as the underlying ledger. We discuss the effects of this on anonymity bounds to these) must be known at compile time. and mitigations in Section VI-C. • A coin value, denoted v(c): the denomination of c,as with the following syntax and semantics. measured in basecoins, as an integer between 0 and a System setup. The algorithm Setup generates a list of public v maximum value max (which is a system parameter). parameters: • A coin serial number, denoted sn(c): a unique string associated with the c, used to prevent double spending. Setup • λ • A coin address, denoted addrpk(c): an address public key, INPUTS: security parameter representing who owns c. • OUTPUTS: public parameters pp Any other quantities associated with a coin c (e.g., various The algorithm Setup is executed by a trusted party. The trapdoors) are implementation details. resulting public parameters pp are published and made available New transactions. Besides Basecoin transactions, there are to all parties (e.g., by embedding them into the protocol’s two new types of transactions. implementation). The setup is done only once; afterwards, no • Mint transactions. A mint transaction txMint is a tuple trusted party is needed, and no global secrets or trapdoors are ,v,∗ v (cm ), where cm is a coin commitment, is a coin value, kept. and ∗ denotes other (implementation-dependent) information. Creating payment addresses. The algorithm CreateAddress The transaction tx records that a coin c with coin Mint generates a new address key pair: commitment cm and value v has been minted. • Pour transactions. A pour transaction txPour is a tuple CreateAddress , old, old, new, new,v , , ∗ (rt sn1 sn2 cm1 cm2 pub info ), where rt is a root • INPUTS: public parameters pp old, old of a Merkle tree, sn1 sn2 are two coin serial numbers, • OUTPUTS: address key pair (addr , addr ) new new pk sk cm1 , cm2 are two coin commitments, vpub is a coin value, info is an arbitrary string, and ∗ denotes other Each user generates at least one address key pair (implementation-dependent) information. The transaction (addrpk, addrsk) in order to receive coins. The public key addrpk txPour records the pouring of two input (and now consumed) is published, while the secret key addrsk is used to redeem old old old old coins c1 , c2 , with respective serial numbers sn1 , sn2 , coins sent to addrpk. A user may generate any number of new new into two new output coins c1 , c2 , with respective coin address key pairs; doing so does not require any interaction. new, new v commitments cm1 cm2 , as well as a public output pub Minting coins. The algorithm Mint generates a coin (of a (which may be zero). Furthermore, txPour also records an given value) and a mint transaction: information string info (perhaps containing information on who is the recipient of vpub basecoins) and that, when this Mint transaction was made, the root of the Merkle tree over coin • INPUTS: commitments was rt (see below). – public parameters pp v ∈{ , ,...,v } Commitments of minted coins and serial numbers of spent – coin value 0 1 max coins. For any given time T , – destination address public key addrpk • OUTPUTS: coin c and mint transaction tx • CMListT denotes the list of all coin commitments appearing Mint LT in mint and pour transactions in ; A system parameter, vmax, caps the value of any single coin. • T SNList denotes the list of all serial numbers appearing in The output coin c has value v and coin address addrpk; the LT pour transactions in . output mint transaction txMint equals (cm,v,∗),wherecm is While both of these lists can be deduced from LT , it will be the coin commitment of c. convenient to think about them as separate (as, in practice, Pouring coins. The Pour algorithm transfers value from these may be separately maintained due to efficiency reasons). input coins into new output coins, marking the input coins Merkle tree over commitments. For any given time T , as consumed. Moreover, a fraction of the input value may be TreeT denotes a Merkle tree over CMListT and rtT its root. publicly revealed. Pouring allows users to subdivide coins into Moreover, the function PathT (cm) gives the authentication smaller denominations, merge coins, and transfer ownership path from a coin commitment cm appearing in CMListT to of anonymous coins, or make public payments.12 11 the root of TreeT . For convenience, we assume that LT also stores rtT  for all T ≤ T (i.e., it stores all past Merkle tree Pour roots). • INPUTS: – public parameters pp B. Algorithms – the Merkle root rt old old A DAP scheme Π is a tuple of polynomial-time algorithms – old coins c1 , c2 old , old (Setup, CreateAddress, Mint, Pour, VerifyTransaction, – old addresses secret keys addrsk,1 addrsk,2 old Receive) – authentication path path1 from commitment cm(c1 ) to root rt, 11While we refer to Mekle trees for simplicity, it is straightforward to extend the definition to allow other data structures representing sets with fast insertion 12We consider pours with 2 inputs and 2 outputs, for simplicity and (as and short proofs of membership. discussed in Section I-B) without loss of generality. old , authentication path path2 from commitment cm(c2 ) to When a user with address key pair (addrpk addrsk) wishes to root rt receive payments sent to addrpk, he uses the Receive algorithm new new – new values v1 ,v2 to scan the ledger. For each payment to addrpk appearing in the new , new – new addresses public keys addrpk,1 addrpk,2 ledger, Receive outputs the corresponding coins whose serial L – public value vpub numbers do not appear on the ledger . Coins received in – transaction string info this way may be spent, just like minted coins, using the Pour new new • OUTPUTS: new coins c1 , c2 and pour transaction txPour algorithm. (We only require Receive to detect coins paid to addrpk via the Pour algorithm and not also detect coins minted Thus, the Pour algorithm takes as input two distinct input by the user himself.) old old coins c1 , c2 , along with corresponding address secret keys old , old addrsk,1 addrsk,2 (required to redeem the two input coins). To Next, we describe completeness (Section III-C) and security old old ensure that c1 , c2 have been previously minted, the Pour (Section III-D). algorithm also takes as input the Merkle root rt (allegedly, C. Completeness equal to the root of Merkle tree over all coin commitments so far), along with two authentication paths path1, path2 for the Completeness of a DAP scheme requires that unspent coins old old S two coin commitments cm(c1 ), cm(c2 ). Two input values can be spent. More precisely, consider a ledger sampler new new L c c v1 ,v2 specify the values of two new anonymous coins outputting a ledger .If 1 and 2 are two coins whose coin new new L c1 , c2 to be generated, and two input address public keys commitments appear in (valid) transactions on , but their new , new cnew, cnew serial numbers do not appear in L, then c1 and c2 can be addrpk,1 addrpk,2 specify the recipients of 1 2 . A third value, vpub, specifies the amount to be publicly spent (e.g., spent using Pour. Namely, running Pour results in a pour to redeem coins or pay transaction fees). The sum of output transaction txPour that VerifyTransaction accepts, and the new values v1 + v2 + vpub must be equal to the sum of the values coins can be received by the intended recipients (by using v of the input coins (and cannot exceed vmax). Finally, the Pour Receive); moreover, txPour correctly records the intended pub algorithm also receives an arbitrary string info, which is bound and transaction string info. This property is formalized via an INCOMP into the output pour transaction txPour. incompleteness experiment . new new The Pour algorithm outputs two new coins c1 , c2 Definition III.1. A DAP scheme Π=(Setup, CreateAddress, and a pour transaction txPour. The transaction txPour equals Mint, Pour, VerifyTransaction, Receive) is complete if no , old, old, new, new,v , , ∗ new, (rt sn1 sn2 cm1 cm2 pub info ), where cm1 polynomial-size ledger sampler S wins INCOMP with more new cm2 are the two coin commitments of the two output coins, than negligible probability. and ∗ denotes other (implementation-dependent) information. D. Security Crucially, txPour reveals only one currency value, the public value vpub (which may be zero); it does not reveal the payment Security of a DAP scheme is characterized by three prop- addresses or values of the old or new coins. erties, which we call ledger indistinguishability, transaction non-malleability, and balance. Verifying transactions. The algorithm VerifyTransaction checks the validity of a transaction: Definition III.2. A DAP scheme Π=(Setup, CreateAddress, Mint, Pour, VerifyTransaction, Receive) is secure if it satisfies VerifyTransaction ledger indistinguishability, transaction non-malleability, and • INPUTS: balance. – public parameters pp Below, we provide an informal overview of each property, – a (mint or pour) transaction tx and defer formal definitions to the extended version of this – the current ledger L paper [26]. • OUTPUTS: bit b, equals 1 iff the transaction is valid

Both mint and pour transactions must be verified before being Each property is formalized as a game between an adversary A C considered well-formed. In practice, transactions can be verified and a challenger . In each game, the behavior of honest ODAP by the nodes in the distributed system maintaining the ledger, parties is realized via a DAP scheme oracle , which L as well as by users who rely on these transactions. maintains a ledger and provides an interface for executing CreateAddress, Mint, Pour and Receive algorithms for honest Receiving coins. The algorithm Receive scans the ledger and parties. To elicit behavior from honest parties, A passes a query retrieves unspent coins paid to a particular user address: to C, which (after sanity checks) proxies the query to ODAP. For each query that requests an honest party to perform an Receive action, A specifies identities of previous transactions and the • INPUTS: input values, and learns the resulting transaction, but not any of , – recipient address key pair (addrpk addrsk) the secrets or trapdoors involved in producing that transaction. L – the current ledger The oracle ODAP also provides an Insert query that allows A • OUTPUTS: set of (unspent) received coins to directly add aribtrary transactions to the ledger L. Ledger indistinguishability. This property captures the produce valid pour transactions that are unrelated to those in T ; requirement that the ledger reveals no new information to the condition that tx∗ reveals a serial number of a previously- the adversary beyond the publicly-revealed information (values spent coin captures non-malleability.) of minted coins, public values, information strings, total number Balance. This property requires that no bounded adversary of transactions, etc.), even when the adversary can adaptively A can own more money than what he minted or received via induce honest parties to perform DAP operations of his choice. payments from others. A That is, no bounded adversary can distinguish between two Balance is formalized by an experiment BAL, in which A L L A ledgers 0 and 1, constructed by using queries to two adaptively interacts with a DAP scheme oracle ODAP and then DAP scheme oracles, when the queries to the two oracles are outputs a set of coins Scoin. Letting Saddr be set of addresses publicly consistent: they have matching type and are identical returned by CreateAddress queries (i.e., addresses of “honest” in terms of publicly-revealed information and the information users), A wins the game if the total value he can spend or A related to addresses controlled by . has spent (either as coins or Basecoin public outputs) is Ledger indistinguishability is formalized by an experiment greater than the value he has received or mined. That is, A L-IND that proceeds as follows. First, a challenger samples a wins if v + v + vA→ >v + v →A b ODAP Unspent Basecoin ADDR Mint ADDR random bit and initializes two DAP scheme oracles 0 where: (i) v is the total value of unspent coins in S ; ODAP L L Unspent coin and 1 , maintaining ledgers 0 and 1. Throughout, the (ii) v is the total value of public outputs placed by A on DAP DAP Basecoin challenger allows A to issue queries to O0 and O1 , thus the ledger; (iii) vMint is the total value of A’s mint transactions; controlling the behavior of honest parties on L0 and L1. The (iv) vADDR→A is the total value of payments received by A challenger provides the adversary with the view of both ledgers, from addresses in Saddr; (v) vA→ADDR is the total value of but in randomized order: LLeft := Lb and LRight := L1−b. The payments sent by A to addresses in Saddr. adversary’s goal is to distinguish whether the view he sees Balance requires that A wins BAL with only negligible L ,L L ,L b corresponds to ( Left Right)=( 0 1), i.e. =0,orto probability. (LLeft,LRight)=(L1,L0), i.e. b =1. At each round of the experiment, the adversary issues queries IV. CONSTRUCTION OF A DECENTRALIZED ANONYMOUS in pairs Q, Q of matching query type. If the query type is PAYMENT SCHEME CreateAddress, then the same address is generated at both We show how to construct a DAP scheme (introduced oracles. If it is to Mint, Pour or Receive, then Q is forwarded in Section III) using zk-SNARKs and other building blocks. to L0 and Q to L1; for Insert queries, query Q is forwarded Later, in Section V, we give a concrete instantiation of this L Q L to Left and is forwarded to Right. The adversary’s queries construction. are restricted in the sense that they must maintain the public consistency of the two ledgers. For example, the public values A. Cryptographic building blocks for Pour queries must be the same, as well as minted amounts We first introduce notation for the standard cryptographic for Mint queries. building blocks that we use. We assume familiarity with the At the conclusion of the experiment, A outputs a guess b , definitions of these building blocks; for more details, see, e.g., and wins when b = b . Ledger indistinguishability requires that [27]. Throughout, λ denotes the security parameter. A L-IND wins with probability at most negligibly greater than Collision-resistant hashing. We use a collision-resistant hash / 1 2. function CRH: {0, 1}∗ →{0, 1}O(λ). Transaction non-malleability. This property requires that Pseudorandom functions. We use a pseudorandom function no bounded adversary A can alter any of the data stored ∗ O(λ) family PRF = {PRFx : {0, 1} →{0, 1} }x where x de- within a (valid) pour transaction txPour. This transaction non- notes the seed. From PRFx, we derive three “non-overlapping” malleability prevents malicious attackers from modifying others’ addr pseudorandom functions, chosen arbitrarily as PRFx (z):= transactions before they are added to the ledger (e.g., by re- sn pk PRFx(00z) , PRFx (z):=PRFx(01z) , PRFx (z):= targeting the Basecoin public output of a pour transaction). sn PRFx(10z). Furthermore, we assume that PRF is also Transaction non-malleability is formalized by an experiment collision resistant, in the sense that it is infeasible to find TR-NM, in which A adaptively interacts with a DAP scheme sn sn ∗ (x, z) =( x ,z ) such that PRF (z)=PRF  (z ). oracle ODAP and then outputs a pour transaction tx . Letting x x T denote the set of pour transactions returned by ODAP, and Statistically-hiding commitments. We use a commitment L denote the final ledger, A wins the game if there exists scheme COMM where the binding property holds computa- tx ∈T, such that (i) tx∗ = tx; (ii) tx∗ reveals a serial number tionally, while the hiding property holds statistically. It is ∗ { { , }∗ →{ , }O(λ)} x contained in tx; and (iii) both tx and tx are valid with respect denoted COMMx : 0 1 0 1 x where denotes to the ledger L containing all transactions preceding tx on L. the commitment trapdoor. Namely, to reveal a commitment cm ∗ z z x In other words, A wins the game if tx manages to modify to a value , it suffices to provide and the trapdoor ; then z some previous pour transaction to spend the same coin in a one can check that cm = COMMx( ). different way. One-time strongly-unforgeable digital signatures. We use a A TR-NM Transaction non-malleability requires that wins digital signature scheme Sig =(Gsig, Ksig, Ssig, Vsig) that works with only negligible probability. (Note that A can of course as follows. λ • G → λ • x , old, old, new, new, sig(1 ) ppsig. Given a security parameter (presented Instances are of the form =(rt sn1 sn2 cm1 cm2 G v ,h ,h ,h x in unary), sig samples public parameters ppenc for the pub Sig 1 2). Thus, an instance specifies a root rt for encryption scheme. a CRH-based Merkle tree (over the list of commitments so • K → , sig(ppsig) (pksig sksig). Given public parameters ppsig, far), the two serial numbers of the consumed coins, two coin Ksig samples a public key and a secret key for a single user. commitments for the two new coins, a public value, and • Ssig(sksig,m) → σ. Given a secret key sksig and a message fields hSig,h1,h2 used for non-malleability. old old m, Ssig signs m to obtain a signature σ. • Witnesses are of the form a =(path1, path2, c1 , c2 , • V ,m,σ → b m old , old , cnew, cnew i ∈{ , } sig(pksig ) . Given a public key pksig, message , addrsk,1 addrsk,2 1 2 ) where, for each 1 2 : and signature σ, V outputs b =1if the signature σ is valid sig cold old ,vold,ρold,rold,sold, old , for message m; else it outputs b =0. i =(addrpk,i i i i i cmi ) cnew new ,vnew,ρnew,rnew,snew, new The signature scheme Sig satisfies the security property of i =(addrpk,i i i i i cmi ) new one-time strong unforgeability against chosen-message attacks for the same cmi as in x, SUF-1CMA ( security). old old old addr ,i =(a ,i, pk ,i) , Key-private public-key encryption. We use a public-key pk pk enc new anew , new , addrpk,i =( pk,i pkenc,i) encryption scheme Enc =(Genc, Kenc, Eenc, Denc) that works old aold , old . as follows. addrsk,i =( sk,i skenc,i) λ • G (1 ) → pp . Given a security parameter λ (presented enc enc Thus, a witness a specifies authentication paths for the two in unary), G samples public parameters pp for the enc enc new coin commitments, the entirety of coin information encryption scheme. about both the old and new coins, and address secret keys • K (pp ) → (pk , sk ). Given public parameters pp , enc enc enc enc enc for the old coins. Kenc samples a public key and a secret key for a single user. Given a POUR instance x, a witness a is valid for x if the • Eenc(pk ,m) → c. Given a public key pk and a message enc enc following holds: m, Eenc encrypts m to obtain a ciphertext c. 1) For each i ∈{ , }: • Denc(skenc,c) → m. Given a secret key skenc and a ciphertext 1 2 a) The coin commitment old of cold appears on the c, Denc decrypts c to produce a message m (or ⊥ if cmi i decryption fails). ledger, i.e., pathi is a valid authentication path for old The encryption scheme Enc satisfies two security properties: leaf cmi with respect to root rt,inaCRH-based (i) ciphertext indistinguishability under chosen-ciphertext attack Merkle tree. aold (IND-CCA security); and (ii) key indistinguishability under b) The address secret key sk,i matches the address public cold aold addr chosen-ciphertext attack (IK-CCA security). While the first key of i , i.e., ,i = PRFaold (0). pk sk,i old old property is standard, the second is less known; informally, c) The serial number sni of ci is computed correctly, IK-CCA old sn old requires that ciphertexts cannot be linked to the public i.e., sni = PRFaold (ρi ). sk,i key used to encrypt them, or to other ciphertexts encrypted old old d) The coin ci is well-formed, i.e., cmi = with the same public key. For definitions, we refer the reader old old old old old a ρ v COMMsi (COMMri ( pk,i i ) i ). to [21]. new new e) The coin ci is well-formed, i.e., cmi = new new new snew rnew a ρ v B. zk-SNARKs for pouring coins COMM i (COMM i ( pk,i i ) i ). aold h h h As outlined in Section I-B, our construction invokes a f) The address secret key sk,i ties Sig to i, i.e., i = pk h zk-SNARK for a specific NP statement, POUR, which we now PRFaold ( Sig). sk,i define. We first recall the context motivating POUR. When a new new old old 2) Balance is preserved: v1 +v2 +vpub = v1 +v2 (with old old new new user u pours “old” coins c1 , c2 into new coins c1 , c2 , old old old old v1 ,v2 ≥ 0 and v1 + v2 ≤ vmax). a corresponding pour transaction Recall that in this paper zk-SNARKs are relative to the old old new new txPour =(rt, sn1 , sn2 , cm1 , cm2 ,vpub, info, ∗) language of arithmetic circuit satisfiability (see Section II); thus, we express the checks in POUR via an arithmetic circuit, is generated. In our construction, we need to provide evidence in denoted C . In particular, the depth d of the Merkle “∗” that various conditions were respected by the pour operation. POUR tree tree needs to be hardcoded in C , and we thus make it Concretely, should demonstrate that (i) u owns cold, cold; POUR txPour 1 2 a parameter of our construction (see below); the maximum cold, cold (ii) coin commitments for 1 2 appear somewhere on the dtree old old number of supported coins is then 2 . ledger; (iii) the revealed serial numbers sn1 , sn2 are of old old new new c1 , c2 ; (iv) the revealed coin commitments cm1 , cm2 C. Algorithm constructions cnew, cnew are of 1 2 ; (v) balance is preserved. Our construction We proceed to describe the construction of the DAP scheme π achieves this by including a zk-SNARK proof POUR for the Π=(Setup, CreateAddress, Mint, Pour, VerifyTransaction, statement POUR which checks the above invariants (as well as Receive) whose intuition was given in Section I-B. Figure 2 others needed for non-malleability). gives the pseudocode for each one of the six algorithms in Π, The statement POUR. Concretely, the NP statement POUR in terms of the building blocks introduced in Section IV-A and is defined as follows. Section IV-B. In the construction, we hardcode two quantities: Setup Pour • INPUTS: security parameter λ • INPUTS: • OUTPUTS: public parameters pp – public parameters pp 1) Construct CPOUR for POUR at security λ. – the Merkle root rt ( , ):= (1λ,C ) old old 2) Compute pk vkPOUR KeyGen POUR . – old coins c1 , c2 POUR λ 3) Compute pp := Genc(1 ). old , old enc λ – old addresses secret keys addrsk,1 addrsk,2 4) Compute pp := G (1 ). old sig sig – path path1 from commitment cm(c1 ) to root rt, 5) Set pp := (pk , vkPOUR, pp , pp ). old POUR enc sig path path2 from commitment cm(c2 ) to root rt 6) Output pp. new new – new values v1 ,v2 – new addresses public keys addrnew , addrnew CreateAddress pk,1 pk,2 – public value vpub • INPUTS: public parameters pp ( , ) – transaction string info • OUTPUTS: address key pair addrpk addrsk cnew, cnew ( , ):=K ( ) • OUTPUTS: new coins 1 2 and pour transaction txPour 1) Compute pkenc skenc enc ppenc . i ∈{1, 2} addr a 1) For each : 2) Randomly sample a PRF seed sk. cold ( old ,vold,ρold,rold,sold, old) addr a) Parse i as addrpk,i i i i i cmi . 3) Compute a = PRFa (0). pk sk old (aold , old ) := (a , ) b) Parse addrsk,i as sk,i skenc,i . 4) Set addrpk pk pkenc . sn c) Compute snold := PRF (ρold). 5) Set addrsk := (ask, skenc). i aold i sk,i 6) Output (addrpk, addrsk). new (anew , new ) d) Parse addrpk,i as pk,i pkenc,i . sn new e) Randomly sample a PRF seed ρi . Mint new new f) Randomly sample two COMM trapdoors ri ,si . • INPUTS : knew := rnew (anew ρnew) g) Compute i COMM i pk,i i . – public parameters pp new new new h) Compute cm := COMMsnew (v k ). v ∈{0, 1,...,v } i i i i – coin value max cnew := ( new ,vnew,ρnew,rnew,snew, new) i) Set i addrpk,i i i i i cmi . – destination address public key addrpk new new new new new j) Set Ci := Eenc(pk ,i, (vi ,ρi ,ri ,si )). • OUTPUTS: coin c and mint transaction txMint enc 2) Generate ( , ):=K ( ). 1) Parse addrpk as (apk, pk ). pksig sksig sig ppsig encsn h := ( ) 2) Randomly sample a PRF seed ρ. 3) Compute Sig CRH pksig . pk pk r, s h1 := (h ) h2 := (h ) 3) Randomly sample two COMM trapdoors . 4) Compute PRFaold Sig and PRFaold Sig . 4) Compute k := COMMr(a ρ). sk,1 sk,2 pk x := ( , old, old, new, new,v ,h ,h ,h ) 5) Compute cm := COMMs(vk). 5) Set rt sn1 sn2 cm1 cm2 pub Sig 1 2 . a := ( , , cold, cold, old , old , cnew, cnew) 6) Set c := (addr ,v,ρ,r,s,cm). 6) Set path1 path2 1 2 addrsk,1 addrsk,2 1 2 . pk π := ( ,x,a) 7) Set txMint := (cm,v,∗), where ∗ := (k, s). 7) Compute POUR Prove pkPOUR . m := (x, π , , C1, C2) 8) Output c and txMint. 8) Set POUR info . 9) Compute σ := Ssig(sksig,m). old old new new VerifyTransaction 10) Set txPour := (rt, sn1 , sn2 , cm1 , cm2 ,vpub, info, ∗), where ∗ := ( ,h ,h ,π , C , C ,σ) • INPUTS: pksig 1 2 POUR 1 2 . new new – public parameters pp 11) Output c1 , c2 and txPour. – a (mint or pour) transaction tx – the current ledger L Receive • OUTPUTS: bit b, equals 1 iff the transaction is valid • INPUTS: 1) If given a mint transaction tx = txMint: – public parameters pp ( ,v,∗) ∗ (k, s) a) Parse txMint as cm , and as . – recipient address key pair (addrpk, addrsk) b) Set cm := COMMs(vk). – the current ledger L c) Output b := 1 if cm = cm , else output b := 0. • OUTPUTS: set of received coins (a , ) 2) If given a pour transaction tx = txPour: 1) Parse addrpk as pk pkenc . old old new new (a , ) a) Parse txPour as (rt, sn1 , sn2 , cm1 , cm2 ,vpub, info, ∗), and ∗ as 2) Parse addrsk as sk skenc . ( ,h ,h ,π , C , C ,σ) pksig 1 2 POUR 1 2 . 3) For each Pour transaction txPour on the ledger: ( , old, old, new, new,v , , ∗) b) If snold or snold appears on L (or snold = snold), output b := 0. a) Parse txPour as rt sn1 sn2 cm1 cm2 pub info , 1 2 1 2 ∗ ( ,h ,h ,π , C , C ,σ) c) If the Merkle root rt does not appear on L, output b := 0. and as pksig 1 2 POUR 1 2 . h := ( ) b) For each i ∈{1, 2}: d) Compute Sig CRH pksig . old old new new (v ,ρ ,r ,s ):=D ( , C ) e) Set x := (rt, sn1 , sn2 , cm1 , cm2 ,vpub,hSig,h1,h2). i) Compute i i i i enc skenc i . D ⊥ f) Set m := (x, πPOUR, info, C1, C2) ii) If enc’s output is not , verify that: b := V ( ,m,σ) • new (v  (a ρ )) g) Compute sig pksig . cmi equals COMMsi i COMMri pk i ; sn h) Compute b := Verify(vkPOUR,x, πPOUR), and output b ∧ b . • sni := PRFa (ρi) does not appear on L. sk iii) If both checks succeed, output new ci := (addrpk,vi,ρi,ri,si, cmi ).

Fig. 2: Construction of a DAP scheme using zk-SNARKs and other ingredients.

the maximum value of a coin, vmax, and the depth of the is a complete (cf. Definition III.1) and secure (cf. Defini- Merkle tree, dtree. tion III.2) DAP scheme.

D. Completeness and security We provide a proof of Theorem IV.1 in the extended version of Our main theorem states that the above construction is indeed this paper [26]. We note that our construction can be modified to a DAP scheme. yield statistical (i.e., everlasting) anonymity; see the discussion in the extension section of the full version of this paper. Theorem IV.1. The tuple Π=(Setup, CreateAddress, Mint, Pour, VerifyTransaction, Receive), as defined in Section IV-C, Remark (trusted setup). Security of Π relies on a trusted party running Setup to generate the public parameters (once and for above we are ignoring the commitment randomness s. The all). This trust is needed for the transaction non-malleability reason is that we already know that k, being the output of a and balance properties but not for ledger indistinguishability. statistically-hiding commitment, can serve as randomness for Thus, even if a powerful espionage agency were to corrupt the next commitment scheme. the setup, anonymity will still be maintained. Moreover, if Instantiating the NP statement POUR. The above choices one wishes to mitigate the trust requirements of this step, one imply a concrete instantiation of the NP statement POUR can conduct the computation of Setup using secure multiparty (see Section IV-B). Specifically, in our implementation, POUR computation techniques; we leave this to future work. checks that the following holds, for each i ∈{1, 2}: old • pathi is an authentication path for leaf cm with respect V. Z EROCASH i to root rt,inaCRH-based Merkle tree; 256 We describe a concrete instantiation of a DAP scheme; this • aold H aold  pk,i = ( sk,i 0 ); instantiation forms the basis of Zerocash. Later, in Section VI, • old H aold   ρold sni = ( sk,i 01 [ i ]254); 192 we discuss how Zerocash can be integrated with existing ledger- • old H H rold H aold ρold  vold cmi = ( ( i [ ( pk,i i )]128) 0 i ); 192 based currencies. • new H H rnew H anew ρnew  vnew cmi = ( ( i [ ( pk,i i )]128) 0 i ); and • h H aold   h A. Instantiation of building blocks i = ( sk,i 10 [ Sig]254). Moreover, POUR checks that vnew + vnew + v = vold + vold, We instantiate the DAP scheme construction from Section IV 1 2 pub 1 2 with vold,vold ≥ 0 and vold + vold < 264. (see Figure 2), aiming at a level of security of 128 bits. Doing 1 2 1 2 Finally, as mentioned, in order for C to be well-defined, so requires concrete choices, described next. POUR we need to fix a Merkle tree depth dtree. In our implementation, CRH, PRF, COMM from SHA256. Let H be the SHA256 64 we fix dtree =64, and thus support up to 2 coins. compression function, which maps a 512-bit input to a 256- Instantiating Sig. For the signature scheme Sig,weuse bit output. We mostly rely on H, rather than the “full” ECDSA to retain consistency and compatibility with the hash, since this suffices for our fixed-size single-block inputs, existing bitcoind source code. However, standard ECDSA is and it simplifies the construction of C . We instantiate POUR malleable: both (r, s) and (r, −s) verify as valid signatures. We CRH, PRF, COMM via H (under suitable assumptions on H). use a non-malleable variant, where s is restricted to the “lower First, we instantiate the collision-resistant hash function CRH 512 half” of field elements. While we are not aware of a formal as H(z) for z ∈{0, 1} ; this function compresses “two-to- SUF-CMA proof for this variant, its use is consistent with one”, so it can be used to construct binary Merkle trees.13 proposals to resolve Bitcoin transaction malleability [29].15 Next, we instantiate the pseudorandom function PRFx(z) as H(xz), with x ∈{0, 1}256 as the seed, and z ∈{0, 1}256 as Instantiating Enc. For the encryption scheme Enc, we use 14 addr the input. Thus, the derived functions are PRFx (z):= the key-private Elliptic-Curve Integrated Encryption Scheme sn pk H(x00z), PRFx (z):=H(x01z) and PRFx (z):= (ECIES) [30, 31]; it is one of the few standardized key-private H(x10z), with x ∈{0, 1}256 and z ∈{0, 1}254. encryption schemes with available implementations. As for the commitment scheme COMM, we only use it in For further details about efficiently realizing these in the the following pattern: arithmetic circuit for POUR, see the full version of this paper. VI. INTEGRATION WITH EXISTING LEDGER-BASED k := COMMr(apkρ) CURRENCIES cm := COMMs(vk) Zerocash can be deployed atop any ledger (even one main- Due to our instantiation of PRF, apk is 256 bits. So we can tained by a central bank.) Here, we briefly detail integration set ρ also to 256 bits and r to 256 + 128 = 384 bits; then we with the Bitcoin protocol. Unless explicitly stated otherwise, can compute k := COMMr(apkρ) as H(r[H(apkρ)]128). in the following section when referring to Bitcoin, and its unit Above, [·]128 denotes that we are truncating the 256-bit string of account bitcoin (plural bitcoins), we mean the underlying to 128 bits (say, by dropping least-significant bits, as in our protocol and software, not the currency system. ( The discussion 128 implementation). Heuristically, for any string x ∈{0, 1} , holds, with little or no modification, for many forks of Bitcoin, −128 the distribution induced by H(rx) is 2 -close to uniform, a.k.a. “altcoins”, such as Litecoin.) and this forms the basis of the statistically-hiding property. For By introducing new transaction types and payment semantics, computing cm, we set coin values to be 64-bit integers (so that, Zerocash breaks compatibility with the Bitcoin network. While 64 in particular, vmax =2 − 1 in our implementation), and then Zerocash could be integrated into Bitcoin (the actual currency 192 compute cm := COMMs(vk) as H(k0 v). Noticeably, and its supporting software) via a “flag day” where a super- majority of Bitcoin miners simultaneously adopt the new 13 h A single exception: we still compute Sig according to the full hash software, we neither expect nor advise such integration in the SHA256, rather than its compression function, because there is no need for this computation to be verified by CPOUR. near future and suggest using Zerocash in a separate altcoin. 14This assumption is reminiscent of previous works analyzing the security of hash-based constructions (e.g., [28]). However in this work we assume 15In practice, one might replace this ECDSA variant with an EC-Schnorr that a portion of the compression function is the seed for the pseudorandom signature satisfying SUF-CMA security with proper encoding of EC group function, rather than using the chaining variable as in [28]. elements; the performance would be similar. Integrating Zerocash into Bitcoin consists of adding a new fabricate an additional block solely for a targeted user. Spending transaction type, Zerocash transactions, and modifying the any coins with respect to the updated Merkle tree in this protocol and software to invoke Zerocash’s DAP interface to “poison-pill” block will uniquely identify the targeted user. To create and verify these transactions. Two approaches to doing mitigate such attacks, users should check with trusted peers so are described next, followed by a discussion of anonymizing their view of the block chain and, for sensitive transactions, the network layer. only spend coins relative to blocks further back in the ledger (since creating the illusion for multiple blocks is far harder). A. Integration by replacing the base currency One approach is to alter the underlying system so that VII. EXPERIMENTS all monetary transactions are done using Zerocash, i.e., by To measure the performance of Zerocash, we ran several invoking the DAP interface and writing/reading the associated experiments. First, we benchmarked the performance of the transactions in the distributed ledger. zk-SNARK for the NP statement POUR (Section VII-A) and As seen in Section III, this suffices to offer the core of the six DAP scheme algorithms (Section VII-B). Second, functionality of payments, minting, merging, splitting, etc., we studied the impact of a higher block verification time via a while assuring users that all transactions using this currency simulation of a Bitcoin network (Section VII-C). are anonymous. However, this has several drawbacks: all transactions incur the cost of generating a zk-SNARK proof; A. Performance of zk-SNARKs for pouring coins the scripting feature of Bitcoin is lost; and Bitcoin’s ability to Our zk-SNARK for the NP statement POUR is obtained by spend unconfirmed transactions is lost. constructing an arithmetic circuit CPOUR for verifying POUR, and then invoking the generic implementation of zk-SNARK B. Integration by hybrid currency for arithmetic circuit satisfiability of [16] (see Section II-C). A different approach is to extend Bitcoin with a parallel, The arithmetic circuit CPOUR is built from scratch and hand- anonymized currency of “zerocoins,” existing alongside bit- optimized to exploit nondeterministic verification and the large coins, using the same ledger, and with the ability to convert field characteristic. freely between the two. The behavior and functionality of Figure 3 reports performance characteristics of the resulting regular bitcoins is unaltered; in particular, they may support zk-SNARK for POUR. This includes three settings: single- functionality such as scripting. thread performance on a laptop machine; and single-thread In this approach, the Bitcoin ledger consists of Bitcoin-style and multi-thread performance on a desktop machine. (The transactions, containing inputs and outputs [20]. Each input is time measurements are the average of 10 runs, with standard either a pointer to an output of a previous transaction (as in plain deviation under 2.5%.) Bitcoin), or a Zerocash pour transaction (which contributes its B. Performance of Zerocash algorithms public value, vpub, of bitcoins to this transaction). Outputs are either an amount and destination public address/script In Figure 4 we report performance characteristics for each (as in plain Bitcoin), or a Zerocash mint transaction (which of the six DAP scheme algorithms in our implementation. Note consumes the input bitcoins to produce zerocoins). The usual that these numbers do not include the costs of maintaining the invariant over bitcoins is maintained and checked in plain Merkle tree because doing so is not the responsibility of these view: the sum of bitcoin inputs (including pours’ vpub) must algorithms. Moreover, for VerifyTransaction, we separately be at least the sum of bitcoin outputs (including mints’ v), report the cost of verifying mint and pour transactions and, in and any difference is offered as a transaction fee. However, the latter case, we exclude the cost of scanning L (as this cost the accounting for zerocoins consumed and produced is done depends on L). Finally, for the case of Receive, we report the separately and implicitly by the DAP scheme. cost to process a given pour transaction in L.

C. Additional anonymity considerations C. Large-scale network simulation Zerocash only anonymizes the transaction ledger. Network Because Bitcoin mining typically takes place on dedicated traffic used to announce transactions, retrieve blocks, and GPUs or ASICs, the CPU resources to execute the DAP scheme contact merchants will still leak identifying information (e.g., algorithms are often of minimal consequence to network IP addresses). Thus users need some anonymity network to performance. There is one potential exception to this rule: the safely use Zerocash. The most obvious way to do this is via VerifyTransaction algorithm must be run by all of the network Tor [32]. Given that Zerocash transactions are not low latency nodes in the course of routine transaction validation. The time themselves, Mixnets (e.g., Mixminion [33]) are also a viable it takes to perform this verification can have significant impact way to add anonymity (and one that is not as vulnerable to on network performance. traffic analysis as Tor). Using mixnets that provide email-like In the Zerocash implementation (as in Bitcoin), every Zero- functionality has the added benefit of providing an out-of-band cash transaction is verified at each hop as it is forwarded though notification mechanism as a replacement to Receive. the network and, potentially, again when blocks containing the Additionally, although in theory all users have a single transaction are verified. Verifying a block consists of checking view of the block chain, a powerful attacker could potentially the proof of work and validating the contained transactions. Intel Intel Intel Core i7-4770 @ 3.40GHz with 16GB of RAM (1 thread) Core i7-2620M Core i7-4770 Setup Time 5 min 17 s @ 2.70GHz @ 3.40GHz pp 896 MiB 12GB of RAM 16GB of RAM CreateAddress Time 326.0 ms 1 thread 1 thread 8 threads addrpk 343 B KeyGen Time 7 min 48 s 5 min 17 s 4 min 11 s addr 319 B 896 sk Proving key MiB Time 23 μs 749 Mint Verification key B Coin c 463 B 2 55 2 2 1 3 Prove Time min s min s min s tx 72 B 288 Mint Proof B Pour Time 2 min 2.01 s Verify Time 8.5 ms 5.4 ms 16 txPour 855 B VerifyTransaction mint 8.3 μs Fig. 3: Performance of our zk-SNARK for the NP statement POUR. pour (excludes L scan) 5.7 ms (N =10, σ ≤ 2.5%) Receive Time (per pour tx) 1.6 ms

Fig. 4: Performance of Zerocash algorithms. Thus Zerocash transactions may take longer to spread though (N =10, σ ≤ 2.5%17) the network and blocks containing Zerocash transactions may take longer to verify. While we are concerned with the first nodes on one virtualized server. issue, the potential impact of the second issue is cause for greater concern. This is because Zerocash transactions cannot The frequency of new blocks can be modeled as a Poisson be spent until they make it onto the ledger. process with a mean of Λblock seconds. To generate blocks Because blocks are also verified at each hop before they are stochastically, we modify bitcoind to fix its block difficulty forwarded through the network, delays in block verification at a trivial level and run a Poisson process, on the simulation slow down the propagation of new blocks through the network. control server, which trivially mines a block on a randomly This causes nodes to waste CPU-cycles mining on out-of-date selected node. This preserves the distribution of blocks, without blocks, reducing the computational power of the network and the computational overhead of a real proof of work. Another making it easier to mount a “51% attack” (dishonest majority Poisson process triggering mechanism, with a different mean of miners) on the distributed ledger. Λtx, introduces new transactions at random network nodes. It is a priori unclear whether this potential issue is a To differentiate which transactions represent normal Bitcoin real concern. Bitcoin caches transaction verifications, so a expenditures vs. which contain Zerocash pour transactions, transaction that was already verified when it propagated through simulated Zerocash transactions pay a unique amount of the network need not be verified again when it is seen in a bitcoins (we set this value arbitrarily at 7 BTC). If a trans- block. The unknown is what percentage of transactions in a action’s output matches this preset value, and it is not in verification cache, then our modified Bitcoin client inserts block are actually in any given node’s cache. We thus conduct 18 a simulation of the Bitcoin network to investigate both the a 10 ms delay simulating the runtime of VerifyTransaction. time it takes Zerocash transactions to make it onto the ledger Otherwise transactions are processed as specified by the Bitcoin and establish the effects of Zerocash transactions on block protocol. We vary the amount of simulated Zerocash traffic by verification and propagation. We find that Zerocash transactions varying the number of transactions with this particular output can be spent reasonably quickly and that the effects of increased amount. This minimizes code changes and estimates only the block validation time are minimal. generic impact of verification delays and not of any specific implementation choice. Simulation design. Because Zerocash requires breaking changes to the Bitcoin protocol, we cannot test our protocol in Methodology. Recent research [17] suggests that the Bitcoin the live Bitcoin network or even in the dedicated testnet. We network contains 16,000 distinct nodes though most are likely must run our own private testnet. For efficiency and cost reasons, no longer participating: approximately 3,500 are reachable we would like to run as many Bitcoin nodes as possible on the at any given time. Each node has an average of 32 open least amount of hardware. This raises two issues. First, reducing connections to randomly selected peers. As of November 2013, the proof of work to practical levels while still preserving a the peak observed transaction rate for Bitcoin is slightly under realistic rate of new blocks is difficult (especially on virtualized one transaction per second [34]. hardware with variable performance). Second, the overhead of In our simulation, we use a 1000-node network in which zk-SNARK verification prevents us from running many Bitcoin each node has an average of 32 peers, transactions are generated with a mean of Λtx =1s, a duration of 1 hour, and a variable 16346 B of this are due to the ciphertexts C1, C2. Future implementations percentage  of Zerocash traffic. To allow for faster experiments, may significantly reduce this overhead or discard these (cf. Section VI-C). instead of generating a block every 10 minutes as in Bitcoin, 17We note that σ for both Mint and VerifyTransaction (mint) is higher than 2.5% due to the variability at such short timescales. Respectively, it is we create blocks at an average of every Λblock = 150 s (as in 3.3 μs and 1.9 μs. Litecoin, a popular altcoin).

18Subsequent optimizations lowered the cost of VerifyTransaction below this, after our experiments. 200 4.5 80

180 4 70

160 3.5 60 140 3 50 120 2.5 100 40 2 80 30

time in seconds time in seconds 1.5

60 time in milliseconds 20 40 1 10 20 0.5 last node Zerocash every node Zerocash 0 0 0 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%    (a) Transaction latency (b) Block propagation time (c) Block verification time

Fig. 5: The average values of the three metrics we study, as a function of , the percentage of transactions that are Zerocash transactions. Note that, in (a), latency is undefined when  =0and hence omitted.

We run our simulation for different traffic mixes, where spendable, is roughly 190 s. For slower block generation rates  indicates the percentage of Zerocash transactions and  ∈ (e.g., Bitcoin’s block every 10 minutes) this should mean users {0%, 25%, 50%, 75%, 100%}. Each simulation is run on 200 must wait only one block before spending received transactions. Amazon EC2 general-purpose m1.medium instances, in one VIII. OPTIMIZATIONS AND EXTENSIONS region on a 10.10./16 private network. On each instance, we deploy 5 instances of bitcoind. See the extended version of this paper [26] for extensions on everlasting anonymity, batched Merkle tree updates, faster Results. Transactions are triggered by a blocking function call 64 block propagation, and scaling to 2 serial numbers. on the simulation control node that must connect to a random node and wait for it to complete sending a transaction. Because IX. CONCURRENT WORK the Poisson process modeling transactions generates delays Danezis et al. [19] suggest using zk-SNARKs to reduce between such calls and not between the exact points when the proof size and verification time in Zerocoin. Our work differs node actuals sends the transactions, the actual transaction rate from [19] in both supported functionality and scalability. is skewed. In our experiments the real transaction rate shifts First, [19]’s protocol, like Zerocoin, only supports fixed-value away from our target of one per second to an average of one coins, and is best viewed as a decentralized mix. Instead, we every 1.4 seconds. define, construct, and implement a full-fledged decentralized  ∈{ , , , In Figure 5 we plot three metrics for 0% 25% 50% electronic currency, which provides anonymous payments of , } 75% 100% . Each is the average defined over the data from any amount.  the entire run of the simulation for a given (i.e., they include Second, in [19], the complexity of the zk-SNARK generator, 19 multiple transactions and blocks). Transaction latency is the prover, and verifier all scale superlinearly in the number of interval between a transaction’s creation and its inclusion in coins, because their arithmetic circuit computes, explicitly, a block. Block propagation time comes in two flavors: 1) the a product over all coins. In particular, the number of coins average time for a new block to reach a node computed over “mixed together” for anonymity cannot be large. Instead, in our the times for all nodes, and 2) the same average computed construction, the respective complexities are polylogarithmic, over only the last node to see the block. polylogarithmic, and constant in the number of coins; our Block verification time is the average time, over all nodes, approach supports a practically-unbounded number of coins. required to verify a block. If verification caching was not effective, we would expect to see a marked increase in both X. CONCLUSION block verification time and propagation time. Since blocks Decentralized currencies should ensure a user’s privacy from occur on average every 150 s, and we expect approximately his peers when conducting legitimate financial transactions. one transaction each second, we should see 150 × 10 ms = Zerocash provides such privacy protection, by hiding user 1500 ms of delay if all transactions were non-cached Zerocash identities, transaction amounts, and account balances from transactions. Instead, we see worst case 80 ms and conclude public view. This, however, may be criticized for hampering caching is effective. This results in a negligible effect on block accountability, regulation, and oversight. Yet, Zerocash need propagation (likely because network operations dominate). not be limited to enforcing the basic monetary invariants of The time needed for a transaction to be confirmed, and hence a currency system. The underlying zk-SNARK cryptographic proof machinery is flexible enough to support a wide range of 19Because our simulated Bitcoin nodes ran on shared EC2 instances, they policies. It can, for example, let a user prove that he paid his due were subject to variable external load, limiting the benchmark precision. Still, it clearly demonstrates that the mild additional delay does not cause catastrophic taxes on all transactions without revealing those transactions, network effects. their amounts, or even the amount of taxes paid. As long as the policy can be specified by efficient nondeterministic [10] H. Lipmaa, “Progression-free sets and sublinear pairing-based non- computation using NP statements, it can (in principle) be interactive zero-knowledge arguments,” in TCC ’12. [11] N. Bitansky, A. Chiesa, Y. Ishai, R. Ostrovsky, and O. Paneth, “Succinct enforced using zk-SNARKs, and added to Zerocash. This non-interactive arguments via linear interactive proofs,” in TCC ’13. can enable privacy-preserving verification and enforcement [12] R. Gennaro, C. Gentry, B. Parno, and M. Raykova, “Quadratic span of a wide range of compliance and regulatory policies that programs and succinct NIZKs without PCPs,” in EUROCRYPT ’13. [13] B. Parno, C. Gentry, J. Howell, and M. Raykova, “Pinocchio: nearly would otherwise be invasive to check directly or might be practical verifiable computation,” in Oakland ’13. bypassed by corrupt authorities. This raises research, policy, [14] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, and M. Virza, “SNARKs and engineering questions over what policies are desirable and for C: verifying program executions succinctly and in zero knowledge,” in CRYPTO ’13. practically realizable. [15] H. Lipmaa, “Succinct non-interactive zero knowledge arguments from Another research question is what new functionality can span programs and linear error-correcting codes,” in ASIACRYPT ’13. be realized by augmenting the capabilities already present in [16] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza, “Succinct non- interactive arguments for a von Neumann architecture,” ePrint 2013/879. Bitcoin’s scripting language with zk-SNARKs that allow fast [17] C. Decker and R. Wattenhofer, “Information propagation in the Bitcoin verification of expressive statements. network,” in P2P ’13. [18] E. Ben-Sasson, “Universal and affordable computational integrity,” May ACKNOWLEDGMENTS 2013, bitcoin 2013: The Future of Payments. [Online]. Available: http://www.youtube.com/watch?v=YRcPReUpkcU We thank Amazon for their assistance and kind donation of [19] G. Danezis, C. Fournet, M. Kohlweiss, and B. Parno, “Pinocchio EC2 resources, and Gregory Maxwell for his advice regarding Coin: building Zerocoin from a succinct pairing-based proof system,” in PETShop ’13. [Online]. Available: http://www0.cs.ucl.ac.uk/staff/G. the Bitcoin codebase. We thank Iddo Ben-Tov and the SCIPR Danezis/papers/DanezisFournetKohlweissParno13.pdf Lab members — Daniel Genkin, Lior Greenblat, Shaul Kfir, [20] S. Nakamoto, “Bitcoin: a peer-to-peer electronic cash system,” 2009. Gil Timnat and Michael Riabzev — for inspiring discussions. [Online]. Available: http://www.bitcoin.org/bitcoin.pdf [21] M. Bellare, A. Boldyreva, A. Desai, and D. Pointcheval, “Key-privacy This work was supported by: Amazon.com through an AWS in public-key encryption,” in ASIACRYPT ’01. in Education research grant; the Broadcom Foundation and [22] D. Boneh and X. Boyen, “Secure identity based encryption without random oracles,” in CRYPTO ’04. Tel Aviv University Authentication Initiative; the Center for [23] R. Gennaro, “Multi-trapdoor commitments and their applications to Science of Information (CSoI), an NSF Science and Technology proofs of knowledge secure under concurrent man-in-the-middle attacks,” Center, under grant agreement CCF-0939370; the Check in CRYPTO ’04. [24] C. Gentry and D. Wichs, “Separating succinct non-interactive arguments Point Institute for Information Security; the U.S. Defense from all falsifiable assumptions,” in STOC ’11. Advanced Research Projects Agency (DARPA) and the Air [25] N. Bitansky, R. Canetti, A. Chiesa, and E. Tromer, “From extractable Force Research Laboratory (AFRL) under contract FA8750- collision resistance to succinct non-interactive arguments of knowledge, and back again,” in ITCS ’12. 11-2-0211; the European Community’s Seventh Framework [26] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and Programme (FP7/2007-2013) under grant agreement number M. Virza, “Zerocash: Decentralized anonymous payments from Bitcoin 240258; the Israeli Centers of Research Excellence I-CORE (extended version),” Cryptology ePrint Archive, 2014. [27] J. Katz and Y. Lindell, Introduction to Modern Cryptography. Chapman program (center 4/11); the Israeli Ministry of Science and & Hall/CRC, 2007. Technology; the Office of Naval Research under contract [28] M. Bellare, “New proofs for NMAC and HMAC: security without N00014-11-1-0470; the Simons Foundation, with a Simons collision-resistance,” in CRYPTO ’06. [29] P. Wuille, “Proposed BIP for dealing with malleability,” Available at Award for Graduate Students in Theoretical Computer Science; https://gist.github.com/sipa/8907691, 2014. and the Skolkovo Foundation under grant agreement 6926059. [30] V. Shoup, “A proposal for an ISO standard for public key encryption (version 2.1),” IACR E-Print Archive, 2001. The views expressed are those of the authors and do not reflect [31] Certicom Research, “SEC 1: Elliptic curve cryptography,” 2000. [Online]. the official policy or position of the Department of Defense or Available: http://www.secg.org/collateral/sec1 final.pdf [32] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: the second- the U.S. Government. generation onion router,” in Security ’04. [33] G. Danezis, R. Dingledine, and N. Mathewson, “Mixminion: design of REFERENCES a type III anonymous remailer protocol,” in SP ’03. [34] T. B. Lee, “Bitcoin needs to scale by a factor of 1000 to compete [1] D. Chaum, “Blind signatures for untraceable payments,” in CRYPTO with Visa. here’s how to do it.” The Washington Post (http://www. ’82. washingtonpost.com), November 2013. [2] J. Camenisch, S. Hohenberger, and A. Lysyanskaya, “Compact e-cash,” in EUROCRYPT ’05. [3] T. Sander and A. Ta-Shma, “Auditable, anonymous electronic cash,” in CRYPTO ’99. [4] F. Reid and H. Martin, “An analysis of anonymity in the Bitcoin system,” in SocialCom/PASSAT ’11. [5] S. Barber, X. Boyen, E. Shi, and E. Uzun, “Bitter to better - how to make Bitcoin a better currency,” in FC ’12. [6] D. Ron and A. Shamir, “Quantitative analysis of the full Bitcoin transaction graph,” ePrint 2012/584, 2012. [7] G. Maxwell, “CoinJoin: Bitcoin privacy for the real world,” August 2013, bitcoin Forum. [Online]. Available: https://bitcointalk.org/index. php?topic=279249.0 [8] I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zerocoin: Anonymous distributed e-cash from bitcoin,” in SP ’13. [9] J. Groth, “Short pairing-based non-interactive zero-knowledge arguments,” in ASIACRYPT ’10.