From adb377de7da8f9cf137ca2e773bcc2deea0e1667 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 8 Feb 2021 18:27:50 +0000 Subject: [PATCH 1/2] book: Document design rationale for Orchard keys and addresses --- book/src/SUMMARY.md | 1 + book/src/design.md | 15 ------- book/src/design/keys.md | 86 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 87 insertions(+), 15 deletions(-) create mode 100644 book/src/design/keys.md diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 485b3119..e8420281 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -9,6 +9,7 @@ - [Spending notes](user/spending-notes.md) - [Integration into an existing chain](user/integration.md) - [Design](design.md) + - [Keys and addresses](design/keys.md) - [Actions](design/actions.md) - [Commitments](design/commitments.md) - [Commitment tree](design/commitment-tree.md) diff --git a/book/src/design.md b/book/src/design.md index de393ccf..e462ab65 100644 --- a/book/src/design.md +++ b/book/src/design.md @@ -20,21 +20,6 @@ - Need to consider the privacy issue related to light clients requesting individual 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 - TODO: UDAs: arbitrary vs whitelisted diff --git a/book/src/design/keys.md b/book/src/design/keys.md new file mode 100644 index 00000000..e9d8700b --- /dev/null +++ b/book/src/design/keys.md @@ -0,0 +1,86 @@ +# 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. This involves corresponding +changes to the key derivation process (such as using Sinsemilla for Pallas-efficient +commitments). + +We also 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. For example, diversifiers remain at 11 bytes, so that Orchard addresses are +the same length as Sapling addresses. + +## 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, due to +addresses not being 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 +wallet scanning. But for users that 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 that ZIP 32. All derivations produce an opaque binary spending key, from which the +keys and addresses are then derived. + +[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 From d5412615076de8591a42c75922de453a70db6f09 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 12 Feb 2021 08:09:45 +1300 Subject: [PATCH 2/2] Apply suggestions from review Co-authored-by: Daira Hopwood --- book/src/design/keys.md | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/book/src/design/keys.md b/book/src/design/keys.md index e9d8700b..00b338d4 100644 --- a/book/src/design/keys.md +++ b/book/src/design/keys.md @@ -2,11 +2,15 @@ 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. This involves corresponding -changes to the key derivation process (such as using Sinsemilla for Pallas-efficient -commitments). +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.) -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 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. 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 -the same length as Sapling 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 @@ -60,10 +68,10 @@ is HD wallets for transparent addresses, which use the following structure defin - (N) Change address 1... - (H) Account 1... -Shielded accounts do not require separating change addresses from normal addresses, due to -addresses not being 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 -wallet scanning. But for users that do want to generate multiple addresses per account, +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 @@ -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. 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 -keys and addresses are then derived. +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