Comments on tech spec about zips HOT 8 CLOSED

Thanks for the quick response:)

You say earlier you will only apply sha-256 on 512 bit blocks,

The PRF uses the SHA256 compression function over 512-bit blocks, but for the commitments, we use the full SHA256 hash.

In that case, you may want to clarify in sec 3.2 or 4.2.1, that when you use the name SHA256 rather than CRH you mean the full SHA256 hash

from zips.

Great and helpful review! 👍

So, for example, last bit of pk_{enc} is always 0?

I believe to avoid the point at infinity, yes.

You say earlier you will only apply sha-256 on 512 bit blocks,

The PRF uses the SHA256 compression function over 512-bit blocks, but for the commitments, we use the full SHA256 hash.

from zips.

Thanks for your review!

@arielgabizon wrote:

I would mention that notation and names of objects are different from zerocash paper. [...] In that context, it might even be good to have a `dictionary' of names here to names in zerocash paper.

+1, I will add that near the start.

sec 3.2 : I would mention that the `i-1' is mod 2

It isn't mod 2; i is always either 1 or 2.

You say pk_enc is 256 bytes [bits] long, but by looking at paper Daniel [Bernstein] paper on curve25519, it outputs an integer in range {0,..,2²⁵⁵-19-1}. So, for example, last bit of pk_enc is always 0?

Yes. As the paper says in section 2, "Note that Curve25519 is not surjective: in particular, its final [i.e. most significant] output bit is always 0 and need not be transmitted." It is transmitted in this protocol. (This isn't anything to do with the point at infinity; it's just that a point is encoded as its x coordinate, and the size of that is not a multiple of 8 bits. The point at infinity is encoded as zero: X₀(∞) = 0.)

Keys need not be validated; Curve25519 is well-defined on all inputs, and the ability to publish addresses with pk_enc not in the range of its output is not a security problem. I intend to add a Security Considerations section that will deal with issues like that.

Sec 5 - You haven't defined transaction.

Agreed, there's a forward reference problem here.

Page 10-11: It's hard to understand without context, what is v^old_pub and v^new_pub. I am guessing v^new_pub is coins from the non-private part of the chain that are used in the transaction?

v^new_pub is transparent value output by the JoinSplit operation.

This should be explained. I did not see any place where it is explained that we are talking about a chain with public and anonymous coins at the same time

Agreed.

Page 14: value stored' ->a value stored' or `values stored'

"Value" is being used as a mass noun here.

from zips.

Another small comment:
In sec 4.5,
when you start discussing treestates it's not completely clear what you mean,
and how they relate to blocks.
Do you mean the treestate of the note commitment tree?
Is the note commitment tree stored in the blocks somehow?

from zips.

I will clarify this. A treestate refers to the state of the note commitment tree and nullifier set.

from zips.

Thanks. Is the treestate specifically the merkle root of the updated note commitment tree?
If so might be good to say this explicitly.
Is the updated treestate contained in the block together with the new transactions?
Or do you think of having two separate chains, one for transactions, and one for treestates?
(perhaps not a very important distinction - but just the way it is phrased now saying `treestates are chained' leaves the reader a little unclear about how to think of it, and might help to address this)

from zips.

No, the root of that tree is called an anchor. Treestates are not explicitly contained in blocks. (The new anchor could be explicitly included in the block, and that might have some advantages, but it isn't in the current spec.)

from zips.

@arielgabizon I think these are mostly addressed; please open a new issue if anything is still unclear in 2016.0-beta-1.

from zips.