mirror of https://github.com/zcash/halo2.git
Apply suggestions from review
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
adb377de7d
commit
d541261507
|
@ -2,11 +2,15 @@
|
||||||
|
|
||||||
Orchard keys and payment addresses are structurally similar to Sapling. The main change is
|
Orchard keys and payment addresses are structurally similar to Sapling. The main change is
|
||||||
that Orchard keys use the Pallas curve instead of Jubjub, in order to enable the future
|
that Orchard keys use the Pallas curve instead of Jubjub, in order to enable the future
|
||||||
use of the Pallas-Vesta curve cycle in the Orchard protocol. This involves corresponding
|
use of the Pallas-Vesta curve cycle in the Orchard protocol. (We already use Vesta as
|
||||||
changes to the key derivation process (such as using Sinsemilla for Pallas-efficient
|
the curve on which Halo 2 proofs are computed, but this doesn't yet require a cycle.)
|
||||||
commitments).
|
|
||||||
|
|
||||||
We also make several structural changes, building on the lessons learned from Sapling:
|
Using the Pallas curve and making the most efficient use of the Halo 2 proof system
|
||||||
|
involves corresponding changes to the key derivation process, such as using Sinsemilla
|
||||||
|
for Pallas-efficient commitments. We also take the opportunity to remove all uses of
|
||||||
|
expensive general-purpose hashes (such as BLAKE2s) from the circuit.
|
||||||
|
|
||||||
|
We make several structural changes, building on the lessons learned from Sapling:
|
||||||
|
|
||||||
- The nullifier private key $\mathsf{nsk}$ is removed. Its purpose in Sapling was as
|
- The nullifier private key $\mathsf{nsk}$ is removed. Its purpose in Sapling was as
|
||||||
defense-in-depth, in case RedDSA was found to have weaknesses; an adversary who could
|
defense-in-depth, in case RedDSA was found to have weaknesses; an adversary who could
|
||||||
|
@ -31,8 +35,12 @@ We also make several structural changes, building on the lessons learned from Sa
|
||||||
for diversified addresses.
|
for diversified addresses.
|
||||||
|
|
||||||
Other than the above, Orchard retains the same design rationale for its keys and addresses
|
Other than the above, Orchard retains the same design rationale for its keys and addresses
|
||||||
as Sapling. For example, diversifiers remain at 11 bytes, so that Orchard addresses are
|
as Sapling, and the same bech32 encoding. For example, diversifiers remain at 11 bytes, so
|
||||||
the same length as Sapling addresses.
|
that Orchard addresses are the same length as Sapling addresses.
|
||||||
|
|
||||||
|
The "human-readable part" for Orchard payment addresses is "zo", i.e. all addresses
|
||||||
|
have the prefix "zo1". Other prefixes and key formats will be described in section 5.6
|
||||||
|
of the protocol specification.
|
||||||
|
|
||||||
## Hierarchical deterministic wallets
|
## Hierarchical deterministic wallets
|
||||||
|
|
||||||
|
@ -60,10 +68,10 @@ is HD wallets for transparent addresses, which use the following structure defin
|
||||||
- (N) Change address 1...
|
- (N) Change address 1...
|
||||||
- (H) Account 1...
|
- (H) Account 1...
|
||||||
|
|
||||||
Shielded accounts do not require separating change addresses from normal addresses, due to
|
Shielded accounts do not require separating change addresses from normal addresses, because
|
||||||
addresses not being revealed in transactions. Similarly, there is also no need to generate
|
addresses are not revealed in transactions. Similarly, there is also no need to generate
|
||||||
a fresh spending key for every transaction, and in fact this causes a linear slow-down in
|
a fresh spending key for every transaction, and in fact this would cause a linear slow-down
|
||||||
wallet scanning. But for users that do want to generate multiple addresses per account,
|
in wallet scanning. But for users who do want to generate multiple addresses per account,
|
||||||
they can generate the following structure, which does not use non-hardened derivation:
|
they can generate the following structure, which does not use non-hardened derivation:
|
||||||
|
|
||||||
- (H) ZIP 32
|
- (H) ZIP 32
|
||||||
|
@ -78,8 +86,11 @@ to derive more than one child layer of addresses. However, in the years since Sa
|
||||||
deployed, we have not seen *any* such use cases appear.
|
deployed, we have not seen *any* such use cases appear.
|
||||||
|
|
||||||
Therefore, for Orchard we only define hardened derivation, and do so with a much simpler
|
Therefore, for Orchard we only define hardened derivation, and do so with a much simpler
|
||||||
design that ZIP 32. All derivations produce an opaque binary spending key, from which the
|
design than ZIP 32. All derivations produce an opaque binary spending key, from which the
|
||||||
keys and addresses are then derived.
|
keys and addresses are then derived. As a side benefit, this makes key formats
|
||||||
|
shorter. (The formats that will actually be used in practice for Orchard will correspond
|
||||||
|
to the simpler Sapling formats in the protocol specification, rather than the longer
|
||||||
|
and more complicated "extended" ones defined by ZIP 32.)
|
||||||
|
|
||||||
[BIP 32]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
|
[BIP 32]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
|
||||||
[BIP 44]: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
|
[BIP 44]: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
|
||||||
|
|
Loading…
Reference in New Issue