diff --git a/zip-0032.html b/zip-0032.html
index 16efaece..8bb4bbed 100644
--- a/zip-0032.html
+++ b/zip-0032.html
@@ -297,6 +297,15 @@ License: MIT
\(m_\mathsf{Sapling}\)
.
+
Note that the master extended key is invalid if
+ \(\mathsf{ask}_m\)
+ is
+ \(0\)
+ , or if the corresponding
+ \(\mathsf{ivk}\)
+ derived as specified in 11 is
+ \(0\)
+ .
Sapling child key derivation
As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index
@@ -325,7 +334,7 @@ License: MIT
\((\mathsf{nk}_{par}, \mathsf{ak}_{par}, \mathsf{ovk}_{par})\)
is the full viewing key derived from
\((\mathsf{ask}_{par}, \mathsf{nsk}_{par}, \mathsf{ovk}_{par})\)
- as described in 11.
+ as described in 11.
Split
@@ -363,13 +372,22 @@ License: MIT
+
Note that the child extended key is invalid if
+ \(\mathsf{ask}_i\)
+ is
+ \(0\)
+ , or if the corresponding
+ \(\mathsf{ivk}\)
+ derived as specified in 11 is
+ \(0\)
+ .
Deriving a child extended full viewing key
Let
\(\mathcal{G}^\mathsf{Sapling}\)
- be as defined in 14 and let
+ be as defined in 14 and let
\(\mathcal{H}^\mathsf{Sapling}\)
- be as defined in 11.
Note that the child extended key is invalid if
+ \(\mathsf{ak}_i\)
+ is the zero point of Jubjub, or if the corresponding
+ \(\mathsf{ivk}\)
+ derived as specified in 11 is
+ \(0\)
+ .
Sapling internal key derivation
-
The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree 5, for any external full viewing key we only 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.
+
The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree 5, for any external full viewing key we only 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.
Deriving a Sapling internal spending key
Let
\((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})\)
@@ -435,7 +460,7 @@ License: MIT
\(\mathsf{ak}\)
and
\(\mathsf{nk}\)
- as specified in 11.
+ as specified in 11.
Let
\(I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingInt"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk}))\)
.
Note that the child extended key is invalid if
+ \(\mathsf{ak}\)
+ is the zero point of Jubjub, or if the corresponding
+ \(\mathsf{ivk}\)
+ derived as specified in 11 is
+ \(0\)
+ .
Deriving a Sapling internal full viewing key
Let
\(\mathcal{H}^\mathsf{Sapling}\)
- be as defined in 11.
Let
\((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)
be the external full viewing key.
@@ -506,7 +538,14 @@ License: MIT
Diagram of Sapling internal key derivation
(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 8.
+
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
+ \(0\)
+ .
Sapling diversifier derivation
@@ -616,6 +655,7 @@ License: MIT
\(\mathsf{c}_i\)
.
+
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.
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.
@@ -623,7 +663,10 @@ License: MIT
\(\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 12.
+
Define
+ \(\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)
+ as follows:
Let
\(K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)
@@ -631,12 +674,15 @@ License: MIT
Let
\(\mathsf{rivk_{internal}} = \mathsf{ToScalar^{Orchard}}(\mathsf{PRF^{expand}}(K, [\mathtt{0x83}] \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{ak}) \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{nk}))\)
.
The result of applying
+ \(\mathsf{DeriveInternalFVK^{Orchard}}\)
+ to the external full viewing key is the internal full viewing key. The corresponding expanded internal spending key is
\((\mathsf{ask}, \mathsf{nk}, \mathsf{rivk_{internal}})\)
- , and the internal full viewing key is
- \((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk_{internal}})\)
- .
+ ,
Unlike Sapling internal key derivation, we do not base this internal key derivation procedure on non-hardened derivation, which is not defined for Orchard. We can obtain the desired separation of viewing authority by modifying only the
\(\mathsf{rivk_{internal}}\)
field relative to the external full viewing key, which results in different
@@ -645,12 +691,13 @@ License: MIT
\(\mathsf{ivk_{internal}}\)
and
\(\mathsf{ovk_{internal}}\)
- fields being derived, as specified in 12 and shown in the following diagram:
+ fields being derived, as specified in 12 and shown in the following diagram:
Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key
-
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 8.
+
Note that the resulting FVK may be invalid, as specified in 12.
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.
@@ -691,7 +738,7 @@ License: MIT
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:
@@ -704,7 +751,7 @@ License: MIT
) 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\)
@@ -713,7 +760,7 @@ License: MIT
\(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\)
@@ -735,7 +782,7 @@ License: MIT
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:
\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\)
@@ -804,7 +851,7 @@ License: MIT
Specification: Key Encodings
-
The following encodings are analogous to the xprv and xpub encodings 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 xprv and xpub encodings 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})\)
@@ -896,7 +943,7 @@ License: MIT
\(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 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 21.
Values reserved due to previous specification for Sprout
diff --git a/zip-0032.rst b/zip-0032.rst
index faf058b6..9f49e441 100644
--- a/zip-0032.rst
+++ b/zip-0032.rst
@@ -202,6 +202,9 @@ Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least
- Return :math:`(\mathsf{ask}_m, \mathsf{nsk}_m, \mathsf{ovk}_m, \mathsf{dk}_m, \mathsf{c}_m)` as the
master extended spending key :math:`m_\mathsf{Sapling}`.
+Note that the master extended key is invalid if :math:`\mathsf{ask}_m` is :math:`0`, or if the corresponding
+:math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
+
Sapling child key derivation
----------------------------
@@ -233,6 +236,9 @@ Deriving a child extended spending key
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
- :math:`\mathsf{c}_i = I_R`.
+Note that the child extended key is invalid if :math:`\mathsf{ask}_i` is :math:`0`, or if the corresponding
+:math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
+
Deriving a child extended full viewing key
``````````````````````````````````````````
@@ -258,6 +264,10 @@ let :math:`\mathcal{H}^\mathsf{Sapling}` be as defined in [#protocol-saplingkeyc
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(I_L, [\texttt{0x16}]`:math:`||\,\mathsf{dk}_{par}))`
- :math:`\mathsf{c}_i = I_R`.
+Note that the child extended key is invalid if :math:`\mathsf{ak}_i` is the zero point of Jubjub,
+or if the corresponding :math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_
+is :math:`0`.
+
Sapling internal key derivation
-------------------------------
@@ -283,6 +293,10 @@ Let :math:`(\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})` be the exter
- Split :math:`R` into two 32-byte sequences, :math:`\mathsf{dk_{internal}}` and :math:`\mathsf{ovk_{internal}}`.
- Return the internal spending key as :math:`(\mathsf{ask}, \mathsf{nsk_{internal}}, \mathsf{ovk_{internal}}, \mathsf{dk_{internal}})`.
+Note that the child extended key is invalid if :math:`\mathsf{ak}` is the zero point of Jubjub,
+or if the corresponding :math:`\mathsf{ivk}` derived as specified in [#protocol-saplingkeycomponents]_
+is :math:`0`.
+
Deriving a Sapling internal full viewing key
````````````````````````````````````````````
@@ -317,6 +331,11 @@ are shown in the following diagram:
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 [#zip-0316]_.
+Note that the internal extended key is invalid if :math:`\mathsf{ak}` is the zero point of Jubjub,
+or if the corresponding :math:`\mathsf{ivk_{internal}}` derived from the internal full viewing key
+as specified in [#protocol-saplingkeycomponents]_ is :math:`0`.
+
+
Sapling diversifier derivation
------------------------------
@@ -377,6 +396,10 @@ Orchard child key derivation
- Use :math:`I_L` as the child spending key :math:`\mathsf{sk}_{i}`.
- Use :math:`I_R` as the child chain code :math:`\mathsf{c}_i`.
+Note that the resulting child spending key may produce an invalid external FVK, as specified
+in [#protocol-orchardkeycomponents]_, 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
-------------------------------
@@ -390,11 +413,16 @@ Let :math:`\mathsf{ask}` be the spend authorizing key if available, and
let :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})` be the corresponding external full
viewing key, obtained as specified in [#protocol-orchardkeycomponents]_.
+Define :math:`\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})`
+as follows:
+
- Let :math:`K = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})`.
- Let :math:`\mathsf{rivk_{internal}} = \mathsf{ToScalar^{Orchard}}(\mathsf{PRF^{expand}}(K, [\mathtt{0x83}] \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{ak}) \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{nk}))`.
+- Return :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk_{internal}})`.
-Then the expanded internal spending key is :math:`(\mathsf{ask}, \mathsf{nk}, \mathsf{rivk_{internal}})`,
-and the internal full viewing key is :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk_{internal}})`.
+The result of applying :math:`\mathsf{DeriveInternalFVK^{Orchard}}` to the external full viewing
+key is the internal full viewing key. The corresponding expanded internal spending key is
+:math:`(\mathsf{ask}, \mathsf{nk}, \mathsf{rivk_{internal}})`,
Unlike `Sapling internal key derivation`_, we do not base this internal key derivation
procedure on non-hardened derivation, which is not defined for Orchard. We can obtain the
@@ -414,6 +442,8 @@ diagram:
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 [#zip-0316]_.
+Note that the resulting FVK may be invalid, as specified in [#protocol-orchardkeycomponents]_.
+
Orchard diversifier derivation
------------------------------
diff --git a/zip-0203.html b/zip-0203.html
index cb4e24e1..bd72617f 100644
--- a/zip-0203.html
+++ b/zip-0203.html
@@ -34,7 +34,8 @@ License: MIT
Specification
Transactions will have a new field, nExpiryHeight, which will set the block height after which transactions will be removed from the mempool if they have not been mined.
-
The data type for nExpiryHeight will be uint32_t. If used in combination with nLockTime, both nLockTime and nExpiryHeight must be block heights. nExpiryHeight will never be a UNIX timestamp, unlike nLockTime values, and thus the maximum expiry height will be 499999999 (but see the exception for coinbase transactions described in Changes for NU5).
+
The data type for nExpiryHeight will be uint32_t. nExpiryHeight will never be a UNIX timestamp, unlike nLockTime values, and thus the maximum expiry height will be 499999999 (but see the exception for coinbase transactions described in Changes for NU5).
+
Note: a previous version of this ZIP incorrectly specified an interaction between nExpiryHeight and nLockTime that was never implemented.
For the example below, the last block that the transaction below could possibly be included in is 3539. After that, it will be removed from the mempool.
"txid": "17561b98cc77cd5a984bb959203e073b5f33cf14cbce90eb32b95ae2c796723f",
"version": 3,
diff --git a/zip-0203.rst b/zip-0203.rst
index cb564429..8af6a78b 100644
--- a/zip-0203.rst
+++ b/zip-0203.rst
@@ -46,11 +46,13 @@ Specification
Transactions will have a new field, ``nExpiryHeight``, which will set the block height
after which transactions will be removed from the mempool if they have not been mined.
-The data type for ``nExpiryHeight`` will be ``uint32_t``. If used in combination with
-``nLockTime``, both ``nLockTime`` and ``nExpiryHeight`` must be block heights.
-``nExpiryHeight`` will never be a UNIX timestamp, unlike ``nLockTime`` values, and thus
-the maximum expiry height will be 499999999 (but see the exception for coinbase
-transactions described in `Changes for NU5`_).
+The data type for ``nExpiryHeight`` will be ``uint32_t``. ``nExpiryHeight`` will never
+be a UNIX timestamp, unlike ``nLockTime`` values, and thus the maximum expiry height
+will be 499999999 (but see the exception for coinbase transactions described in
+`Changes for NU5`_).
+
+Note: a previous version of this ZIP incorrectly specified an interaction between
+``nExpiryHeight`` and ``nLockTime`` that was never implemented.
For the example below, the last block that the transaction below could possibly be
included in is 3539. After that, it will be removed from the mempool.
