Is there a whitepaper?

Technology
1

Is there a whitepaper or another technical description (other than the code itself)? (Apologies if it’s at Github. That site is blocked at my office)

1 Like
2

The zerocash paper exists which goes in-depth: Paper | Zerocash

We make some changes from this paper that we’re working to formalize in a protocol description, but that isn’t finished yet. (There are lots of further changes to make, so it could be irritating to update a spec consistently right now.)

2 Likes
3

How accurate is the Zerocash paper with respect to how Zcash works? Is it large strokes the same, or lots of changes?

I completely understand about not wanting to update a spec mid development.

4

It’s mostly the same, but certain operations were merged together or simplified, and the semantics of integration with the outside consensus rules has changed somewhat.

5

Thank you. I will take a look at it, and look forward to learning more details about Zcash as they firm up.

6

By the way, a (very early) paper describing our implementation, which might be easier to understand than the zerocash paper, is here: zips/protocol.pdf at main · zcash/zips · GitHub

2 Likes
7

Relative to the Zerocash paper,

  • Mint and Pour operations are merged into a generalized Pour. This is possible because the generalized Pour has a public (transparent) input as well as a public output.
  • A transaction at the Bitcoin-like layer is associated with a sequence of Pours, as opposed to Pours (and Mints) being encoded as script operations. Pours later in this sequence can spend coins output by Pours earlier in the same transaction (this is called a “chained Pour”), which was not previously possible.
  • A security issue that would have allowed the Receive operation to receive coins that later become unspendable (we call this the Faerie Gold attack) will be fixed.
  • We may switch to a memory-hard proof of work (one of the candidates under consideration is Biryukov and Khovratovich’s Asymmetric proof-of-work based on the Generalized Birthday problem, which supports memory-hard proofs with low-memory verification).
  • The key-private public key encryption may be changed to crypto_box_seal [edit: actually a slightly optimized variant, still based on crypto_box] and the signature scheme may be changed to Ed25519 [much later edit: this did happen for JoinSplit signatures, not for transparent signatures which are still ECDSA].
  • There may be a “memo” field associated with sent coins.
  • We may change the hash function used for the Merkle tree over commitments from SHA-256-compress to a hash that is more “SNARK-friendly” (i.e. allows smaller circuit size and therefore better Pour performance and memory usage) [much later edit: we didn’t do this for launch but are doing it for Sapling].

Note that not all of these protocol changes are implemented yet in the public alpha, and there is no guarantee of all of them making it into 1.0.

3 Likes
8

For a more dynamic view of possible --not necessarily committed-- 1.0 features (and some tickets that are not features), see this github query.

9

I would very, very strongly like to see this come to pass. :+1:

1 Like
10

Could you please elaborate? What is crypto_box_seal?

Thank you for bearing with the newbie :).

Pablo.

11

crypto_box_seal is an encryption scheme implemented by the libsodium library. It is not the scheme we ended up using, although the scheme we’re using adopts some of its security features.

For a detailed explanation (written for an audience of cryptographers) see section 8.7 of zips/protocol.pdf at main · zcash/zips · GitHub .

12

Also note that we did in fact change the signature scheme used for signing JoinSplits to Ed25519. We did not change the signature scheme used for parts of the protocol that follow Bitcoin; that is still ECDSA over secp256k1.

13

Thank you for the detailed response, I will get through the material this week.

Pablo.