Sapling extended keys

BIP 32 defines a method to derive a number of child keys from a parent key. In order to prevent these from depending solely on the parent key itself, both the private and public keys are extended with a 32-byte chain code. We similarly extend Sapling keys with a chain code here. However, the concepts of "private" and "public" keys in BIP 32 do not map cleanly to Sapling's key components. We take the following approach:

• We derive child Sapling expanded spending keys, rather than Sapling spending keys. This enables us to implement both hardened and non-hardened derivation modes (the latter being incompatible with Sapling spending keys).
• We do not derive Sapling public keys directly, as this would prevent the use of diversified addresses. Instead, we derive Sapling full viewing keys, from which payment addresses can be generated. This maintains the trust semantics of BIP 32: someone with access to a BIP 32 extended public key is able to view all transactions involving that address, which a Sapling full viewing key also enables.

We represent a Sapling extended spending key as \((\mathsf{ask, nsk, ovk, dk, c})\) , where \((\mathsf{ask, nsk, ovk})\) is the normal Sapling expanded spending key, \(\mathsf{dk}\) is a diversifier key, and \(\mathsf{c}\) is the chain code.

We represent a Sapling extended full viewing key as \((\mathsf{ak, nk, ovk, dk, c})\) , where \((\mathsf{ak, nk, ovk})\) is the normal Sapling full viewing key, \(\mathsf{dk}\) is the same diversifier key as above, and \(\mathsf{c}\) is the chain code.

Sapling helper functions

Define

• \(\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk}) :=\) \(\mathsf{I2LEOSP}_{256}(\mathsf{ask})\) \(||\,\mathsf{I2LEOSP}_{256}(\mathsf{nsk})\) \(||\,\mathsf{ovk}\) \(||\,\mathsf{dk}\)
• \(\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}) :=\) \(\mathsf{LEBS2OS}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{ak}))\) \(||\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_\mathbb{J}(\mathsf{nk}))\) \(||\,\mathsf{ovk}\) \(||\,\mathsf{dk}\)

Sapling master key generation

Let \(S\) be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.

• Calculate \(I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Sapling”}, S)\) .
• Split \(I\) into two 32-byte sequences, \(I_L\) and \(I_R\) .
• Use \(I_L\) as the master spending key \(\mathsf{sk}_m\) , and \(I_R\) as the master chain code \(\mathsf{c}_m\) .
• Calculate \(\mathsf{ask}_m\) , \(\mathsf{nsk}_m\) , and \(\mathsf{ovk}_m\) via the standard Sapling derivation 10:
  • \(\mathsf{ask}_m = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x00}]))\)
  • \(\mathsf{nsk}_m = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x01}]))\)
  • \(\mathsf{ovk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x02}]))\) .
• Calculate \(\mathsf{dk}_m\) similarly:
  • \(\mathsf{dk}_m = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{sk}_m, [\texttt{0x10}]))\) .
• Return \((\mathsf{ask}_m, \mathsf{nsk}_m, \mathsf{ovk}_m, \mathsf{dk}_m, \mathsf{c}_m)\) as the master extended spending key \(m_\mathsf{Sapling}\) .

Sapling child key derivation

As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index \(i\) , depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.

Sapling diversifier derivation

The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key \(\mathsf{dk}\) . To prevent the diversifier leaking how many diversified addresses have already been generated for an account, we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account. In order to reach the maximum possible diversifier range without running into repetitions due to the birthday bound, we use FF1-AES256 as a Pseudo-Random Permutation as follows:

• Let \(j\) be the index of the desired diversifier, in the range \(0\,.\!. 2^{88} - 1\) .
• \(d_j = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\) .

A valid diversifier \(d_j\) is one for which \(\mathsf{DiversifyHash}(d_j) \neq \bot\) . For a given \(\mathsf{dk}\) , approximately half of the possible values of \(j\) yield valid diversifiers.

The default diversifier for a Sapling extended key is defined to be \(d_j\) , where \(j\) is the least nonnegative integer yielding a valid diversifier.

Sprout extended keys

Due to the way Sprout keys are constructed and used, it is not possible to derive incoming viewing keys or payment addresses in parallel with spending keys. Nor is it possible to implement non-hardened derivation. We therefore only define and derive Sprout extended spending keys.

We represent a Sprout extended spending key as \((\mathsf{a_{sk}, c})\) , where \(\mathsf{a_{sk}}\) is the normal Sprout spending key, and \(\mathsf{c}\) is the chain code.

Sprout helper functions

Let \(\mathsf{EncodeASK}(\mathsf{a_{sk}})\) be the 32-byte encoding of \(\mathsf{a_{sk}}\) in the raw encoding of a Sprout spending key (excluding lead bytes) as specified in 15.

Let \(\mathsf{DecodeASK}(ASK)\) be the result of clearing the 4 most significant bits of the first byte of \(ASK\) , and decoding the 32-byte result according to the inverse of \(\mathsf{EncodeASK}\) .

Sprout master key generation

Let \(S\) be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.

• Calculate \(I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32_Sprout”}, S)\) .
• Split \(I\) into two 32-byte sequences, \(I_L\) and \(I_R\) .
• Use \(\mathsf{DecodeASK}(I_L)\) as the master spending key \(\mathsf{a}_{\mathsf{sk},m}\) .
• Use \(I_R\) as the master chain code \(\mathsf{c}_m\) .

Sprout child key derivation

\(\mathsf{CDKsk}((\mathsf{a}_{\mathsf{sk},par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{a}_{\mathsf{sk},i}, \mathsf{c}_i)\)

• Check whether \(i \geq 2^{31}\) (whether the child is a hardened key).
  • If so (hardened child): let \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x80}]\) \(||\,\mathsf{EncodeASK}(\mathsf{a}_{\mathsf{sk},par})\) \(||\,\mathsf{I2LEOSP}_{32}(i))\) .
  • If not (normal child): return failure.
• Split \(I\) into two 32-byte sequences, \(I_L\) and \(I_R\) .
• Use \(\mathsf{DecodeASK}(I_L)\) as the child spending key \(\mathsf{a}_{\mathsf{sk},i}\) .
• Use \(I_R\) as the child chain code \(\mathsf{c}_i\) .

Orchard extended keys

We represent an Orchard extended spending key as \((\mathsf{sk, c}),\) where \(\mathsf{sk}\) is the normal Orchard spending key (opaque 32 bytes), and \(\mathsf{c}\) is the chain code.

Orchard master key generation

Let \(S\) be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.

• Calculate \(I = \mathsf{BLAKE2b}\text{-}\mathsf{512}(\texttt{“ZcashIP32Orchard”}, S)\) .
• Split \(I\) into two 32-byte sequences, \(I_L\) and \(I_R\) .
• Use \(I_L\) as the master spending key \(\mathsf{sk}_m\) .
• Use \(I_R\) as the master chain code \(\mathsf{c}_m\) .
• Return \((\mathsf{sk}_m, \mathsf{c}_m)\) as the master extended spending key \(m_\mathsf{Orchard}\) .

Orchard child key derivation

\(\mathsf{CDKsk}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{sk}_{i}, \mathsf{c}_i)\)

• Check whether \(i \geq 2^{31}\) (whether the child is a hardened key).
  • If so (hardened child): let \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\texttt{0x81}]\,||\,\mathsf{sk}_{par}\,||\,\mathsf{I2LEOSP}_{32}(i))\) .
  • If not (normal child): return failure.
• Split \(I\) into two 32-byte sequences, \(I_L\) and \(I_R\) .
• Use \(I_L\) as the child spending key \(\mathsf{sk}_{i}\) .
• Use \(I_R\) as the child chain code \(\mathsf{c}_i\) .

Orchard diversifier derivation

As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending key. This means that the full viewing key provides the capability to determine the position of a diversifier within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the key structure.

Given an Orchard extended spending key \((\mathsf{sk}_i, \mathsf{c}_i)\) :

• Let \((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\) be the Orchard full viewing key for \(\mathsf{sk}_i\) .
• Let \(\mathsf{K} = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\) and let \(\mathsf{B} = \mathsf{repr}_{\mathbb{P}}(\mathsf{ak})\,||\,\mathsf{I2LEBSP}_{256}(\mathsf{nk})\) .
• \(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{K}, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(\mathsf{B})))\) .
• Let \(j\) be the index of the desired diversifier, in the range \(0\,.\!. 2^{88} - 1\) .
• \(d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))\) .

Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of \(j\) yield valid diversifiers.

The default diversifier for \((\mathsf{sk}_i, \mathsf{c}_i)\) is defined to be \(d_{i,0}.\)

Key path levels

Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:

• \(purpose\) : a constant set to \(32'\) (or \(\texttt{0x80000020}\) ) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.
• \(coin\_type\) : a constant identifying the cybercoin that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 6. Note that in keeping with that document, all cybercoin testnets share \(coin\_type\) index \(1\) .
• \(account\) : numbered from index \(0\) in sequentially increasing manner. Defined as in BIP 44 5.

Unlike BIP 44, none of the shielded key paths have a \(change\) path level. The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating external and internal address usage. Shielded addresses are never publicly visible in transactions, which means that sending change back to the originating address is indistinguishable from using a change address.

Sapling key path

Sapling provides a mechanism to allow the efficient creation of diversified payment addresses with the same spending authority. A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.

The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Sapling ZIP 32 derivation MUST support the following path for any account in range \(\{ 0\,.\!. 2^{31} - 1 \}\) :

• \(m_\mathsf{Sapling} / purpose' / coin\_type' / account'\) .

Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier as defined above) for any account they support. They MAY also support generating a stream of payment addresses for a given account, if they wish to maintain the user experience of giving a unique address to each recipient.

Note that a given account can have a maximum of approximately \(2^{87}\) payment addresses, because each diversifier has around a 50% chance of being invalid.

If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened \(address\_index\) path level as in 5:

• \(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\) .

Sprout key path

Wallets implementing Sprout ZIP 32 derivation MUST support the following path:

• \(m_\mathsf{Sprout} / purpose' / coin\_type' / account' / address\_index\) .

Orchard key path

Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.

The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard ZIP 32 derivation MUST support the following path for any account in range \(\{ 0\,.\!. 2^{31} - 1 \}\) :

• \(m_\mathsf{Orchard} / purpose' / coin\_type' / account'\) .

Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of diversified payment addresses for a given account, if they wish to enable users to give a unique address to each recipient.

Note that a given account can have a maximum of \(2^{88}\) payment addresses (unlike Sapling, all Orchard diversifiers are valid).

Sapling Full Viewing Key Fingerprints and Tags

A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding \(\mathit{FVK}\) (as specified in 16) is given by:

• \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\) .

It MAY be used to uniquely identify a particular Sapling full viewing key.

A "Sapling full viewing key tag" is the first 4 bytes of the corresponding Sapling full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.

Sprout Address Fingerprints and Tags

A "Sprout address fingerprint" of a Sprout payment address with raw encoding \(\mathit{ADDR}\) (as specified in 14, including the lead bytes) is given by:

• \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, \mathit{ADDR})\) .

It MAY be used to uniquely identify a particular Sprout payment address.

A "Sprout address tag" is the first 4 bytes of the corresponding Sprout address fingerprint. It is intended for optimizing performance of address lookups, and MUST NOT be assumed to uniquely identify a particular address.

Orchard Full Viewing Key Fingerprints and Tags

An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding \(\mathit{FVK}\) (as specified in 18) is given by:

• \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\) .

It MAY be used to uniquely identify a particular Orchard full viewing key.

An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.

Seed Fingerprints

A "seed fingerprint" for the master seed \(S\) of a hierarchical deterministic wallet is given by:

• \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_HD_Seed_FP”},\) \([\mathsf{length}(S)]\,||\,S)\) .

It MAY be used to uniquely identify a particular hierarchical deterministic wallet.

No corresponding short tag is defined.

Note: a previous version of this specification did not have the length byte prefixing the seed. The current specification reflects the implementation in zcashd.

Sapling extended spending keys

A Sapling extended spending key \((\mathsf{ask, nsk, ovk, dk, c})\) , at depth \(depth\) , with parent full viewing key tag \(parent\_fvk\_tag\) and child number \(i\) , is represented as a byte sequence:

• \(\mathsf{I2LEOSP}_{8}(depth)\) \(||\,parent\_fvk\_tag\) \(||\,\mathsf{I2LEOSP}_{32}(i)\) \(||\,\mathsf{c}\) \(||\,\mathsf{EncodeExtSKParts}(\mathsf{ask, nsk, ovk, dk})\) .

For the master extended spending key, \(depth\) is \(0\) , \(parent\_fvk\_tag\) is 4 zero bytes, and \(i\) is \(0\) .

When encoded as Bech32, the Human-Readable Part is secret-extended-key-main for the production network, or secret-extended-key-test for the test network.

Sapling extended full viewing keys

A Sapling extended full viewing key \((\mathsf{ak, nk, ovk, dk, c})\) , at depth \(depth\) , with parent full viewing key tag \(parent\_fvk\_tag\) and child number \(i\) , is represented as a byte sequence:

• \(\mathsf{I2LEOSP}_{8}(depth)\) \(||\,parent\_fvk\_tag\) \(||\,\mathsf{I2LEOSP}_{32}(i)\) \(||\,\mathsf{c}\) \(||\,\mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk})\) .

For the master extended full viewing key, \(depth\) is \(0\) , \(parent\_fvk\_tag\) is 4 zero bytes, and \(i\) is \(0\) .

When encoded as Bech32, the Human-Readable Part is zxviews for the production network, or zxviewtestsapling for the test network.

Sprout extended spending keys

A Sprout extended spending key \((\mathsf{a_{sk}, c})\) , at depth \(depth\) , with parent address tag \(parent\_addr\_tag\) and child number \(i\) , is represented as a byte sequence:

• \(\mathsf{I2LEOSP}_{8}(depth)\) \(||\,parent\_addr\_tag\) \(||\,\mathsf{I2LEOSP}_{32}(i)\) \(||\,\mathsf{c}\) \(||\,\mathsf{EncodeASK}(\mathsf{a_{sk}})\) .

For the master extended spending key, \(depth\) is \(0\) , \(parent\_addr\_tag\) is 4 zero bytes, and \(i\) is \(0\) .

When encoded as Bech32, the Human-Readable Part is zxsprout for the production network, or zxtestsprout for the test network. Sprout extended spending keys are encoded using Bech32 even though other Sprout keys and addresses are encoded using Base58Check.

Orchard extended spending keys

An Orchard extended spending key \((\mathsf{sk, c})\) , at depth \(depth\) , with parent full viewing key tag \(parent\_fvk\_tag\) and child number \(i\) , is represented as a byte sequence:

• \(\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{sk}\) .

For the master extended spending key, \(depth\) is \(0\) , \(parent\_fvk\_tag\) is 4 zero bytes, and \(i\) is \(0\) .

When encoded as Bech32, the Human-Readable Part is secret-orchard-extsk-main for Mainnet, or secret-orchard-extsk-test for Testnet.

We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users 19.