From 9dbe0a50f74c3516b00c0d2806c5f3b724768177 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 12 Oct 2021 19:10:03 +0100 Subject: [PATCH 01/19] ZIP 32: minor wording changes. Signed-off-by: Daira Hopwood --- zip-0032.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/zip-0032.rst b/zip-0032.rst index 0b579b6f..d644c273 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -62,8 +62,8 @@ advantages over random generation: from all future addresses. - Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures. -- View authority or spend authority can be delegated independently for sub-trees without compromising the - master seed. +- Viewing authority or spending authority can be delegated independently for sub-trees without compromising + the master seed. 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 @@ -401,9 +401,9 @@ hardened derivation: - :math:`purpose`: a constant set to :math:`32'` (or :math:`\texttt{0x80000020}`) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification. -- :math:`coin\_type`: a constant identifying the cybercoin that this subtree's keys are used with. For +- :math:`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 - [#slip-0044]_. Note that in keeping with that document, all cybercoin testnets share :math:`coin\_type` + [#slip-0044]_. Note that in keeping with that document, all cryptocurrency testnets share :math:`coin\_type` index :math:`1`. - :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in From 4d536ff421c25bf484d2ccae9f0c866d62bb4db2 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 12 Oct 2021 19:17:42 +0100 Subject: [PATCH 02/19] ZIP 32: Add a note saying how zcashd uses a non-hardened `address_index` path level for Sapling. Signed-off-by: Daira Hopwood --- zip-0032.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/zip-0032.rst b/zip-0032.rst index d644c273..522b3bc2 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -442,6 +442,9 @@ they MAY additionally support a non-hardened :math:`address\_index` path level a * :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index`. +`zcashd` version 4.5.2 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase +under account :math:`\mathtt{0x7FFFFFFE}`. + Sprout key path --------------- From 4d0477ce5fd7bd5fcc7312aa34b7a94267d0211b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 12 Oct 2021 23:23:57 +0100 Subject: [PATCH 03/19] ZIPs 32 and 316: refine how UIVK components are derived for Orchard and Transparent P2PKH. Signed-off-by: Daira Hopwood --- zip-0032.rst | 50 +++++++++++++++++++++++------------ zip-0316.rst | 74 +++++++++++++++++++++++++++++++++++++++++----------- 2 files changed, 93 insertions(+), 31 deletions(-) diff --git a/zip-0032.rst b/zip-0032.rst index 522b3bc2..08f5d0e8 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -384,6 +384,10 @@ valid diversifiers. The default diversifier for :math:`(\mathsf{sk}_i, \mathsf{c}_i)` is defined to be :math:`d_{i,0}.` +Although the diversifier *key* is derived from the full viewing key which is at the Account level, the +resulting diversified addresses are derived from the key at the non-change child of that level, as described +in `Orchard key path`_ below. + Specification: Wallet usage =========================== @@ -409,11 +413,18 @@ hardened derivation: - :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in BIP 44 [#bip-0044]_. -Unlike BIP 44, none of the shielded key paths have a :math:`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. +In BIP 44, there is also a :math:`change` unhardened path level as a child of :math:`account`. This +level is not present in the Sprout and Sapling key paths. It *is* present in Orchard, but as a hardened +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. For Sprout and Sapling, it +was reasoned that shielded addresses are never publicly visible in transactions, and so sending change +back to the originating address would be indistinguishable from using a change address. However, this +reasoning does not apply if we give out incoming viewing keys, and so for Orchard the :math:`change` +level has been reintroduced. This ensures that an Orchard incoming viewing key will only be able to view +incoming payments, not incoming change, which was deemed to be more useful for anticipated applications +of incoming viewing keys (such as a merchant terminal or a charity donation address). Sapling key path ---------------- @@ -455,20 +466,27 @@ Wallets implementing Sprout ZIP 32 derivation MUST support the following path: 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. +Orchard supports diversified addresses with the same spending authority (like Sapling). Unlike Sapling and +Sprout, we reintroduce the :math:`change'` level of the key path, so that the spending authorities generated +for incoming payments and for change are distinct. The motivation for this distinction is to allow giving +out an incoming viewing key that is only able to see incoming payments, and not incoming change. -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 :math:`\{ 0\,.\!. 2^{31} - 1 \}`: +A group of diversified addresses with the same spending authority 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. -* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account'`. +The key path levels include an account identifier, which in all user interfaces should be represented as +a "bucket of funds" under the control of a single spending authority. Wallets implementing Orchard ZIP 32 +derivation MUST support the following two paths for any account in range :math:`\{ 0\,.\!. 2^{31} - 1 \}`: -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. +* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account' / 0'` (for incoming payments); +* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account' / 1'` (for change). + +Furthermore, wallets MUST support generating a default payment address and a default change address (each +corresponding to the default diversifier for Orchard) for any account they support. They MAY also support +generating a stream of diversified payment addresses (based on the non-change key path) for a given account, +if they wish to enable users to give a unique address to each recipient. A single address using the default +diversifier SHOULD be used for change. Note that a given account can have a maximum of :math:`2^{88}` payment addresses (unlike Sapling, all Orchard diversifiers are valid). diff --git a/zip-0316.rst b/zip-0316.rst index d6654a44..f7ae2bf9 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -390,15 +390,22 @@ The following UFVK or UIVK Encodings are used in place of the * An Orchard UFVK or UIVK Encoding, with Typecode :math:`\mathtt{0x03},` is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming - Viewing Key respectively. + Viewing Key respectively. The UFVK uses the key at the Account level + of the ZIP 32 hierarchy, i.e. at path + :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account'`, + while the UIVK uses its non-change child key at path + :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`. * A Sapling UFVK Encoding, with Typecode :math:`\mathtt{0x02},` is the encoding of a Sapling Extended Full Viewing Key defined in - [#zip-0032-sapling-extfvk]_. + [#zip-0032-sapling-extfvk]_. This SHOULD be an Extended Full Viewing + Key at the Account level of the ZIP 32 hierarchy. * A Sapling UIVK Encoding, also with Typecode :math:`\mathtt{0x02},` is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by :math:`\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).` + Unlike Orchard, a Sapling UIVK is associated with the same spending + authority as the corresponding UFVK, i.e. also at the Account level. * There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be @@ -408,9 +415,14 @@ The following UFVK or UIVK Encodings are used in place of the * For Transparent P2PKH Addresses that are derived according to BIP 32 [#bip-0032]_ and BIP 44 [#bip-0044]_, the UFVK and UIVK Encodings - have Typecode :math:`\mathtt{0x00}.` These encodings are identical - and are the serialization of an extended public key, defined in the - section “Serialization format” of BIP 32 [#bip-0032-serialization-format]_. + have Typecode :math:`\mathtt{0x00}.` Both of these encodings are the + serialization of an extended public key, defined in the section + “Serialization format” of BIP 32 [#bip-0032-serialization-format]_. + However, the UFVK uses the key at the Account level, i.e. at path + :math:`m / 44' / coin\_type' / account'`, while the UIVK uses its + non-change child key at path :math:`m / 44' / coin\_type' / account' / 0`. + (In accordance with BIP 44 and differently to Orchard, the Change level + uses non-hardened derivation.) The Human-Readable Parts (as defined in [#bip-0350]_) of Unified Viewing Keys are defined as follows: @@ -437,8 +449,13 @@ Requirements for both Unified Addresses and Unified Viewing Keys all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.) -* Each Receiver, UFVK, or UIVK SHOULD represent an Address or - Viewing Key at the ZIP 32 or BIP 44 Account level. +* Each Receiver and UFVK SHOULD represent an Address or Full Viewing + Key at the ZIP 32 or BIP 44 Account level. + +* Each UIVK SHOULD represent an Incoming Viewing Key at the Account + level for Sapling, or its non-change child Incoming Viewing Key for + Orchard, or its non-change child extended public key for Transparent + P2PKH. * For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding. @@ -486,14 +503,29 @@ should be sufficient because experiments are expected to be reasonably short-term, and should otherwise be either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued. +New types SHOULD maintain the same distinction between UFVK and UIVK +authority as for Orchard, i.e. a UFVK is intended to give access to +view all transactions to and from the address, while an UIVK is intended +to give access only to view incoming payments (as opposed to change). + Deriving a UIVK from a UFVK --------------------------- -Each UIVK Encoding can straightforwardly be derived from the -corresponding UFVK Encoding, without changing the Typecode. In the -case of a Transparent P2PKH UFVK Encoding, the UIVK Encoding is the -same. +For a Sapling UFVK, the corresponding Sapling UIVK is obtained as +specified in [#protocol-saplingkeycomponents]_. + +For an Orchard UFVK, the corresponding Orchard UIVK is obtained by +deriving the child UFVK with non-hardened index :math:`0`, as specified +in [#zip-0032-orchard-child-key-derivation]_, and then the UIVK as +specified in [#protocol-orchardkeycomponents]_. + +For a Transparent P2PKH UFVK Encoding, the UIVK Encoding is obtained +from the extended public key corresponding to the account's non-change +key path, i.e. by deriving the child key with non-hardened index :math:`0`. +It is encoded in the same way as the UFVK Encoding. + +In each case, the Typecode remains the same as in the UFVK. Deriving a Unified Address from a UIVK @@ -511,6 +543,13 @@ UIVK. That is, There are no additional constraints on an Orchard diversifier index. +Note that Sapling Receiver addresses MUST be derived from the key path +at the Account level [#zip-0032-sapling-key-path]_, while Orchard Receiver +addresses MUST be derived from the non-change branch of the key path at +:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'` +[#zip-0032-orchard-key-path]_. This is to accommodate the use of a +distinct change spend authority in Orchard. + In the case of deriving a Transparent P2PKH Receiver from a Transparent P2PKH UIVK, the diversifier index is used as a BIP 44 child key index at the Index level to derive the address. As is usual for derivations @@ -768,13 +807,18 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal] `_ -.. [#protocol-notation] `Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal]. Section 2: Notation `_ -.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ -.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses `_ +.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.2.16 or later [NU5 proposal] `_ +.. [#protocol-notation] `Zcash Protocol Specification, Version 2020.2.16. Section 2: Notation `_ +.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2020.2.16. Section 4.2.2: Sapling Key Components `_ +.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2020.2.16. Section 4.2.3: Orchard Key Components `_ +.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.3.1: Sapling Payment Addresses `_ +.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.2: Orchard Raw Payment Addresses `_ .. [#zip-0000] `ZIP 0: ZIP Process `_ .. [#zip-0032-sapling-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys `_ .. [#zip-0032-sapling-diversifier-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation `_ +.. [#zip-0032-orchard-child-key-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation `_ +.. [#zip-0032-sapling-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path `_ +.. [#zip-0032-orchard-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path `_ .. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool `_ .. [#zip-0224] `ZIP 224: Orchard Shielded Protocol `_ .. [#zip-0321] `ZIP 321: Payment Request URIs `_ From b85a249a592b8c390ff311acc03d631733fb73ed Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 18 Oct 2021 20:01:57 +0100 Subject: [PATCH 04/19] ZIP 316: clarify how P2PKH addresses are derived. Signed-off-by: Daira Hopwood --- zip-0316.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index f7ae2bf9..1b8b4eb8 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -554,10 +554,11 @@ In the case of deriving a Transparent P2PKH Receiver from a Transparent P2PKH UIVK, the diversifier index is used as a BIP 44 child key index at the Index level to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation -[#bip-0032-public-to-public]_ MUST be used, with the Change element -of the path being 0, and the Index element of the path being the -diversifier index [#bip-0044-path-index]_. That is, the BIP 44 path of -the Transparent P2PKH Receiver MUST be: +[#bip-0032-public-to-public]_ MUST be used. The UIVK is assumed to +be the extended public key for the non-change element of the path, and +then the Index element of the path MUST be the diversifier index +[#bip-0044-path-index]_. That is, if the UIVK was constructed correctly +then the BIP 44 path of the Transparent P2PKH Receiver will be: * :math:`m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.` From 880bf02301639a8b56ca0905fd91c3dca2084cde Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 25 Oct 2021 20:10:43 +0100 Subject: [PATCH 05/19] Don't use UFVK or UIVK when referring to Viewing Key components. (A UFVK or UIVK is properly only the whole thing.) Signed-off-by: Daira Hopwood --- zip-0316.rst | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 1b8b4eb8..ddfbb07b 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -379,13 +379,13 @@ will normally take the union of information provided by all contained Receivers, and therefore the Priority List defined in the previous section is not used. -For each UFVK Type or UIVK Type currently defined in this specification, +For each FVK Type or IVK Type currently defined in this specification, the same Typecode is used as for the corresponding Receiver Type in a -Unified Address. Additional UFVK Types and UIVK Types MAY be defined in +Unified Address. Additional FVK Types and IVK Types MAY be defined in future, and these will not necessarily use the same Typecode as the corresponding Unified Address. -The following UFVK or UIVK Encodings are used in place of the +The following FVK or IVK Encodings are used in place of the :math:`\mathtt{addr}` field: * An Orchard UFVK or UIVK Encoding, with Typecode :math:`\mathtt{0x03},` @@ -396,16 +396,16 @@ The following UFVK or UIVK Encodings are used in place of the while the UIVK uses its non-change child key at path :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`. -* A Sapling UFVK Encoding, with Typecode :math:`\mathtt{0x02},` is +* A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is the encoding of a Sapling Extended Full Viewing Key defined in [#zip-0032-sapling-extfvk]_. This SHOULD be an Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy. -* A Sapling UIVK Encoding, also with Typecode :math:`\mathtt{0x02},` +* A Sapling IVK Encoding, also with Typecode :math:`\mathtt{0x02},` is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by :math:`\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).` - Unlike Orchard, a Sapling UIVK is associated with the same spending - authority as the corresponding UFVK, i.e. also at the Account level. + Unlike Orchard, a Sapling IVK is associated with the same spending + authority as the corresponding FVK, i.e. also at the Account level. * There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be @@ -414,12 +414,12 @@ The following UFVK or UIVK Encodings are used in place of the treated as unrecognized by Consumers. * For Transparent P2PKH Addresses that are derived according to BIP 32 - [#bip-0032]_ and BIP 44 [#bip-0044]_, the UFVK and UIVK Encodings + [#bip-0032]_ and BIP 44 [#bip-0044]_, the FVK and IVK Encodings have Typecode :math:`\mathtt{0x00}.` Both of these encodings are the serialization of an extended public key, defined in the section “Serialization format” of BIP 32 [#bip-0032-serialization-format]_. - However, the UFVK uses the key at the Account level, i.e. at path - :math:`m / 44' / coin\_type' / account'`, while the UIVK uses its + However, the FVK uses the key at the Account level, i.e. at path + :math:`m / 44' / coin\_type' / account'`, while the IVK uses its non-change child key at path :math:`m / 44' / coin\_type' / account' / 0`. (In accordance with BIP 44 and differently to Orchard, the Change level uses non-hardened derivation.) @@ -449,10 +449,10 @@ Requirements for both Unified Addresses and Unified Viewing Keys all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.) -* Each Receiver and UFVK SHOULD represent an Address or Full Viewing +* Each Receiver and FVK SHOULD represent an Address or Full Viewing Key at the ZIP 32 or BIP 44 Account level. -* Each UIVK SHOULD represent an Incoming Viewing Key at the Account +* Each IVK SHOULD represent an Incoming Viewing Key at the Account level for Sapling, or its non-change child Incoming Viewing Key for Orchard, or its non-change child extended public key for Transparent P2PKH. @@ -503,9 +503,9 @@ should be sufficient because experiments are expected to be reasonably short-term, and should otherwise be either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued. -New types SHOULD maintain the same distinction between UFVK and UIVK -authority as for Orchard, i.e. a UFVK is intended to give access to -view all transactions to and from the address, while an UIVK is intended +New types SHOULD maintain the same distinction between FVK and IVK +authority as for Orchard, i.e. an FVK is intended to give access to +view all transactions to and from the address, while an IVK is intended to give access only to view incoming payments (as opposed to change). @@ -551,10 +551,10 @@ addresses MUST be derived from the non-change branch of the key path at distinct change spend authority in Orchard. In the case of deriving a Transparent P2PKH Receiver from a Transparent -P2PKH UIVK, the diversifier index is used as a BIP 44 child key index +P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation -[#bip-0032-public-to-public]_ MUST be used. The UIVK is assumed to +[#bip-0032-public-to-public]_ MUST be used. The IVK is assumed to be the extended public key for the non-change element of the path, and then the Index element of the path MUST be the diversifier index [#bip-0044-path-index]_. That is, if the UIVK was constructed correctly From 5c402793c3b458ee2780fd0adcf6806ac95e5dd4 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 25 Oct 2021 20:12:23 +0100 Subject: [PATCH 06/19] Corrections for Orchard Viewing Keys. Signed-off-by: Daira Hopwood --- zip-0316.rst | 55 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 35 insertions(+), 20 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index ddfbb07b..11439efd 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -388,12 +388,22 @@ corresponding Unified Address. The following FVK or IVK Encodings are used in place of the :math:`\mathtt{addr}` field: -* An Orchard UFVK or UIVK Encoding, with Typecode :math:`\mathtt{0x03},` - is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming - Viewing Key respectively. The UFVK uses the key at the Account level - of the ZIP 32 hierarchy, i.e. at path - :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account'`, - while the UIVK uses its non-change child key at path +* An Orchard FVK Encoding, with Typecode :math:`\mathtt{0x03},` is + a concatenation of: + + * the raw encoding [#protocol-orchardfullviewingkeyencoding]_ of the + Orchard Full Viewing Key at the non-change child of the Account + level, i.e. at path + :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`; + * the raw encoding [#protocol-orchardfullviewingkeyencoding]_ of the + Orchard Full Viewing Key at the change child of the Account level, + i.e. at path + :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 1'`. + +* An Orchard IVK Encoding, also with Typecode :math:`\mathtt{0x03},` + is the raw encoding [#protocol-orchardinviewingkeyencoding]_ of the + Orchard Incoming Viewing Key corresponding to the non-change child + (only) of the Account level, i.e. at path :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`. * A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is @@ -512,20 +522,23 @@ to give access only to view incoming payments (as opposed to change). Deriving a UIVK from a UFVK --------------------------- -For a Sapling UFVK, the corresponding Sapling UIVK is obtained as -specified in [#protocol-saplingkeycomponents]_. +The following derivations are applied to each component FVK: -For an Orchard UFVK, the corresponding Orchard UIVK is obtained by -deriving the child UFVK with non-hardened index :math:`0`, as specified -in [#zip-0032-orchard-child-key-derivation]_, and then the UIVK as -specified in [#protocol-orchardkeycomponents]_. +* For a Sapling FVK, the corresponding Sapling IVK is obtained as + specified in [#protocol-saplingkeycomponents]_. -For a Transparent P2PKH UFVK Encoding, the UIVK Encoding is obtained -from the extended public key corresponding to the account's non-change -key path, i.e. by deriving the child key with non-hardened index :math:`0`. -It is encoded in the same way as the UFVK Encoding. +* For an Orchard FVK, the corresponding Orchard IVK is obtained by + decoding the first :math:`96` bytes of the FVK Encoding (normally + corresponding to the FVK at the non-change child of the Account level) + as an Orchard Full Viewing Key, then deriving the IVK as specified in + [#protocol-orchardkeycomponents]_. -In each case, the Typecode remains the same as in the UFVK. +* For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK + is obtained from the extended public key corresponding to the account's + non-change key path, i.e. by deriving the child key with non-hardened + index :math:`0`. It is encoded in the same way as the FVK Encoding. + +In each case, the Typecode remains the same as in the FVK. Deriving a Unified Address from a UIVK @@ -543,9 +556,9 @@ UIVK. That is, There are no additional constraints on an Orchard diversifier index. -Note that Sapling Receiver addresses MUST be derived from the key path +Note that Sapling Receiver addresses are derived from the key path at the Account level [#zip-0032-sapling-key-path]_, while Orchard Receiver -addresses MUST be derived from the non-change branch of the key path at +addresses are derived from the non-change branch of the key path at :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'` [#zip-0032-orchard-key-path]_. This is to accommodate the use of a distinct change spend authority in Orchard. @@ -564,7 +577,7 @@ then the BIP 44 path of the Transparent P2PKH Receiver will be: Jumbling ---------- +-------- Security goal (**near second preimage resistance**): @@ -814,6 +827,8 @@ References .. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2020.2.16. Section 4.2.3: Orchard Key Components `_ .. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.3.1: Sapling Payment Addresses `_ .. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.2: Orchard Raw Payment Addresses `_ +.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys `_ +.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.4: Orchard Raw Full Viewing Keys `_ .. [#zip-0000] `ZIP 0: ZIP Process `_ .. [#zip-0032-sapling-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys `_ .. [#zip-0032-sapling-diversifier-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation `_ From 9a4df93e974ebdbb534f7d866d86f6f5270fe92e Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 25 Oct 2021 20:29:17 +0100 Subject: [PATCH 07/19] Cosmetics. Signed-off-by: Daira Hopwood --- zip-0316.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 11439efd..f7fff602 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -571,9 +571,8 @@ below the BIP 44 Account level, non-hardened (public) derivation be the extended public key for the non-change element of the path, and then the Index element of the path MUST be the diversifier index [#bip-0044-path-index]_. That is, if the UIVK was constructed correctly -then the BIP 44 path of the Transparent P2PKH Receiver will be: - -* :math:`m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.` +then the BIP 44 path of the Transparent P2PKH Receiver will be +:math:`m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.` Jumbling From dfdb4242f5537455b40598820aacc2182baf7b91 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 25 Oct 2021 20:30:07 +0100 Subject: [PATCH 08/19] ZIP 32: Change the address index used to derive "legacy" Sapling addresses to 0x7FFFFFFF. Signed-off-by: Daira Hopwood --- zip-0032.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0032.rst b/zip-0032.rst index 08f5d0e8..288b32cc 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -454,7 +454,7 @@ they MAY additionally support a non-hardened :math:`address\_index` path level a * :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index`. `zcashd` version 4.5.2 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase -under account :math:`\mathtt{0x7FFFFFFE}`. +under account :math:`\mathtt{0x7FFFFFFF}`. Sprout key path --------------- From 78b7d8489f9b8259ec25935935599a4827abbcbf Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 22 Nov 2021 15:26:18 +0000 Subject: [PATCH 09/19] ZIP 32: Revert all refinements The hardened change path approach is being dropped. ZIP 316 will include separate amendments (to be made later) that derive change addresses within each protocol's key tree, instead of at the spend authorization level. --- zip-0032.rst | 50 +++++++++++++++----------------------------- zip-0316.rst | 58 +++++++++++++--------------------------------------- 2 files changed, 30 insertions(+), 78 deletions(-) diff --git a/zip-0032.rst b/zip-0032.rst index 288b32cc..10392143 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -384,10 +384,6 @@ valid diversifiers. The default diversifier for :math:`(\mathsf{sk}_i, \mathsf{c}_i)` is defined to be :math:`d_{i,0}.` -Although the diversifier *key* is derived from the full viewing key which is at the Account level, the -resulting diversified addresses are derived from the key at the non-change child of that level, as described -in `Orchard key path`_ below. - Specification: Wallet usage =========================== @@ -413,18 +409,11 @@ hardened derivation: - :math:`account`: numbered from index :math:`0` in sequentially increasing manner. Defined as in BIP 44 [#bip-0044]_. -In BIP 44, there is also a :math:`change` unhardened path level as a child of :math:`account`. This -level is not present in the Sprout and Sapling key paths. It *is* present in Orchard, but as a hardened -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. For Sprout and Sapling, it -was reasoned that shielded addresses are never publicly visible in transactions, and so sending change -back to the originating address would be indistinguishable from using a change address. However, this -reasoning does not apply if we give out incoming viewing keys, and so for Orchard the :math:`change` -level has been reintroduced. This ensures that an Orchard incoming viewing key will only be able to view -incoming payments, not incoming change, which was deemed to be more useful for anticipated applications -of incoming viewing keys (such as a merchant terminal or a charity donation address). +Unlike BIP 44, none of the shielded key paths have a :math:`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 ---------------- @@ -466,27 +455,20 @@ Wallets implementing Sprout ZIP 32 derivation MUST support the following path: Orchard key path ---------------- -Orchard supports diversified addresses with the same spending authority (like Sapling). Unlike Sapling and -Sprout, we reintroduce the :math:`change'` level of the key path, so that the spending authorities generated -for incoming payments and for change are distinct. The motivation for this distinction is to allow giving -out an incoming viewing key that is only able to see incoming payments, and not incoming change. +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. -A group of diversified addresses with the same spending authority 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 :math:`\{ 0\,.\!. 2^{31} - 1 \}`: -The key path levels include an account identifier, which in all user interfaces should be represented as -a "bucket of funds" under the control of a single spending authority. Wallets implementing Orchard ZIP 32 -derivation MUST support the following two paths for any account in range :math:`\{ 0\,.\!. 2^{31} - 1 \}`: +* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account'`. -* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account' / 0'` (for incoming payments); -* :math:`m_\mathsf{Orchard} / purpose' / coin\_type' / account' / 1'` (for change). - -Furthermore, wallets MUST support generating a default payment address and a default change address (each -corresponding to the default diversifier for Orchard) for any account they support. They MAY also support -generating a stream of diversified payment addresses (based on the non-change key path) for a given account, -if they wish to enable users to give a unique address to each recipient. A single address using the default -diversifier SHOULD be used for change. +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 :math:`2^{88}` payment addresses (unlike Sapling, all Orchard diversifiers are valid). diff --git a/zip-0316.rst b/zip-0316.rst index f7fff602..2bc1751f 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -388,23 +388,9 @@ corresponding Unified Address. The following FVK or IVK Encodings are used in place of the :math:`\mathtt{addr}` field: -* An Orchard FVK Encoding, with Typecode :math:`\mathtt{0x03},` is - a concatenation of: - - * the raw encoding [#protocol-orchardfullviewingkeyencoding]_ of the - Orchard Full Viewing Key at the non-change child of the Account - level, i.e. at path - :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`; - * the raw encoding [#protocol-orchardfullviewingkeyencoding]_ of the - Orchard Full Viewing Key at the change child of the Account level, - i.e. at path - :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 1'`. - -* An Orchard IVK Encoding, also with Typecode :math:`\mathtt{0x03},` - is the raw encoding [#protocol-orchardinviewingkeyencoding]_ of the - Orchard Incoming Viewing Key corresponding to the non-change child - (only) of the Account level, i.e. at path - :math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'`. +* An Orchard FVK or IVK Encoding, with Typecode :math:`\mathtt{0x03},` is + is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming + Viewing Key respectively. * A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is the encoding of a Sapling Extended Full Viewing Key defined in @@ -414,8 +400,6 @@ The following FVK or IVK Encodings are used in place of the * A Sapling IVK Encoding, also with Typecode :math:`\mathtt{0x02},` is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by :math:`\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).` - Unlike Orchard, a Sapling IVK is associated with the same spending - authority as the corresponding FVK, i.e. also at the Account level. * There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be @@ -431,8 +415,6 @@ The following FVK or IVK Encodings are used in place of the However, the FVK uses the key at the Account level, i.e. at path :math:`m / 44' / coin\_type' / account'`, while the IVK uses its non-change child key at path :math:`m / 44' / coin\_type' / account' / 0`. - (In accordance with BIP 44 and differently to Orchard, the Change level - uses non-hardened derivation.) The Human-Readable Parts (as defined in [#bip-0350]_) of Unified Viewing Keys are defined as follows: @@ -463,9 +445,8 @@ Requirements for both Unified Addresses and Unified Viewing Keys Key at the ZIP 32 or BIP 44 Account level. * Each IVK SHOULD represent an Incoming Viewing Key at the Account - level for Sapling, or its non-change child Incoming Viewing Key for - Orchard, or its non-change child extended public key for Transparent - P2PKH. + level for Sapling or Orchard, or its non-change child extended public + key for Transparent P2PKH. * For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding. @@ -514,7 +495,7 @@ short-term, and should otherwise be either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued. New types SHOULD maintain the same distinction between FVK and IVK -authority as for Orchard, i.e. an FVK is intended to give access to +authority as existing types, i.e. an FVK is intended to give access to view all transactions to and from the address, while an IVK is intended to give access only to view incoming payments (as opposed to change). @@ -527,11 +508,8 @@ The following derivations are applied to each component FVK: * For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in [#protocol-saplingkeycomponents]_. -* For an Orchard FVK, the corresponding Orchard IVK is obtained by - decoding the first :math:`96` bytes of the FVK Encoding (normally - corresponding to the FVK at the non-change child of the Account level) - as an Orchard Full Viewing Key, then deriving the IVK as specified in - [#protocol-orchardkeycomponents]_. +* For an Orchard FVK, the corresponding Orchard IVK is obtained as + specified in [#protocol-orchardkeycomponents]_. * For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK is obtained from the extended public key corresponding to the account's @@ -556,22 +534,14 @@ UIVK. That is, There are no additional constraints on an Orchard diversifier index. -Note that Sapling Receiver addresses are derived from the key path -at the Account level [#zip-0032-sapling-key-path]_, while Orchard Receiver -addresses are derived from the non-change branch of the key path at -:math:`m_\mathsf{Orchard} / 32' / coin\_type' / account' / 0'` -[#zip-0032-orchard-key-path]_. This is to accommodate the use of a -distinct change spend authority in Orchard. - In the case of deriving a Transparent P2PKH Receiver from a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index -at the Index level to derive the address. As is usual for derivations -below the BIP 44 Account level, non-hardened (public) derivation -[#bip-0032-public-to-public]_ MUST be used. The IVK is assumed to -be the extended public key for the non-change element of the path, and -then the Index element of the path MUST be the diversifier index -[#bip-0044-path-index]_. That is, if the UIVK was constructed correctly -then the BIP 44 path of the Transparent P2PKH Receiver will be +at the Index level [#bip-0044-path-index]_ to derive the address. As is +usual for derivations below the BIP 44 Account level, non-hardened +(public) derivation [#bip-0032-public-to-public]_ MUST be used. The IVK +is assumed to be the extended public key for the non-change element of +the path. That is, if the UIVK was constructed correctly then the BIP 44 +path of the Transparent P2PKH Receiver will be :math:`m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.` From 026977744c6e936de763ce26997d934c8cac4be2 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Mon, 22 Nov 2021 15:49:41 +0000 Subject: [PATCH 10/19] ZIP 316: Fix bug in transparent constraint on diversifier index The largest valid integer for any BIP 32 path element with a defined hardening state (in this case, non-hardened) is 2^32 - 1 (being the 31-bit integer with all bits set to 1). The range of valid diversifier indices for transparent-including UAs is defined as end-inclusive in the ZIP, but used the end-exclusive bound 2^32. --- zip-0316.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0316.rst b/zip-0316.rst index 2bc1751f..3573a929 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -530,7 +530,7 @@ UIVK. That is, defined in ZIP 32 section “Sapling diversifier derivation” [#zip-0032-sapling-diversifier-derivation]_. * A Transparent diversifier index MUST be in the range :math:`0` to - :math:`2^{31}` inclusive. + :math:`2^{31} - 1` inclusive. There are no additional constraints on an Orchard diversifier index. From 208d9b39c1b5f652b0fd6a6d6d386e8b281bb71e Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 8 Dec 2021 00:24:35 +0000 Subject: [PATCH 11/19] ZIP 316: Update Sapling and transparent viewing key encodings. Signed-off-by: Daira Hopwood --- zip-0316.rst | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 3573a929..74af407e 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -392,10 +392,12 @@ The following FVK or IVK Encodings are used in place of the is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively. -* A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is - the encoding of a Sapling Extended Full Viewing Key defined in - [#zip-0032-sapling-extfvk]_. This SHOULD be an Extended Full Viewing - Key at the Account level of the ZIP 32 hierarchy. +* A Sapling FVK Encoding, with Typecode :math:`\mathtt{0x02},` is the + encoding of :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})` + given by :math:`\mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})`, + where :math:`\mathsf{EncodeExtFVKParts}` is defined in [#zip-0032-sapling-helper-functions]_. + This SHOULD be derived from the Extended Full Viewing Key at the Account + level of the ZIP 32 hierarchy. * A Sapling IVK Encoding, also with Typecode :math:`\mathtt{0x02},` is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by @@ -408,10 +410,12 @@ The following FVK or IVK Encodings are used in place of the treated as unrecognized by Consumers. * For Transparent P2PKH Addresses that are derived according to BIP 32 - [#bip-0032]_ and BIP 44 [#bip-0044]_, the FVK and IVK Encodings - have Typecode :math:`\mathtt{0x00}.` Both of these encodings are the - serialization of an extended public key, defined in the section - “Serialization format” of BIP 32 [#bip-0032-serialization-format]_. + [#bip-0032]_ and BIP 44 [#bip-0044]_, the FVK and IVK Encodings have + Typecode :math:`\mathtt{0x00}.` Both of these are encodings of the + chain code and public key :math:`(\mathsf{c}, \mathsf{pk})` given by + :math:`\mathsf{c}\,||\,\mathsf{ser_P}(\mathsf{pk})`. (This is the + same as the last 65 bytes of the extended public key format defined + in section “Serialization format” of BIP 32 [#bip-0032-serialization-format]_.) However, the FVK uses the key at the Account level, i.e. at path :math:`m / 44' / coin\_type' / account'`, while the IVK uses its non-change child key at path :math:`m / 44' / coin\_type' / account' / 0`. @@ -799,6 +803,7 @@ References .. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys `_ .. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.4: Orchard Raw Full Viewing Keys `_ .. [#zip-0000] `ZIP 0: ZIP Process `_ +.. [#zip-0032-sapling-helper-functions] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions `_ .. [#zip-0032-sapling-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys `_ .. [#zip-0032-sapling-diversifier-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation `_ .. [#zip-0032-orchard-child-key-derivation] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation `_ From 0e83a55a0542d96278f276cece240d901ad73c3b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 8 Dec 2021 00:25:45 +0000 Subject: [PATCH 12/19] ZIP 316: Clarify requirements for HD-derived items and remove redundancy. Signed-off-by: Daira Hopwood --- zip-0316.rst | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 74af407e..ff571ab2 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -445,12 +445,9 @@ Requirements for both Unified Addresses and Unified Viewing Keys all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.) -* Each Receiver and FVK SHOULD represent an Address or Full Viewing - Key at the ZIP 32 or BIP 44 Account level. - -* Each IVK SHOULD represent an Incoming Viewing Key at the Account - level for Sapling or Orchard, or its non-change child extended public - key for Transparent P2PKH. +* Within a single UA or UVK, all HD-derived Receivers, FVKs, and IVKs + SHOULD represent an Address or Viewing Key for the same account (as + used in the ZIP 32 or BIP 44 Account level). * For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding. From d325f0b3b4c5a7b1fcdfb429c80058f6ed5aa5b8 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 8 Dec 2021 00:29:03 +0000 Subject: [PATCH 13/19] ZIP 316: Fix link. Signed-off-by: Daira Hopwood --- zip-0316.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0316.rst b/zip-0316.rst index ff571ab2..9bbe7c38 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -810,7 +810,7 @@ References .. [#zip-0224] `ZIP 224: Orchard Shielded Protocol `_ .. [#zip-0321] `ZIP 321: Payment Request URIs `_ .. [#bip-0032] `BIP 32: Hierarchical Deterministic Wallets `_ -.. [#bip-0032-serialization-format] `BIP 32: Hierarchical Deterministic Wallets — Serialization Format `_ +.. [#bip-0032-serialization-format] `BIP 32: Hierarchical Deterministic Wallets — Serialization Format `_ .. [#bip-0032-public-to-public] `BIP 32: Hierarchical Deterministic Wallets — Child key derivation (CKD) functions: Public parent key → public child key `_ .. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets `_ .. [#bip-0044-path-index] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Index `_ From 0db40ef9279654d7ed6257a87434984d8405d8b1 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 8 Dec 2021 01:33:10 +0000 Subject: [PATCH 14/19] ZIP 32: Note that legacy Sapling addresses use hardened derivation for `address_index`. --- zip-0032.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0032.rst b/zip-0032.rst index 10392143..df2186a2 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -443,7 +443,7 @@ they MAY additionally support a non-hardened :math:`address\_index` path level a * :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index`. `zcashd` version 4.5.2 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase -under account :math:`\mathtt{0x7FFFFFFF}`. +under account :math:`\mathtt{0x7FFFFFFF}`, using hardened derivation for :math:`address\_index`. Sprout key path --------------- From 682308e33bf160f8945ed915bcecaabbcf2625eb Mon Sep 17 00:00:00 2001 From: Deirdre Connolly Date: Wed, 8 Dec 2021 16:13:40 -0500 Subject: [PATCH 15/19] ZIP 32: There will not be a zcashd 4.5.2, there will be 4.6.0. --- zip-0032.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0032.rst b/zip-0032.rst index df2186a2..b3a8f27c 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -442,7 +442,7 @@ they MAY additionally support a non-hardened :math:`address\_index` path level a * :math:`m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index`. -`zcashd` version 4.5.2 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase +`zcashd` version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account :math:`\mathtt{0x7FFFFFFF}`, using hardened derivation for :math:`address\_index`. Sprout key path From 110fe1a84ef0589034d92c7a1995afa9bb2351ab Mon Sep 17 00:00:00 2001 From: Deirdre Connolly Date: Wed, 8 Dec 2021 16:28:48 -0500 Subject: [PATCH 16/19] ZIP 316: Update wording for Transparent P2PKH Receiver derivation. Co-authored-by: Deirdre Connolly Signed-off-by: Daira Hopwood --- zip-0316.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 9bbe7c38..a89298ab 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -540,9 +540,9 @@ P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level [#bip-0044-path-index]_ to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation [#bip-0032-public-to-public]_ MUST be used. The IVK -is assumed to be the extended public key for the non-change element of -the path. That is, if the UIVK was constructed correctly then the BIP 44 -path of the Transparent P2PKH Receiver will be +is assumed to correspond to the extended public key for the non-change +element of the path. That is, if the UIVK was constructed correctly then +the BIP 44 path of the Transparent P2PKH Receiver will be :math:`m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.` From 96c5ad3f69491653323c806be40a3e3607eafb85 Mon Sep 17 00:00:00 2001 From: Deirdre Connolly Date: Wed, 8 Dec 2021 16:29:56 -0500 Subject: [PATCH 17/19] ZIP 316: Clarify position of Transparent IVKs in the key tree. Co-authored-by: Kris Nuttycombe Signed-off-by: Daira Hopwood --- zip-0316.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index a89298ab..26c2b1f8 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -417,8 +417,9 @@ The following FVK or IVK Encodings are used in place of the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 [#bip-0032-serialization-format]_.) However, the FVK uses the key at the Account level, i.e. at path - :math:`m / 44' / coin\_type' / account'`, while the IVK uses its - non-change child key at path :math:`m / 44' / coin\_type' / account' / 0`. + :math:`m / 44' / coin\_type' / account'`, while the IVK uses the + external (non-change) child key at the Change level, i.e. at path + :math:`m / 44' / coin\_type' / account' / 0`. The Human-Readable Parts (as defined in [#bip-0350]_) of Unified Viewing Keys are defined as follows: From 4a238755195a9cf9145d0ab534263f9a37579b06 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 8 Dec 2021 23:43:11 +0000 Subject: [PATCH 18/19] ZIP 316: Clarify derivation of P2PKH IVK from FVK. Signed-off-by: Daira Hopwood --- zip-0316.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 26c2b1f8..ed2599a4 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -514,9 +514,8 @@ The following derivations are applied to each component FVK: specified in [#protocol-orchardkeycomponents]_. * For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK - is obtained from the extended public key corresponding to the account's - non-change key path, i.e. by deriving the child key with non-hardened - index :math:`0`. It is encoded in the same way as the FVK Encoding. + is obtained by deriving the child key with non-hardened index :math:`0` + as described in [#bip-0032-public-to-public]_. In each case, the Typecode remains the same as in the FVK. From 12a16786815e3be292c24350d944ad21c026174c Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 8 Dec 2021 23:47:06 +0000 Subject: [PATCH 19/19] ZIPs 32 and 316: Regenerate HTML. Signed-off-by: Daira Hopwood --- zip-0032.html | 9 ++- zip-0316.html | 194 ++++++++++++++++++++++++++++++++++++-------------- 2 files changed, 146 insertions(+), 57 deletions(-) diff --git a/zip-0032.html b/zip-0032.html index fba5d76b..d9f75da1 100644 --- a/zip-0032.html +++ b/zip-0032.html @@ -44,7 +44,7 @@ License: MIT
  • Wallets only need to store a single seed (particularly useful for hardware wallets).
  • A one-time backup of the seed (usually stored as a word phrase 3) can be used to recover funds from all future addresses.
  • Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.
    • -
  • View authority or spend authority can be delegated independently for sub-trees without compromising the master seed.
    • +
  • Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.

    • 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.

    @@ -670,7 +670,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 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 + : 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\) @@ -707,6 +707,11 @@ License: MIT \(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\) .
    • +

    zcashd version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account + \(\mathtt{0x7FFFFFFF}\) + , using hardened derivation for + \(address\_index\) + .

    Sprout key path

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

    diff --git a/zip-0316.html b/zip-0316.html index b170abc4..092d8dfe 100644 --- a/zip-0316.html +++ b/zip-0316.html @@ -71,7 +71,7 @@ Discussions-To: <https://g
  • Sapling Addresses

    • Each of these has its own Address Encodings, as a string and as a QR code. (Since the QR code is derivable from the string encoding, for many purposes it suffices to consider the string encoding.)

    -

    The Orchard proposal 10 adds a new Address type, Orchard Addresses.

    +

    The Orchard proposal 18 adds a new Address type, Orchard Addresses.

    The difficulty with defining new Address Encodings for each Address type, is that end-users are forced to be aware of the various types, and in particular which types are supported by a given Consumer or Recipient. In order to make sure that transfers are completed successfully, users may be forced to explicitly generate Addresses of different types and re-distribute encodings of them, which adds significant friction and cognitive overhead to understanding and using Zcash.

    The goals for a Unified Address standard are as follows:

    Viewing Keys

    A Unified Full Viewing Key (resp. Unified Incoming Viewing Key) can be used in a similar way to a Full Viewing Key (resp. Incoming Viewing Key) as described in the Zcash Protocol Specification 2.

    -

    For a Transparent P2PKH Address that is derived according to BIP 32 12 and BIP 44 15, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.

    +

    For a Transparent P2PKH Address that is derived according to BIP 32 20 and BIP 44 23, the nearest equivalent to a Full Viewing Key or Incoming Viewing Key for a given BIP 44 account is an extended public key, as defined in the section “Extended keys” of BIP 32. Therefore, UFVKs and UIVKs should be able to include such extended public keys.

    A wallet should support deriving a UIVK from a UFVK, and a Unified Address from a UIVK.

    Open Issues and Known Concerns

    @@ -150,10 +150,10 @@ Discussions-To: <https://g

    Encoding of Unified Full/Incoming Viewing Keys

    Unified Full or Incoming Viewing Keys are encoded and decoded analogously to Unified Addresses. A Consumer MUST use the decoding procedure from the previous section. For Viewing Keys, a Consumer will normally take the union of information provided by all contained Receivers, and therefore the Priority List defined in the previous section is not used.

    -

    For each UFVK Type or UIVK Type currently defined in this specification, the same Typecode is used as for the corresponding Receiver Type in a Unified Address. Additional UFVK Types and UIVK Types MAY be defined in future, and these will not necessarily use the same Typecode as the corresponding Unified Address.

    -

    The following UFVK or UIVK Encodings are used in place of the +

    For each FVK Type or IVK Type currently defined in this specification, the same Typecode is used as for the corresponding Receiver Type in a Unified Address. Additional FVK Types and IVK Types MAY be defined in future, and these will not necessarily use the same Typecode as the corresponding Unified Address.

    +

    The following FVK or IVK Encodings are used in place of the \(\mathtt{addr}\) field:

      -
    • An Orchard UFVK or UIVK Encoding, with Typecode +
    • An Orchard FVK or IVK Encoding, with Typecode \(\mathtt{0x03},\) - is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively.
      • -
    • A Sapling UFVK Encoding, with Typecode + is is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively.
      • +
    • A Sapling FVK Encoding, with Typecode \(\mathtt{0x02},\) - is the encoding of a Sapling Extended Full Viewing Key defined in 7.
      • -
    • A Sapling UIVK Encoding, also with Typecode + is the encoding of + \((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\) + given by + \(\mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\) + , where + \(\mathsf{EncodeExtFVKParts}\) + is defined in 11. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.
      • +
    • A Sapling IVK Encoding, also with Typecode \(\mathtt{0x02},\) is an encoding of \((\mathsf{dk}, \mathsf{ivk})\) @@ -229,11 +235,19 @@ Discussions-To: <https://g
    • There is no defined way to represent a Viewing Key for a Transparent P2SH Address in a UFVK or UIVK (because P2SH Addresses cannot be diversified in an unlinkable way). The Typecode \(\mathtt{0x01}\) MUST NOT be included in a UFVK or UIVK by Producers, and MUST be treated as unrecognized by Consumers.
      • -
    • For Transparent P2PKH Addresses that are derived according to BIP 32 12 and BIP 44 15, the UFVK and UIVK Encodings have Typecode +
    • For Transparent P2PKH Addresses that are derived according to BIP 32 20 and BIP 44 23, the FVK and IVK Encodings have Typecode \(\mathtt{0x00}.\) - These encodings are identical and are the serialization of an extended public key, defined in the section “Serialization format” of BIP 32 13.
      • + Both of these are encodings of the chain code and public key + \((\mathsf{c}, \mathsf{pk})\) + given by + \(\mathsf{c}\,||\,\mathsf{ser_P}(\mathsf{pk})\) + . (This is the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 21.) However, the FVK uses the key at the Account level, i.e. at path + \(m / 44' / coin\_type' / account'\) + , while the IVK uses the external (non-change) child key at the Change level, i.e. at path + \(m / 44' / coin\_type' / account' / 0\) + .
    -

    The Human-Readable Parts (as defined in 17) of Unified Viewing Keys are defined as follows:

    +

    The Human-Readable Parts (as defined in 25) of Unified Viewing Keys are defined as follows:

    • “uivk” for Unified Incoming Viewing Keys on Mainnet;
    • “uivktest” for Unified Incoming Viewing Keys on Testnet;
      • @@ -254,10 +268,10 @@ Discussions-To: <https://g \(\mathtt{length}\) fields are encoded as \(\mathtt{compactSize}.\) - 20 (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.) -
    • Each Receiver, UFVK, or UIVK SHOULD represent an Address or Viewing Key at the ZIP 32 or BIP 44 Account level.
      • + 28 (Although existing Receiver Encodings and Viewing Key Encodings are all less than 256 bytes and so could use a one-byte length field, encodings for experimental types may be longer.) +
    • Within a single UA or UVK, all HD-derived Receivers, FVKs, and IVKs SHOULD represent an Address or Viewing Key for the same account (as used in the ZIP 32 or BIP 44 Account level).
    • For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding.
      • -
    • There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade 9) to send funds into the Sprout chain value pool, this would not be generally useful.
      • +
    • There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade 17) to send funds into the Sprout chain value pool, this would not be generally useful.
    • Consumers MUST ignore constituent Addresses/Viewing Keys with Typecodes they do not recognize.
    • Consumers MUST reject Unified Addresses/Viewing Keys in which the same Typecode appears more than once, or that include both P2SH and P2PKH Transparent Addresses, or that contain only a Transparent Address.
    • Consumers MUST reject Unified Addresses/Viewing Keys in which any constituent address does not meet the validation requirements of its Receiver Encoding, as specified in the Zcash Protocol Specification 2.
      • @@ -266,33 +280,39 @@ Discussions-To: <https://g

    Adding new types

    -

    It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process 6.

    +

    It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process 10.

    For experimentation prior to proposing a ZIP, experimental types MAY be added using the reserved Typecodes \(\mathtt{0xFFFA}\) to \(\mathtt{0xFFFF}\) inclusive. This provides for six simultaneous experiments, which can be referred to as experiments A to F. This should be sufficient because experiments are expected to be reasonably short-term, and should otherwise be either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued.

    +

    New types SHOULD maintain the same distinction between FVK and IVK authority as existing types, i.e. an FVK is intended to give access to view all transactions to and from the address, while an IVK is intended to give access only to view incoming payments (as opposed to change).

    Deriving a UIVK from a UFVK

    -

    Each UIVK Encoding can straightforwardly be derived from the corresponding UFVK Encoding, without changing the Typecode. In the case of a Transparent P2PKH UFVK Encoding, the UIVK Encoding is the same.

    +

    The following derivations are applied to each component FVK:

    +
      +
    • For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in 4.
      • +
    • For an Orchard FVK, the corresponding Orchard IVK is obtained as specified in 5.
      • +
    • For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK is obtained by deriving the child key with non-hardened index + \(0\) + as described in 22.
      • +
    +

    In each case, the Typecode remains the same as in the FVK.

    Deriving a Unified Address from a UIVK

    To derive a Unified Address from a UIVK we need to choose a diversifier index, which MUST be valid for all of the Viewing Key Types in the UIVK. That is,

      -
    • A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” 8.
      • +
    • A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” 13.
    • A Transparent diversifier index MUST be in the range \(0\) to - \(2^{31}\) + \(2^{31} - 1\) inclusive.

    There are no additional constraints on an Orchard diversifier index.

    -

    In the case of deriving a Transparent P2PKH Receiver from a Transparent P2PKH UIVK, the diversifier index is used as a BIP 44 child key index at the Index level to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation 14 MUST be used, with the Change element of the path being 0, and the Index element of the path being the diversifier index 16. That is, the BIP 44 path of the Transparent P2PKH Receiver MUST be:

    -
      -
    • - \(m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.\) -
      • -
    +

    In the case of deriving a Transparent P2PKH Receiver from a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level 24 to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation 22 MUST be used. The IVK is assumed to correspond to the extended public key for the non-change element of the path. That is, if the UIVK was constructed correctly then the BIP 44 path of the Transparent P2PKH Receiver will be + \(m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.\) +

    Jumbling

    Security goal (near second preimage resistance):

    @@ -605,7 +625,7 @@ c^{n+m}}{q}.\) 2 - Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal] + Zcash Protocol Specification, Version 2020.2.16 or later [NU5 proposal] @@ -613,38 +633,78 @@ c^{n+m}}{q}.\) 3 - Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal]. Section 2: Notation + Zcash Protocol Specification, Version 2020.2.16. Section 2: Notation + + + + + + + + + + +
    4Zcash Protocol Specification, Version 2020.2.16. Section 4.2.2: Sapling Key Components
    + + + + +
    5Zcash Protocol Specification, Version 2020.2.16. Section 4.2.3: Orchard Key Components
    - - + +
    4Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses6Zcash Protocol Specification, Version 2020.2.16. Section 5.6.3.1: Sapling Payment Addresses
    - - + + + + +
    5Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses7Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.2: Orchard Raw Payment Addresses
    + + + + + + + +
    8Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys
    + + + + +
    9Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.4: Orchard Raw Full Viewing Keys
    - +
    610 ZIP 0: ZIP Process
    + + + + + + + +
    11ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions
    - + @@ -652,15 +712,39 @@ c^{n+m}}{q}.\)
    712 ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys
    - +
    813 ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation
    + + + + + + + +
    14ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation
    + + + + + + + +
    15ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path
    + + + + + + + +
    16ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path
    - + @@ -668,7 +752,7 @@ c^{n+m}}{q}.\)
    917 ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool
    - + @@ -676,7 +760,7 @@ c^{n+m}}{q}.\)
    1018 ZIP 224: Orchard Shielded Protocol
    - + @@ -684,7 +768,7 @@ c^{n+m}}{q}.\)
    1119 ZIP 321: Payment Request URIs
    - + @@ -692,15 +776,15 @@ c^{n+m}}{q}.\)
    1220 BIP 32: Hierarchical Deterministic Wallets
    - - + +
    13BIP 32: Hierarchical Deterministic Wallets — Serialization Format21BIP 32: Hierarchical Deterministic Wallets — Serialization Format
    - + @@ -708,7 +792,7 @@ c^{n+m}}{q}.\)
    1422 BIP 32: Hierarchical Deterministic Wallets — Child key derivation (CKD) functions: Public parent key → public child key
    - + @@ -716,7 +800,7 @@ c^{n+m}}{q}.\)
    1523 BIP 44: Multi-Account Hierarchy for Deterministic Wallets
    - + @@ -724,7 +808,7 @@ c^{n+m}}{q}.\)
    1624 BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Index
    - + @@ -732,7 +816,7 @@ c^{n+m}}{q}.\)
    1725 BIP 350: Bech32m format for v1+ witness addresses
    - + @@ -740,7 +824,7 @@ c^{n+m}}{q}.\)
    1826 Transactions: P2PKH Script Validation — Bitcoin Developer Guide
    - + @@ -748,7 +832,7 @@ c^{n+m}}{q}.\)
    1927 Transactions: P2SH Scripts — Bitcoin Developer Guide
    - +
    2028 Variable length integer. Bitcoin Wiki