orchard/book/src/design/keys.md

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.