[protocol spec] Some comments from Ariel

[arielgabizon]

• '..a multiple of 8 bits' -> no need for 'bits' again in this sentence, change to, e.g., 'which is a multiple of 8'

  • I disagree, "a multiple of 8 bits" is clearer.

• 3.3 'treestates are chained as follows:..' You don't see in the bullets below how the output treestate of a transaction is computed from the input treestate.

  • Yes, filed as [protocol spec] Clarify how a transaction's output treestate is computed from its input treestate #931.

Sec 4:

• 'agree a shared secret' -> 'agree on a shared secret' (twice)

  • "agree a shared secret" uses meaning 2 here: https://www.merriam-webster.com/dictionary/agree and is standard for British English. Zcash documentation style allows any ideolect that is consistent within a document.

• 'In fact the instantiation' -> 'In fact, the instantiation' (perhaps add comma)

  • Done locally. (My style is to include the comma iff there would be a pause when spoken, which there would be here, but not in shorter sentences such as "In fact the history is a little more complicated.")

• Proof of Knowledge bullet. Suggest to change to :

  For any efficient adversary A there exists an efficient extractor E_A, such that for any input x:ZK.PrimaryInput given to both as input, the following holds.
  The probability that A outputs \pi: ZK.proof such that ZK.Verify(x,\pi)=1 but E_A doesn't output w such that (x,w)\in ZK.SatisfyingInputs is negligible.
  Here A and E_A are assumed to be deterministic and the probability is over the randomness of ZK.Gen.

  (If you want A and E_A not to be deterministic you need to also give E_A access to random tape of A, I like to just assume they are deterministic as since they are non-uniform circuits you can fix A's randomness to maximize its success of producing a proof)

  • Moved to [protocol spec] Review definition of Knowledge Soundness #932.

• `adapted to state concrete rather than asymptotic security' - I would erase this, if you use the term 'negligible' you are talking about asymptotic security.

  • The word "negligible" is no longer used, since that isn't what was meant. Zcash aims for 125 bits of concrete security (see the slides on "Cryptographic Strength" in my "Understanding the Security of Zcash" presentation).

• 4.1.7 - would just add reference to wikipedia: https://en.wikipedia.org/wiki/Commitment_scheme . It explains well the notions of computational hiding and binding.

  • Again we want a concrete security definition. Wikipedia only gives an asymptotic definition (and personally I think that page is quite waffly and a bit of a mess). Also it unnecessarily requires the randomness to be a bit string, which it is not for our commitment schemes; and its definition of hiding unnecessarily specifies $x \neq x'.$ Apart from those issues and differences in notation, the definitions we give are equivalent to those currently on Wikipedia.
  • Note that we never reference Wikipedia, and if we did it would have to be a specific page version, since Wikipedia pages may be edited by an adversary.

• In references PGHR -> PHGR i.e. Howell appears before Gentry.

  • This was fixed.

[arielgabizon]

Also, what I can't understand from the protocol spec is - when vpub_new ZEC are inserted to the transparent value pool from a joinsplit - what is the transparent address they go to? That address doesn't seem to be part of the joinsplit description.. @daira @str4d @ebfull ?

[str4d]

Think of vpub_new as an input to the transparent part of the transaction. The address it goes to is therefore defined by the transparent outputs. If there aren't any, then the vpub_new goes entirely to the miner as fee, just like any other leftover transparent input value.

[arielgabizon]

Thanks @str4d . That doesn't seem to be completely well-defined . If there are no transparent outputs or exactly one, it is well-defined. But what if there are multiple transparent outputs - where does vpub_new go to in that case?

[str4d]

Then the sum of the values of the transparent outputs must be less than or equal to vpub_new.

More precisely, the balance equation is:

sum(tx_inputs) + sum(vpub_new) >= sum(tx_outputs) + sum(vpub_old)

With the difference becoming the fee. There's also a requirement that vpub_old and vpub_new can't both be non-zero in the same JoinSplit, but that is just to reduce data leakage AFAIK.

[arielgabizon]

ahh I think I get it now thanks!

[arielgabizon]

Another issue that came up while discussing something with @str4d. It is described in 4.3 of spec; that we should have h_sig=HASH(randomSeed,nf_old,joinSplitPubKey).
But I could not find any place in the spec where this is enforced in circuit or as consensus rule.

[daira]

See the end of section 4.3:

"Consensus rules:
[...]

• The proof π_JoinSplit MUST be valid given a primary input formed from the other fields and hSig. I.e. it must be the case that ZK_JoinSplit.Verify((rt, nf^old_1..N^old, cm^new_1..N^new, v^old_pub, v^new_pub, hSig, h_1..N^old), π_JoinSplit) = 1."

hSig here means the value computed as described in the same section.

[arielgabizon]

joinsplit.verify checks h_i's are certain function of h_sig.. it does not check anything about h_sig being function of randomSeed,nf_old,joinSplitPubKey (at least according to 4.9)

[daira]

But hSig isn't provided anywhere as protocol input. The only way to compute it is from the other fields as described in 4.3. (I agree that if it were provided as input, then there would need to be a rule that that input is consistent with the computed value.)

[arielgabizon]

if what you mean is hSig is computed by the verifier from randomSeed,nf_old,joinSplitPubKey, that are given themselves to him as input, then I can see that being fine

[daira]

Yes, that's exactly the situation.

[arielgabizon]

OK..great! Then that should be made more clear in the spec.

[daira]

How would you suggest I clarify 4.3? Maybe say "hSig as computed above" in the consensus rule I quoted?

[arielgabizon]

Ok..now reading 4.3 I understand how you thought of it.
I would add, just above 4.10, something like
"Note that as opposed to the other parts of the primary input H_sig is not explicitly given,
but computed according to a consensus rule as a function of randomSeed,nf_old,joinSplitPubKey,
that are given as part of the joinsplit description".
Another option (can also do both)
is to add another bullet in 4.3 under consensus rules: where it says "the value h_sig is computed as ... and then given as input to joinsplit.verify"

[str4d]

For reference, hSig calculation for verification happens here.

[daira]

Done.