Extending ZeroCoin: EZC and ZeroCash

In what follows, we present a number of proposals that address some of the limitations of ZeroCoin. In particular, we present EZC and ZeroCash, two independently designed systems, that support transactions where one or more anonymous coins can be spent in the form of fresh anonymous coins. In these proposals, the value of the coins spent is hidden from the rest of the network, and the coin recipient has complete control over the spent coins.

Throughout the rest of this chapter, we present Extended ZeroCoin that, as its name suggests, builds on top of ZeroCoin. We then move on to ZeroCash that constitutes a ZK-SNARK based implementation of decentralized anonymous payment systems [9].

Besides overviewing the operations of EZC and ZeroCash, we will additionally compare these proposals with ZeroCoin.

Extended ZeroCoin

Extended ZeroCoin is an enhanced variant of ZeroCoin, dubbed EZC, that enables the expenditure of transaction amounts exceeding the value of 1 BTC while concealing these amounts from the network. Similar to ZeroCoin, EZC leverages accumulators and ZKPoK protocols to construct multi-valued ZCs. The resulting coins can be either spent as regular Bitcoins or can be spent directly in the network without the need to transform them back to equivalent value BTCs. Additionally, EZC transactions require that the transaction amounts only need to be revealed to the payment sender and recipient, and not to the rest of the participants of the system. It is noteworthy, that since EZC coins (henceforth referred to as eZC) do not have to be exchanged back to BTCs, this scheme also prevents the leakage of the balances of those addresses who opt out from exchanging their coins to BTCs.

Figure 5.3 compares the main operations of EZC to ZC.

Similar to ZeroCoin, a fundamental assumption for the security of EZC is that the public parameters of the system are generated honestly (i.e., in a way that complies with the security definition of the primitives). As mentioned earlier, EZC supports Mint operation, denoted by EZC.Mint, where arbitrary valued BTCs are converted to an anonymous EZC coin (eZC), Spend, denoted by EZC.Spend, where eZCs are spent in the form of BTCs, and Pour, denoted by EZC.Pour, where eZCs are spent in the form of freshly generated eZCs.

Similar to conventional Bitcoin payments, the validity of each transaction is verified by the network peers, who subsequently work toward confirming valid transactions in blocks. For simplicity, we will refer to a transaction resulting from operation O by an O transaction (e.g., a Mint transaction refers to a transaction output by the Mint procedure).

Overview of EZC: During setup, the system runs the Setup of a dynamic accumulator scheme (i.e., Acc.Setup). Let this accumulator be denoted by AccEzc. AccEzc includes all properly minted and confirmed eZCs.

In EZC, the EZC.Mint transaction is constructed in a similar way to the that of ZeroCoin, and consists of an input (in BTCs) and an output that includes

Comparison between EZC and ZC

Figure 5.3 Comparison between EZC and ZC. Each ZC corresponds to a single BTC and can only be spent in the form of BTCs. EZC, on the other hand, enables the construction of a multivalued eZC and can be spent in eZCs without the need to transform them back to BTCs.

information related to the created eZCs. However, unlike ZeroCoin, the coins generated with EZC.Mint can accommodate any payment value vaC (e.g., in BTCs).

The outputs of this transaction consist of a commitment cmtr(ser,vaC) to val and to a random serial number ser, and of a proof of c’s correctness. As we show later, val is revealed by the peer who runs EZC.Mint to all the peers in the network but ser is kept private until the eZC that is minted is spent. The constructed transaction is signed using the Bitcoin private keys corresponding to the input address(es). The correctness of EZC.Mint transactions is verified by the rest of the peers in the network and correct EZC.Mint transactions are included in the longest blockchain. After confirmation of an EZC.Mint transaction, the commitment cmtr(ser,val) is added (using the Acc.Add procedure) as a member of Accezc.

To spend an eZC in the form of BTCs of value vaC, the eZC-owner—who knows ser and the opening of cmtrser, val—constructs a proof n that ser indeed corresponds to a commitment to a value val that is a member of AccEZC. He or she then engages in EZC.Spend by constructing a transaction signed with a signature of knowledge of n. The resulting transaction has a similar structure to a Bitcoin transaction, where n is used as input and its output can distribute val to one or more Bitcoin addresses. Note that for peers to be able to verify the correctness of such a transaction, the serial ser must be revealed; nevertheless, no entity is able to link the EZC.Spend transaction to a particular EZC.Mint transaction, and, thus to the btc-s that created it.

On the other hand, to spend an eZC in the form of anonymous eZCs of the same or smaller value val', the payer reveals ser, and engages in a similar set of operations as in EZC.Spend to construct a proof n that the coins involved in the transaction are properly created. To accommodate for the creation of the recipient’s eZC, the two parties construct a commitment cmtr' (val', ser') to a freshly generated serial ser' and to the payment amount val'. n contains a proof that the payment amount (val) does not exceed the value of the payer’s coin (val'). Finally, n is used to produce a signature of knowledge on the output commitment cmtr'(val', ser') into an EZC.Pour transaction, which is released to the network with ser'. As soon as the latter is confirmed, cmtr' val', ser' is added by the peers to AccEZC. Note that val' is kept private between the payer and the payment recipient, while ser' and the opening of cmtr'val', ser' is only known to the payment recipient.

Protocol specification: In what follows, we detail the operations in EZC. In the sequel, we denote the public information associated with an eZC by pubeZCand the corresponding private information by seceZC.

• params — EZC.Setup(A), the setup of EZC, running with input a security parameter A and produces the system parameters params. More specifically, EZC.Setup runs AccEZC .Setup(A) to obtain (N, u), and generates primes p, q, such that p = 2f • q + 1, f > 1. It then picks g, h, and w such that

Finally, it sets

• n, pubeZC, u(seceZC)} — EZC.Mint(IETC, params), that performs the conversion of one or more BTCs to eZCs. This operation is executed by the owner u of a set of BTCs IETC that are converted into an eZC with public information pubeZCand private information seceZC. Here, u picks ser, r ——R G, where ser is the serial number of the generated eZC computes pubezc = cmtrser, val, and a ZKPoK n asserting that pubeZC is correctly formed:

Note that the EZC.Mint transaction is constructed similarly to a standard Bit- coin transaction, where the BTCs are used as input and (pubeZC, n) is used as output. Subsequently, peers verify that pubeZC is correctly formed by running the ZKPoK verification protocol for n and by confirming that the input BTCs were not spent in the past, as is currently done in Bitcoin. If the transaction is deemed valid by the majority of the computation power of the network, pubeZC is included in the blockchain, and pubeZC is considered as a valid member of the public accumulator AccEZC. User u’s private output is seceZC = (ser, r), while {seceZC, val} is stored in u’s local memory.

• OBTC ^ EZC.Spend[params, serS, uS(seceZCs, pubeZCs)] that is performed to spend eZCs back to BTCs. This operation results in a transaction that uses as input (seceZCs ,pubeZCs) and spends them in BTCs of value val to a set of Bit- coin addresses IBTC. Here, the sender uS first computes the public accumulator value Accezc locally by running Accezc. Accumulate(N, u, {pubeZC}VepubLoi for the set of EZC commitments that have appeared in the longest blockchain so far. The sender retrieves seceZCs from his or her local memory and runs:

to compute the witness wS for pubeZCs’s membership in AccEZC. Furthermore, uS computes a ZKPoK n to show that serS corresponds to an eZC whose public information (here, pubeZCs) is part of AccEZC, and that it corresponds to a value val. Subsequently, it converts n to a signature of knowledge on OBTC:

Finally, uS announces the corresponding signature within a transaction to the EZC network, which, after confirming the transactions’ correctness, it includes the latter in a block.[1]

  • • {(pnbezcs, PubezcR,us(se<ZoS),uR(seCezcR))/^} — EZC.Pour
  • (params, ser s , Accezc, us (vat cr, vat s , rs, ser'S, r's ),UR(vat r, ser r,tr)), where an eZC is spent to one or more other eZCs. This is an interactive operation between a payment sender u S and a payment recipient uR .It takes as input the information associated with an eZC of uS (e.g., seceZCs and pubeZCs) and spends it in the form of a new eZC that belongs to uR, eZCR; if change amounts should be incorporated, this operation outputs additionally a eZC that belongs to uS denoted by eZCS.

Here, uR’s private input seceZCR consists of a serial number serR for his or her new coin and a random number rS G Z(p-1)/2 that will be used in her new coin’s commitment. Assuming that (serS, rS, vatS) is the entry for eZCS in uS’s local memory, uS announces the serial number serS of eZCS and privately contributes rS and vatS to compute the eZCS validity proof as in EZC.Spend. Finally, uS’s private input includes the values (ser'S, r's) used for eZCS/’s construction. We emphasize that seceZCR should be kept private even toward uS so the latter is not able to trace further spendings of eZCR.

In more detail, the payment sender uS and recipient uR engage in the following operations:

1. uS proves the validity of eZCS. This is achieved as follows. uS runs ACC.Accumulate(N, u, {pubeZC}VpUb|_0g) for the set of eZC-commitments that appear in the EZC-blockchain to compute the current public accumulator value Accezc. Subsequently, uS runs ACC.GenWitness(params, pubeZC seceZCs, Accezc) to extract a witness wS that eZCS has been confirmed in a block. Then, uS computes n as described in the previous section; that is:

2. uS mints eZCS. This is achieved as follows. For the transaction output side, uS picks ser'S iR Zp-1, and r's ——R Zp_i, and computes the public information associated to eZCS, as pubezCs = gserS hva[Swr'S, where vatS = vatS - vatR is the change value. Finally, uS updates n to include a proof that pubezCs is properly formed:

NIZKPoK(a, в, y, S, e, Z, n) :

3. uS needs to enable uR to privately mint for the payment coin eZCR. For that purpose, uS picks rSRR Zp-1, computes the auxiliary token lSR = Нт1 R wrsR, and updates ZKPoK n so as to include a proof of correctness of ?sr, and sends it to uR along with rSR:

4. uR mints eZCR: uR picks serRR Zp_i, and rRR Zp-1 and computes pubgzcR = gserRhm[R • wrR; he or she extends n to include proof of correctness of pubeZCR and converts it into a ZKSoK to sign serS and pubeZCR and pubeZCS in the longest blockchain resulting into another transaction:

The resulting transaction is announced to the network of EZCpeers, who upon verification of its correctness work toward its inclusion into a block. After such a transaction is included into a block, pubeZCR and pubeZCS are considered members of AccEZC.

The security of Extended ZeroCoin rests upon the standard security assumptions of the underlying signature of knowledge, and dynamic accumulator schemes used within. It is easy to see that a spending operation in Extended ZeroCoin costs more in terms of computation that a ZeroCoin spending. However, note that in Zero- Coin direct spendings from ZeroCoins to ZeroCoins is not possible, and one would need to convert a ZeroCoin to a Bitcoin and the latter to a ZeroCoin to be able to always maintain its coin belongings in secrecy. If one takes into account that a ZeroCoin has a fixed value, and one would need to perform multiple spendings to perform a single payment worth of few Bitcoins, the overall cost of maintaining anonymous payments in ZeroCoin may end up being comparable to the one of Extended ZeroCoin.

  • [1] Note that if fees are to be supported, the fee amount should be explicitly stated within the messagein the signature (transaction).
< Prev   CONTENTS   Source   Next >