mirror of https://github.com/zcash/orchard.git
Merge pull request #17 from zcash/book-keys-addresses
book: Document design rationale for Orchard keys and addresses
This commit is contained in:
commit
b0b3536a5a
|
@ -9,6 +9,7 @@
|
||||||
- [Spending notes](user/spending-notes.md)
|
- [Spending notes](user/spending-notes.md)
|
||||||
- [Integration into an existing chain](user/integration.md)
|
- [Integration into an existing chain](user/integration.md)
|
||||||
- [Design](design.md)
|
- [Design](design.md)
|
||||||
|
- [Keys and addresses](design/keys.md)
|
||||||
- [Actions](design/actions.md)
|
- [Actions](design/actions.md)
|
||||||
- [Commitments](design/commitments.md)
|
- [Commitments](design/commitments.md)
|
||||||
- [Commitment tree](design/commitment-tree.md)
|
- [Commitment tree](design/commitment-tree.md)
|
||||||
|
|
|
@ -20,21 +20,6 @@
|
||||||
- Need to consider the privacy issue related to light clients requesting individual
|
- Need to consider the privacy issue related to light clients requesting individual
|
||||||
memos vs being able to fetch all memos.
|
memos vs being able to fetch all memos.
|
||||||
|
|
||||||
### Key structure
|
|
||||||
|
|
||||||
Provisional proposal: exactly the same key structure as Sapling.
|
|
||||||
|
|
||||||
Group hashing uses the isogeny.
|
|
||||||
|
|
||||||
- nsk goes away; `nk` is now a field element
|
|
||||||
- TODO: ak / nk split enables splitting the security argument, but could consider merging.
|
|
||||||
Merging would help with ivk derivation perf (though as a commitment now it's pretty cheap)
|
|
||||||
|
|
||||||
ZIP 32 integration
|
|
||||||
- Use same Sapling design?
|
|
||||||
- Simpler "hardened-only" derivation structure?
|
|
||||||
- Improve diversifier integration / documentation
|
|
||||||
|
|
||||||
### Note structure
|
### Note structure
|
||||||
|
|
||||||
- TODO: UDAs: arbitrary vs whitelisted
|
- TODO: UDAs: arbitrary vs whitelisted
|
||||||
|
|
|
@ -0,0 +1,97 @@
|
||||||
|
# Keys and addresses
|
||||||
|
|
||||||
|
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
|
||||||
|
use of the Pallas-Vesta curve cycle in the Orchard protocol. (We already use Vesta as
|
||||||
|
the curve on which Halo 2 proofs are computed, but this doesn't yet require a cycle.)
|
||||||
|
|
||||||
|
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
|
||||||
|
defense-in-depth, in case RedDSA was found to have weaknesses; an adversary who could
|
||||||
|
recover $\mathsf{ask}$ would not be able to spend funds. In practice it has not been
|
||||||
|
feasible to manage $\mathsf{nsk}$ much more securely than a full viewing key, as the
|
||||||
|
computational power required to generate Sapling proofs has made it necessary to perform
|
||||||
|
this step on the same device that is creating the overall transaction (rather than on a
|
||||||
|
more constrained device like a hardware wallet). We are also more confident in RedDSA
|
||||||
|
now.
|
||||||
|
|
||||||
|
- $\mathsf{nk}$ is now a field element instead of a curve point, making it more efficient
|
||||||
|
to generate nullifiers.
|
||||||
|
|
||||||
|
- $\mathsf{ovk}$ is now derived from $\mathsf{fvk}$, instead of being derived in parallel.
|
||||||
|
This places it in a similar position within the key structure to $\mathsf{ivk}$, and
|
||||||
|
also removes an issue where two full viewing keys could be constructed that have the
|
||||||
|
same $\mathsf{ivk}$ but different $\mathsf{ovk}$s. Users still have control over whether
|
||||||
|
$\mathsf{ovk}$ is used when constructing a transaction.
|
||||||
|
|
||||||
|
- All diversifiers now result in valid payment addresses, due to group hashing into Pallas
|
||||||
|
being specified to be infallible. This removes significant complexity from the use cases
|
||||||
|
for diversified addresses.
|
||||||
|
|
||||||
|
Other than the above, Orchard retains the same design rationale for its keys and addresses
|
||||||
|
as Sapling, and the same bech32 encoding. For example, diversifiers remain at 11 bytes, so
|
||||||
|
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
|
||||||
|
|
||||||
|
When designing Sapling, we defined a [BIP 32]-like mechanism for generating hierarchical
|
||||||
|
deterministic wallets in [ZIP 32]. We decided at the time to stick closely to the design
|
||||||
|
of BIP 32, on the assumption that there were Bitcoin use cases that used both hardened and
|
||||||
|
non-hardened derivation that we might not be aware of. This decision created significant
|
||||||
|
complexity for Sapling: we needed to handle derivation separately for each component of
|
||||||
|
the expanded spending key and full viewing key (whereas for transparent addresses there is
|
||||||
|
only a single component in the spending key).
|
||||||
|
|
||||||
|
Non-hardened derivation enables creating a multi-level path of child addresses below some
|
||||||
|
parent address, without involving the parent spending key. The primary use case for this
|
||||||
|
is HD wallets for transparent addresses, which use the following structure defined in
|
||||||
|
[BIP 44]:
|
||||||
|
|
||||||
|
- (H) BIP 44
|
||||||
|
- (H) Coin type: Zcash
|
||||||
|
- (H) Account 0
|
||||||
|
- (N) Normal addresses
|
||||||
|
- (N) Address 0
|
||||||
|
- (N) Address 1...
|
||||||
|
- (N) Change addresses
|
||||||
|
- (N) Change address 0
|
||||||
|
- (N) Change address 1...
|
||||||
|
- (H) Account 1...
|
||||||
|
|
||||||
|
Shielded accounts do not require separating change addresses from normal addresses, because
|
||||||
|
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 would cause a linear slow-down
|
||||||
|
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:
|
||||||
|
|
||||||
|
- (H) ZIP 32
|
||||||
|
- (H) Coin type: Zcash
|
||||||
|
- (H) Account 0
|
||||||
|
- Diversified address 0
|
||||||
|
- Diversified address 1...
|
||||||
|
- (H) Account 1...
|
||||||
|
|
||||||
|
Non-hardened derivation is therefore only required for use-cases that require the ability
|
||||||
|
to derive more than one child layer of addresses. However, in the years since Sapling was
|
||||||
|
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
|
||||||
|
design than ZIP 32. All derivations produce an opaque binary spending key, from which the
|
||||||
|
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 44]: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
|
||||||
|
[ZIP 32]: https://zips.z.cash/zip-0032
|
Loading…
Reference in New Issue