search

zcash / zips

Zcash Improvement Proposals
https://zips.z.cash
MIT License
274 stars 156 forks source link

Knapsack issue: contains notes on multiple small issues in the protocol #624

Closed zancas closed 11 months ago

zancas commented 2 years ago

I believe that specification is in error, since I think of NU5 as "onward" relative to Sapling and it doesn't have the referenced components (in particular it doesn't have an nsk). I lost time searching for an nsk in the Orchard diagram.

The diagrams are structured such that higher components have diminished authority relative to lower, is it correct for an OVK and an IVK to have the same value on the authority dimension?

zancas commented 2 years ago

There are elisions of the pattern "if" from words in the defintion of "anchor" on page 17 of the spec.

zancas commented 2 years ago

In 4.1.5 Key Agreement this:

"is a cryptographic protocol in which two parties agree a shared secret, "

Is intended to read as this:

"is a cryptographic protocol in which two parties agree on a shared secret, "

zancas commented 2 years ago

If e.g. KA.Public were rendered in a more distinctive font it would be more difficult for the reader to misinterpret the . as English punctuation instead of a part of the token.

daira commented 11 months ago

I believe that specification is in error, since I think of NU5 as "onward" relative to Sapling and it doesn't have the referenced components (in particular it doesn't have an nsk). I lost time searching for an nsk in the Orchard diagram.

I don't see any implication in the spec that Orchard has an $\mathsf{nsk}$. They are different protocols.

The diagrams are structured such that higher components have diminished authority relative to lower, is it correct for an OVK and an IVK to have the same value on the authority dimension?

Yes in the sense that they are incomparable in authority, so there's no reason for one to be lower or higher than the other.

There are elisions of the pattern "if" from words in the definition of "anchor" on page 17 of the spec.

I don't know what you mean. All the uses of "anchor" around there look correct.

In 4.1.5 Key Agreement this:

"is a cryptographic protocol in which two parties agree a shared secret, "

Is intended to read as this:

"is a cryptographic protocol in which two parties agree on a shared secret, "

This is apparently a British/US English usage difference. In general we don't correct such differences as long as they are somewhat consistent within a document.

If e.g. KA.Public were rendered in a more distinctive font it would be more difficult for the reader to misinterpret the . as English punctuation instead of a part of the token.

I think it's unambiguous. The usage as a field selector is always rendered without any space on either side; the use as a period/full stop is always followed by a space or the end of the paragraph. This is also a common notation in many programming languages. In any case I'm not changing the font choices — that would be hugely disruptive make-work.