Draft ZIPs 
These are works-in-progress that have been assigned ZIP numbers. These will eventually become either Proposed (and thus Released), or one of Withdrawn, Rejected, or Obsolete.
@@ -111,9 +111,9 @@Terminology
The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
-"Jubjub" refers to the elliptic curve defined in 15.
+"Jubjub" refers to the elliptic curve defined in 14.
+A "cryptovalue" is a high-entropy value used in a cryptographic protocol that is not necessarily a key.
A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.
-The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 10.
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 9.
Abstract
This proposal defines a mechanism for extending hierarchical deterministic wallets, as described in BIP 32 2, to support Zcash's shielded addresses.
@@ -54,7 +55,7 @@At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.
Conventions
- Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification 9. They are reproduced here for convenience:
+Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification 8. They are reproduced here for convenience:
- \(\mathsf{truncate}_k(S)\) @@ -106,7 +107,7 @@ \(\mathsf{repr}_\mathbb{J}(P)\) is the representation of the Jubjub elliptic curve point \(P\) - as a bit sequence, defined in 15. + as a bit sequence, defined in 14.
- \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\) refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string @@ -146,9 +147,9 @@ \(d\) to a base point on the Jubjub elliptic curve, or to \(\bot\) - if the diversifier is invalid. It is instantiated in 13. + if the diversifier is invalid. It is instantiated in 12.
The following algorithm standardized in 22 is used:
+The following algorithm standardized in 21 is used:
- \(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\) @@ -195,6 +196,11 @@ \(m_\mathsf{Sapling} / a / b / c\!\) .
Note: no corresponding notation is currently defined for the result of Hardened-only child key derivation with non-zero + \(\mathsf{lead}\) + and/or non-empty + \(\mathsf{tag}\!\) + .
Specification: Sapling key derivation
Sapling extended keys
@@ -271,7 +277,7 @@
\(\mathsf{nsk}_m\!\)
, and
\(\mathsf{ovk}_m\)
- via the standard Sapling derivation 11:
+ via the standard Sapling derivation 10:
Deriving a child extended full viewing key
Let \(\mathcal{G}^\mathsf{Sapling}\) - be as defined in 14 and let + be as defined in 13 and let \(\mathcal{H}^\mathsf{Sapling}\) - be as defined in 11.
+ be as defined in 10.\(\mathsf{CKDfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})\) @@ -446,7 +452,7 @@ \(\mathsf{ak}_i\) is the zero point of Jubjub, or if the corresponding \(\mathsf{ivk}\) - derived as specified in 11 is + derived as specified in 10 is \(0\!\) .
Deriving a Sapling internal full viewing key
Let \(\mathcal{H}^\mathsf{Sapling}\) - be as defined in 11.
+ be as defined in 10.Let \((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\) be the external full viewing key.
@@ -540,12 +546,12 @@(For simplicity, the proof authorizing key is not shown.)
-This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 8.
+This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 23.
Note that the internal extended key is invalid if \(\mathsf{ak}\) is the zero point of Jubjub, or if the corresponding \(\mathsf{ivk_{internal}}\) - derived from the internal full viewing key as specified in 11 is + derived from the internal full viewing key as specified in 10 is \(0\!\) .
Specification: Hardened-only key derivation
The derivation mechanism for Sapling addresses specified above incurs significant complexity to support non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for non-hardened derivation appear. With that in mind, we now have a general hardened-only derivation process that retains compatibility with existing derivation path semantics (to enable deriving the same path across multiple contexts).
+The functions defined in this section are intended for internal use by context-specific mechanisms in subsequent sections, rather than for direct use.
Instantiation
Let \(\mathsf{Context}\) @@ -631,21 +638,29 @@
Hardened-only child key derivation
+ As well as the integer child index + \(i\!\) + , the child key derivation function defined here supports a lead byte + \(\mathsf{lead}\) + (used for domain separation) and byte sequence + \(\mathsf{tag}\!\) + . Each triple + \((i, \mathsf{lead}, \mathsf{tag})\) + produces an independent output.
- \(\mathsf{CKDh}^\mathsf{Context}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\) - \(\rightarrow (\mathsf{sk}_i, \mathsf{c}_i)\) + \(\mathsf{CKDh}^\mathsf{Context}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i, \mathsf{lead}, \mathsf{tag})\) + \(\rightarrow (\mathsf{sk}_{child}, \mathsf{c}_{child})\) :
-
-
- 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}, [\mathsf{Context.CKDDomain}]\,||\,\mathsf{sk}_{par}\,||\,\mathsf{I2LEOSP}_{32}(i))\!\) - . -
- If not (normal child): return failure. -
- If + \(i < 2^{31}\) + (non-hardened child index): return failure. +
- Let + \(\mathsf{lead\_enc} = \begin{cases} \,[\,],&\!\!\textsf{if } \mathsf{lead} = 0 \textsf{ and } \mathsf{tag} = [\,] \\ \,[\mathsf{lead}],&\!\!\textsf{otherwise.}\end{cases}\) +
- Let + \(I = \mathsf{PRF^{expand}}(\mathsf{c}_{par}, [\mathsf{Context.CKDDomain}]\,||\,\mathsf{sk}_{par}\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{lead\_enc}\,||\,\mathsf{tag})\!\) + .
- Split \(I\) into two 32-byte sequences, @@ -653,20 +668,23 @@ and \(I_R\!\) . -
- Use - \(I_L\) - as the child secret key - \(\mathsf{sk}_i\!\) - . -
- Use - \(I_R\) - as the child chain code - \(\mathsf{c}_i\!\) - .
- Return - \((\mathsf{sk}_i, \mathsf{c}_i)\!\) + \((I_L, I_R)\!\) .
Note that in the input to + \(\mathsf{PRF^{expand}}\!\) + , the case + \(\mathsf{lead} = 0\) + and + \(\mathsf{tag} = [\,]\) + is encoded in a way compatible with the definition of + \(\mathsf{CKDh}\) + in previous versions of this specification (before + \(\mathsf{lead}\) + and + \(\mathsf{tag}\) + were added).
Specification: Orchard key derivation
@@ -707,10 +725,10 @@
:
- Return - \(\mathsf{CKDh}^\mathsf{Orchard}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\) + \(\mathsf{CKDh}^\mathsf{Orchard}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i, 0, [\,])\)
Note that the resulting child spending key may produce an invalid external FVK, as specified in 12, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.
+Note that the resulting child spending key may produce an invalid external FVK, as specified in 11, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.
Orchard internal key derivation
As in the case of Sapling, for a given external address, we want to produce another address for use by wallets for internal operations such as change and auto-shielding. That is, for any external full viewing key we need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.
@@ -718,7 +736,7 @@ \(\mathsf{ask}\) be the spend authorizing key if available, and let \((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\) - be the corresponding external full viewing key, obtained as specified in 12. + be the corresponding external full viewing key, obtained as specified in 11.Define \(\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\) as follows:
@@ -727,7 +745,7 @@ \(K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\!\) .
This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 8.
-Note that the resulting FVK may be invalid, as specified in 12.
+This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 23.
+Note that the resulting FVK may be invalid, as specified in 11.
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.
@@ -790,54 +808,134 @@Specification: Arbitrary key derivation
- In some contexts there is a need for deriving arbitrary keys with the same derivation path as existing key material (for example, deriving an arbitrary account-level key), without the need for ecosystem-wide coordination. The following instantiation of the hardened key generation process may be used for this purpose.
+Specification: Registered key derivation
+ In the context of a particular application protocol defined by a ZIP, there is sometimes a need to define an HD subtree that will not collide with keys derived for other protocols, as far as that is possible to assure by following the ZIP process 22.
+Within this subtree, the application protocol may use derivation paths related to those used for existing key material — for example, to derive an account-level key. The following instantiation of the hardened key generation process may be used for this purpose.
+It is strongly RECOMMENDED that implementors ensure that documentation of the context string(s), and the usage and derivation paths of the application protocol's key tree in the corresponding ZIP are substantially complete, before public deployment of software or hardware using this mechanism. The ZIP process allows for subsequent updates and corrections.
Let \(\mathsf{ContextString}\) be a globally-unique non-empty sequence of at most 252 bytes that identifies the desired context.
We instantiate the hardened key generation process with the following constants:
- - \(\mathsf{Arbitrary.MKGDomain} = \texttt{“ZcashArbitraryKD”}\) + \(\mathsf{Registered.MKGDomain} = \texttt{“ZIPRegistered\_KD”}\) + +
- + \(\mathsf{Registered.CKDDomain} = \mathtt{0xAC}\) + +
Registered subtree root key generation
+ Let + \(S\) + be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
+The registered subtree root is obtained as:
++ \(\mathsf{RegKD}(\mathsf{ContextString}, \mathsf{S}, \mathsf{ZipNumber})\) + \(\rightarrow (\mathsf{sk}_{subtree}, \mathsf{c}_{subtree})\) + :
+-
+
- Let + \((\mathsf{sk}_{m}, \mathsf{c}_{m}) = \mathsf{MKGh}^\mathsf{Registered}([\mathsf{length}(\mathsf{ContextString})]\,||\,\mathsf{ContextString}\,||\,[\mathsf{length}(S)]\,||\,S)\!\) + . +
- Return + \(\mathsf{CKDh}^\mathsf{Registered}((\mathsf{sk}_{m}, \mathsf{c}_{m}), \mathsf{ZipNumber} + 2^{31}, 0, [\,])\!\) + . +
Note: The intermediate key + \((\mathsf{sk}_{m}, \mathsf{c}_{m})\) + would grant the ability to derive the subtree root for application protocols defined in any ZIP using the same + \(\mathsf{ContextString}\) + and seed. This is a potentially dangerous scope of grant since it cannot be known what future protocols will use this mechanism; therefore, + \((\mathsf{sk}_{m}, \mathsf{c}_{m})\) + SHOULD NOT be used or stored directly without careful consideration of security consequences.
+Registered child key derivation
+ As well as the integer child index + \(i\!\) + , the child key derivation function defined here supports a byte sequence + \(\mathsf{tag}\!\) + ; each pair + \((i, \mathsf{tag})\) + produces a different child key. If an explicit tag is not required, + \(\mathsf{tag}\) + is set to the empty byte sequence.
+Note: The tag MUST use an unambiguous encoding within the given context. It is RECOMMENDED to use a prefix-free encoding, which may require the use of length fields if multiple fields need to be encoded.
++ \(\mathsf{CKDreg}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i, \mathsf{tag})\) + \(\rightarrow (\mathsf{sk}_{child}, \mathsf{c}_{child})\) + :
+-
+
- Return + \(\mathsf{CKDh}^\mathsf{Registered}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i, 0, \mathsf{tag})\!\) + . +
Full-width child cryptovalue derivation
+ If the application protocol requires a 64-byte cryptovalue (for example, to avoid an entropy bottleneck in its subsequent operations), then a similar process to Registered child key derivation above can be used to obtain such a cryptovalue at a given child index; again with optional tag. The same considerations about encoding of the + \(\mathsf{tag}\) + apply as above.
++ \(\mathsf{derive\_child\_cryptovalue}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i, \mathsf{tag})\) + \(\rightarrow \mathsf{K}_{child}\) + :
+-
+
- Let + \((I_L, I_R) = \mathsf{CKDh}^\mathsf{Registered}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i, 1, \mathsf{tag})\!\) + . +
- Return + \(I_L\,||\,I_R\!\) + . +
For the avoidance of doubt, the output of + \(\mathsf{derive\_child\_cryptovalue}\) + MUST NOT be provided as input to any key derivation function defined in ZIP 32. In particular, it MUST NOT be reinterpreted directly or indirectly as an input to + \(\mathsf{CKDh}\!\) + .
+Specification: Ad-hoc key derivation (deprecated)
+ For compatibility with existing deployments, we also define a mechanism to derive ad-hoc key trees for private use by applications, without ecosystem coordination. This was called "arbitrary key derivation" in previous iterations of this ZIP, but that term caused confusion as to the applicability of the mechanism.
+Since there is no guarantee of non-collision between different application protocols, and no way to tie these key trees to well-defined specification or documentation processes, use of this mechanism is NOT RECOMMENDED for new protocols.
+Let + \(\mathsf{ContextString}\) + be a globally-unique non-empty sequence of at most 252 bytes that identifies the desired context.
+We instantiate the hardened key derivation process with the following constants:
+-
+
- + \(\mathsf{Adhoc.MKGDomain} = \texttt{“ZcashArbitraryKD”}\)
- - \(\mathsf{Arbitrary.CKDDomain} = \mathtt{0xAB}\) + \(\mathsf{Adhoc.CKDDomain} = \mathtt{0xAB}\)
Arbitrary master key generation
+ Ad-hoc master key generation (deprecated)
Let \(S\) be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
-The master extended arbitrary key is:
+The master extended ad-hoc key is:
- \(m_\mathsf{Arbitrary} = \mathsf{MKGh}^\mathsf{Arbitrary}([\mathsf{length}(\mathsf{ContextString})]\,||\,\mathsf{ContextString}\,||\,[\mathsf{length}(S)]\,||\,S)\!\) + \(m_\mathsf{Adhoc} = \mathsf{MKGh}^\mathsf{Adhoc}([\mathsf{length}(\mathsf{ContextString})]\,||\,\mathsf{ContextString}\,||\,[\mathsf{length}(S)]\,||\,S)\!\) .
Arbitrary child key derivation
+ Ad-hoc child key derivation (deprecated)
\(\mathsf{CKDarb}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{sk}_i, \mathsf{c}_i)\) :
- Return - \(\mathsf{CKDh}^\mathsf{Arbitrary}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)\!\) + \(\mathsf{CKDh}^\mathsf{Adhoc}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i, 0, [\,])\!\) .
If the context requires a 64-byte key (for example, to avoid an entropy bottleneck in its particular subsequent operations), and +
Note: a previous iteration of this ZIP suggested that, if \(i\) - is the last element of an HD path, the concatenation + is the last element of an HD path (i.e. no extension of this path is used), then the concatenation \(\mathsf{sk}_i\,||\,\mathsf{c}_i\) - MAY be used as a key. In this case, - \((\mathsf{sk}_i, \mathsf{c}_i)\) - MUST NOT be given as input to - \(\mathsf{CKDarb}\) - (this is a restatement of the requirement that - \(i\) - is the last element of an HD path).
+ could be used as a 64-bit key. This is NOT RECOMMENDED, because it is difficult to define safe APIs that enforce the restriction that a given node in the key tree must not be used both in this way and to derive further child keys. Full-width child cryptovalue derivation provides a safe way to obtain the same functionality for new application protocols.Specification: Wallet usage
- Existing Zcash-supporting HD wallets all use BIP 44 5 to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.
+Existing Zcash-supporting HD wallets all use BIP 44 5 to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.
Key path levels
Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:
-
@@ -850,7 +948,7 @@
) 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 cryptocurrency 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 cryptocurrency testnets share + : a constant identifying the cryptocurrency 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 cryptocurrency testnets share \(coin\_type\) index \(1\!\) @@ -859,7 +957,7 @@ \(account\!\) : numbered from index \(0\) - in sequentially increasing manner. Defined as in BIP 44 5. + in sequentially increasing manner. Defined as in BIP 44 5.
Unlike BIP 44, none of the shielded key paths have a \(change\) @@ -881,7 +979,7 @@ 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:
+ path level as in 5:-
\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\!\)
@@ -913,7 +1011,7 @@
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 18) is given by:
+ (as specified in 17) is given by:-
\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\!\)
@@ -925,7 +1023,7 @@
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 20) is given by:
+ (as specified in 19) is given by:- \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\!\) @@ -950,7 +1048,7 @@
Specification: Key Encodings
-The following encodings are analogous to the
+xprvandxpubencodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 7 encoding.The following encodings are analogous to the
xprvandxpubencodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 7 encoding.Sapling extended spending keys
A Sapling extended spending key \((\mathsf{ask, nsk, ovk, dk, c})\!\) @@ -1042,7 +1140,7 @@ \(0\!\) .
When encoded as Bech32, the Human-Readable Part is
-secret-orchard-extsk-mainfor Mainnet, orsecret-orchard-extsk-testfor 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 21.
+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 20.
Values reserved due to previous specification for Sprout
@@ -1067,7 +1165,7 @@ -
\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\!\)
@@ -925,7 +1023,7 @@
Test Vectors
- TBC
+Test vectors are available at <https://github.com/zcash/zcash-test-vectors> in the sapling_zip32, sapling_zip32_hard, orchard_zip32, zip_0032_registered, and zip_0032_arbitrary files for each format.
Reference Implementation
-
@@ -1134,18 +1232,10 @@
| 8 | -ZIP 316: Unified Addresses and Unified Viewing Keys | -
|---|