Advanced Integration

The following section describes a number of features that implementers might want to consider.

Using Transaction Windows

The original Zerocoin proposal defines the confirmed transaction set as the set of all confirmed ZEROCOIN_MINT transactions in the block chain. For efficiency reasons, some clients might wish to define this set over a smaller subset of the transactions. For example, the transaction set might include only transactions issued within a particular 2-year period.

This approach has advantages and disadvantages. The advantages are:

• It simplifies and speeds up Accumulator calculation (by accumulating fewer transactions).
• It reduces the amount of data clients need to store. This is particularly important for the serial number double spending checks.
• It allows for periodic re-generation of the Zerocoin parameters (both N and the internal parameters).

The drawback to this approach is a reduction in the size of the anonymity set. Zerocoin works like a laundry, 'mixing' coins minted by different users. Since there will presumably be fewer coins in a window, the anonymity becomes somewhat weaker. Additionally: spenders will have to specify the window in which their coin was Minted, further reducing anonymity. If clients refuse to store old windows, this could imply limits on the lifespan of a single zerocoin.

Using multiple accumulators

One security concern in the Zerocoin system is the need for a trusted modulus N (see Generating Zerocoin parameters). If this value is incorrectly generated or an untrustworthy generator retains the factorization of N, then some parties might be able to double-spend Zerocoins.

One solution to this problem is to simultaneously use multiple distinct N values, each one keying a separate Accumulator. Provided that one N value is honestly-generated this will prevent double spending. This approach requires changes to the libzerocoin code (which we will likely make in future versions) and requires a separate proof of knowledge for each accumulator, which would likely add 4-7KB to the CoinSpend proof size for each additional N.

Throwing away the CoinSpend signature/proofs

One limitation of Zerocoin is the need to store a relatively large CoinSpend signature (containing a proof of knowledge) in the block chain. At present this signature is >25KB serialized and thus represents a major burden on chain storage.

One solution to this problem is to distribute the full CoinSpend signature through some related channel (for example, a Distributed Hash Table or separate block chain) and only include only the transaction serial number and a hash of the CoinSpend signature within the ZEROCOIN_SPEND transaction. The full CoinSpend could be retained for a period of time, then discarded after it has been thoroughly verified by the network. This would reduce the cryptographic contents of the ZEROCOIN_SPEND transaction to approximately 64 bytes.

The disadvantage of this approach is that it makes payees dependent on the honesty of the network. If the CoinSpend proofs are no longer available for verification, payees will have to trust that these proofs were verified successfully before their inclusion into the block chain. Implementing this will require some careful thought and engineering.

Incremental deployment

One area of research is to incrementally deploy Zerocoin within an existing currency. The challenge here is that some clients will not recognize Zerocoin spend transactions, and will therefore not allow users to redeem their coins.

One possible solution is to (temporarily) use one or more trusted parties to facilitate Zerocoin spending. These trusted parties could be removed once all clients natively support the Zerocoin protocol.

This approach requires the following changes:

• Instead of a dedicated ZEROCOIN_MINT transaction, clients should generate a standard Bitcoin transaction that transfers the input to the Bitcoin address of the trusted party. The PublicCoin should be encoded as arbitrary data within the transaction (using standard data embedding techniques.)

• The information in a ZEROCOIN_SPEND transaction can be encoded as arbitrary data within a standard Bitcoin transaction (this must include at minimum, the identity of the redemption transaction, the serial number from the CoinSpend and the hash of the full CoinSpend signature, if not the full signature.) The trusted party can then search for these transactions, verify the CoinSpend and (using standard Bitcoin secret keys) issue a traditional Bitcoin transaction that transfers the inputs of the specified redemption transaction to the spender.

This approach eliminates many of the nice features of Zerocoin and is intended as a temporary solution. However this approach may still be superior to a standard laundry or Chaumian eCash service for the following reasons:

1. A compromise of the trusted party does not harm spenders' anonymity (though they might lose coins).
2. Anonymous coin creation and redemption is fully auditable through the block chain.
3. The role of the trusted party can easily be split among multiple parties using standard k-out-of-N Bitcoin signature techniques.
4. This approach provides an eventual upgrade path to 'full' Zerocoin with no trusted parties.