Merge pull request #17 from zcash/book-keys-addresses

book: Document design rationale for Orchard keys and addresses

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)

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

book/src/design/keys.md

@@ -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