Address Daira's comments

This commit is contained in:
str4d 2018-06-08 08:42:37 +12:00 committed by Daira Hopwood
parent 9a87098e0c
commit a5309ed60e
1 changed files with 12 additions and 9 deletions

View File

@ -61,7 +61,7 @@ Most of the notation and functions used in this ZIP are defined in the Sapling p
- *a* || *b* means the concatenation of sequences *a* then *b*.
- [*k*] *P* means scalar multiplication in the group *P*.
- [*k*] *P* means scalar multiplication of the elliptic curve point *P* by the scalar *k*.
- LEOS2IP\ :sub:`l`\ (*S*) is the integer in range {0..2\ :sup:`l`\ -1} represented in little-endian order
by the byte sequence *S* of length *l*/8.
@ -69,7 +69,7 @@ Most of the notation and functions used in this ZIP are defined in the Sapling p
- BLAKE2b-512(*p*, *x*) refers to unkeyed BLAKE2b-512 in sequential mode, with an output digest length of 64
bytes, 16-byte personalization string *p*, and input *x*.
- PRF\ :sup:`expand`\ (*sk, t*) := BLAKE2b-512("Zcash_ExpandSeed", *sk* || *t*)
- PRF\ :sup:`expand`\ (*sk*, *t*) := BLAKE2b-512("Zcash_ExpandSeed", *sk* || *t*)
- ToScalar(*x*) := LEOS2IP(*x*) (mod *r*\ :sub:`J`\ )
@ -175,7 +175,7 @@ CDKfvk((*ak*\ :sub:`par`\ , *nk*\ :sub:`par`\ , *ovk*\ :sub:`par`\ , *c*\ :sub:`
Specification: Sprout key derivation
====================================
For completeness, we define a system for deriving a tree of Sprout keys components. It is unlikely that this
For completeness, we define a system for deriving a tree of Sprout key components. It is unlikely that this
will garner much usage once Sapling activates, but is presented for those users who may require it.
Sprout extended keys
@ -231,13 +231,14 @@ derivation:
- ``coin_type``: a constant identifying the cybercoin that this subtree's keys are used with. For
compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44
[#slip-0044]_.
[#slip-0044]_. Note that in keeping with that document, all cybercoin testnets share ``coin_type`` index 1.
- ``account``: numbered from index 0 in sequentially increasing manner. Defined as in BIP 44 [#bip-0044]_.
Unlike BIP 44, neither Sprout nor Sapling have a `change` path level. This is because shielded addresses are
never publicly visible in transactions, which means that sending change back to the originating address is
indistinguishable from using a change address.
Unlike BIP 44, neither Sprout nor Sapling have a `change` path level. The use of change addresses in Bitcoin
is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating
external and internal address usage. Shielded addresses are never publicly visible in transactions, which
means that sending change back to the originating address is indistinguishable from using a change address.
Sapling key path
----------------
@ -255,8 +256,10 @@ ZIP 32 derivation MUST support the following path::
Wallets MUST support generating the default payment address (corresponding to the default diversifier). They
MAY also support generating a stream of payment addresses for a given account, if they wish to maintain the
user experience of giving a unique address to each recipient. Note that a given account can have a maximum of
2\ :sup:`88` payment addresses.
user experience of giving a unique address to each recipient.
Note that a given account can have a maximum of approximately 2\ :sup:`87` payment addresses, because each
diversifier has around a 50% chance of being invalid.
If in certain circumstances a wallet needs to derive independent spend authorities within a single account,
they MAY additionally support a non-hardened ``address_index`` path level as in BIP 44::