mirror of https://github.com/zcash/zips.git
Address Daira's comments
This commit is contained in:
parent
9a87098e0c
commit
a5309ed60e
21
zip-0032.rst
21
zip-0032.rst
|
@ -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*.
|
- *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
|
- 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.
|
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
|
- 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*.
|
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`\ )
|
- 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
|
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.
|
will garner much usage once Sapling activates, but is presented for those users who may require it.
|
||||||
|
|
||||||
Sprout extended keys
|
Sprout extended keys
|
||||||
|
@ -231,13 +231,14 @@ derivation:
|
||||||
|
|
||||||
- ``coin_type``: a constant identifying the cybercoin that this subtree's keys are used with. For
|
- ``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
|
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]_.
|
- ``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
|
Unlike BIP 44, neither Sprout nor Sapling have a `change` path level. The use of change addresses in Bitcoin
|
||||||
never publicly visible in transactions, which means that sending change back to the originating address is
|
is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating
|
||||||
indistinguishable from using a change address.
|
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
|
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
|
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
|
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
|
user experience of giving a unique address to each recipient.
|
||||||
2\ :sup:`88` payment addresses.
|
|
||||||
|
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,
|
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::
|
they MAY additionally support a non-hardened ``address_index`` path level as in BIP 44::
|
||||||
|
|
Loading…
Reference in New Issue