From adb377de7da8f9cf137ca2e773bcc2deea0e1667 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 8 Feb 2021 18:27:50 +0000 Subject: [PATCH] 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