From 4d0477ce5fd7bd5fcc7312aa34b7a94267d0211b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 12 Oct 2021 23:23:57 +0100 Subject: [PATCH] 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 `_