From e3092254955a6be8762486f8eff0c97548727df0 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 26 Aug 2021 19:51:18 +0100 Subject: [PATCH 01/16] ZIP 316: Update terminology to better account for viewing keys. Signed-off-by: Daira Hopwood --- zip-0316.rst | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index f491ce8e..d8f27117 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -28,10 +28,11 @@ Recipient A wallet or other software that can receive transfers of assets (such as ZEC) or in the future potentially other transaction-based state changes. Producer - A wallet or other software that can create an Address (normally also a - Recipient). + A wallet or other software that can create an Address (in which case it is + normally also a Recipient) or a Viewing Key. Consumer - A wallet or other software that can make use of an Address that it is given. + A wallet or other software that can make use of an Address or Viewing Key + that it is given. Sender A wallet or other software that can send transfers of assets, or other consensus state side-effects defined in future. Senders are a subset of @@ -42,7 +43,12 @@ Receiver unambiguously with a specific Receiver Type, identified by an integer Typecode. Receiver Encoding An encoding of a Receiver as a byte sequence. -Legacy Address (or LA) +Viewing Key + The necessary information to view information about a payments to an Address, + or (in the case of a Full Viewing Key) from an Address. +Viewing Key Encoding + An encoding of a Viewing Key as a byte sequence. +Legacy Address A Transparent, Sprout, or Sapling Address. Unified Address (or UA) A Unified Address combines multiple Receivers. @@ -50,6 +56,8 @@ Unified Full Viewing Key (or UFVK) A Unified Full Viewing Key combines multiple Full Viewing Keys. Unified Incoming Viewing Key (or UIVK) A Unified Incoming Viewing Key combines multiple Incoming Viewing Keys. +Unified Viewing Key + Either a Unified Full Viewing Key or a Unified Incoming Viewing Key. Address Either a Legacy Address or a Unified Address. Transfer Protocol @@ -182,11 +190,12 @@ Receivers --------- Every Wallet must properly *parse* a Unified Address containing unrecognized -Receiver Types; and similarly for Unified Full Viewing Keys and Unified -Incoming Viewing Keys. +Receiver Types; and similarly for Unified Viewing Keys containing unrecognized +Viewing Key Types. -A Wallet may process unrecognized Receiver Types by indicating to the user -their presence or similar information for usability or diagnostic purposes. +A Wallet may process unrecognized Receiver Types or Viewing Key Types by +indicating to the user their presence or similar information for usability or +diagnostic purposes. Transport Encoding ------------------ From 6611f7a245e8a543d8436903296520a5a7602c31 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 13:51:04 +0100 Subject: [PATCH 02/16] ZIP 316: Updates for longer UAs/UVKs and experimental types. Signed-off-by: Daira Hopwood --- zip-0316.rst | 91 +++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 66 insertions(+), 25 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index d8f27117..10a9591a 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -244,6 +244,15 @@ though it were absent. shielded support without re-acquiring counterparty UAs. If they are re-acquired, the user flow and usability will be minimally disrupted. +Experimental Usage +------------------ + +Unified Addresses and Unified Viewing Keys must be able to include +Receivers and Viewing Keys of experimental types, possibly alongside +non-experimental ones. These experimental Receivers or Viewing Keys +must be used only by wallets whose users have explicitly opted into +the corresponding experiment. + Viewing Keys ------------ @@ -314,10 +323,10 @@ The raw encoding of a Unified Address is a concatenation of :math:`(\mathtt{typecode}, \mathtt{length}, \mathtt{addr})` encodings of the consituent Receivers: -* :math:`\mathtt{typecode} : \mathtt{byte}` — the Typecode from the +* :math:`\mathtt{typecode} : \mathtt{compactSize}` — the Typecode from the above Priority List; -* :math:`\mathtt{length} : \mathtt{byte}` — the length in bytes of +* :math:`\mathtt{length} : \mathtt{compactSize}` — the length in bytes of :math:`\mathtt{addr}`; * :math:`\mathtt{addr} : \mathtt{byte[length]}` — the Receiver Encoding. @@ -391,8 +400,11 @@ Requirements for both Unified Addresses and Unified Viewing Keys P2SH and P2PKH transparent-only address formats suffice for this purpose and are already supported by the existing ecosystem. -* The :math:`\mathtt{length}` field is always encoded as a single - byte, *not* as a :math:`\mathtt{compactSize}`. +* The :math:`\mathtt{length}` field is encoded as a + :math:`\mathtt{compactSize}.` [#Bitcoin-CompactSize]_ (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.) * For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding. @@ -425,6 +437,21 @@ Requirements for both Unified Addresses and Unified Viewing Keys that cannot be interpreted as specified above. +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 [#zip-0000]_. + +Experimental types MAY be added using the reserved Typecodes 0xFFFA to 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. + + Address hardening ----------------- @@ -483,7 +510,7 @@ length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with extendable output length) based on :math:`H`, personalized by :math:`i`. Given input :math:`M` of length :math:`\ell_M` bytes such that -:math:`48 \leq \ell_M \leq 16448`, define :math:`\mathsf{F4Jumble}(M)` +:math:`48 \leq \ell_M \leq 4194368,` define :math:`\mathsf{F4Jumble}(M)` by: * let :math:`\ell_L = \mathsf{min}(\ell_H, \mathsf{floor}(\ell_M/2))` @@ -501,14 +528,14 @@ way for a Feistel construction, by observing that :math:`r = p \oplus q` implies The first argument to BLAKE2b below is the personalization. We instantiate :math:`H_i(u)` by -:math:`\mathsf{BLAKE2b‐}(8\ell_L)(\texttt{“UA_F4Jumble_H_”} \,||\,` -:math:`[i, 0], u)`. +:math:`\mathsf{BLAKE2b‐}(8\ell_L)(\texttt{“UA_F4Jumble_H”} \,||\,` +:math:`[i, 0, 0], u).` We instantiate :math:`G_i(u)` as the first :math:`\ell_R` bytes of the concatenation of -:math:`[\mathsf{BLAKE2b‐}512(\texttt{“UA_F4Jumble_G_”} \,||\,` -:math:`[i, j], u) \text{ for } j \text{ from } 0 \text{ up to}` -:math:`\mathsf{ceiling}(\ell_R/\ell_H)-1]`. +:math:`[\mathsf{BLAKE2b‐}512(\texttt{“UA_F4Jumble_G”} \,||\, [i] \,||\,` +:math:`\mathsf{I2LEOSP}_{16}(j), u) \text{ for } j \text{ from}` +:math:`0 \text{ up to } \mathsf{ceiling}(\ell_R/\ell_H)-1].` .. figure:: zip-0316-f4.png :width: 372px @@ -530,14 +557,14 @@ zero bytes, to the raw encoding, then applies :math:`\mathsf{F4Jumble}` before encoding the result with Bech32m. The Consumer rejects any Bech32m-decoded byte sequence that is less than -48 bytes or greater than 16448 bytes; otherwise it applies -:math:`\mathsf{F4Jumble}^{-1}`. It rejects any result that does not end +48 bytes or greater than 4194368 bytes; otherwise it applies +:math:`\mathsf{F4Jumble}^{-1}.` It rejects any result that does not end in the expected padding, before stripping these 16 bytes and parsing the result. (48 bytes is the minimum size of a valid UA, UFVK, or UIVK raw encoding plus 16 zero bytes, corresponding to a single Sapling Incoming Viewing Key. -16448 bytes is the largest input/output size supported by :math:`\mathsf{F4Jumble}`.) +4194368 bytes is the largest input/output size supported by :math:`\mathsf{F4Jumble}.`) Heuristic analysis '''''''''''''''''' @@ -601,14 +628,26 @@ to a single Address with a given Typecode (and at most one Transparent Address) means that this is also the maximum length as of NU5 activation. For longer UAs (when other Typecodes are added), the cost increases to 6 -BLAKE2b compressions for :math:`128 < \ell_M \leq 192`, and 10 BLAKE2b -compressions for :math:`192 < \ell_M \leq 256`, for example. The maximum -cost for which the algorithm is defined would be 768 BLAKE2b compressions -at :math:`\ell_M = 16448` bytes. We will almost certainly never add enough -Typecodes to reach that, and we might want to define a smaller limit. +BLAKE2b compressions for :math:`128 < \ell_M \leq 192,` and 10 BLAKE2b +compressions for :math:`192 < \ell_M \leq 256,` for example. The maximum +cost for which the algorithm is defined would be 196608 BLAKE2b compressions +at :math:`\ell_M = 4194368` bytes. + +A naïve implementation of the :math:`F4Jumble^{-1}` function would require +roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state. However, +it is possible to reduce this by streaming the :math:`d` part of the jumbled +encoding from a less memory-constrained device. After the first pass of +:math:`d`, the implementation is able to compute :math:`y`; after the second +pass it is able to compute :math:`a`; and the third allows it to compute +and incrementally parse :math:`b.` The maximum memory usage during this +process would be 128 bytes (for the cached :math:`c` or :math:`y`), plus two +BLAKE2b hash states. + +Since this streaming implementation of :math:`F4Jumble^{-1}` is quite +complicated, we do not require all Consumers to support it. If a Consumer +implementation cannot support UAs / UVKs up to the maximum length, it MUST +nevertheless support UAs / UVKs with :math:`\ell_M` of at least 256 bytes. -The memory usage, for a memory-optimized implementation, is roughly -:math:`\ell_M` bytes plus the size of a BLAKE2b hash state. Dependencies '''''''''''' @@ -640,20 +679,22 @@ Acknowledgements ================ The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre, -Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, and Teor for -discussions on the subject of Unified Addresses. +Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, Teor, and +Eran Tromer for discussions on the subject of Unified Addresses. References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.1.24 or later [NU5 proposal] `_ -.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ -.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses `_ +.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.2.14 or later [NU5 proposal] `_ +.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ +.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses `_ +.. [#zip-0000] `ZIP 0: ZIP Process `_ .. [#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 `_ .. [#bip-0350] `BIP 350: Bech32m format for v1+ witness addresses `_ .. [#P2PKH] `Transactions: P2PKH Script Validation — Bitcoin Developer Guide `_ .. [#P2SH] `Transactions: P2SH Scripts — Bitcoin Developer Guide `_ +.. [#Bitcoin-CompactSize] `Variable length integer. Bitcoin Wiki `_ From cf0219cd6705b32d9f75ce0d12fdb0b1fb3b21e5 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 13:44:03 +0100 Subject: [PATCH 03/16] ZIP 316: Clarify a security requirement for streamed calculation of F4Jumble^-1. Signed-off-by: Daira Hopwood --- zip-0316.rst | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 10a9591a..4151433f 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -636,12 +636,15 @@ at :math:`\ell_M = 4194368` bytes. A naïve implementation of the :math:`F4Jumble^{-1}` function would require roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state. However, it is possible to reduce this by streaming the :math:`d` part of the jumbled -encoding from a less memory-constrained device. After the first pass of -:math:`d`, the implementation is able to compute :math:`y`; after the second -pass it is able to compute :math:`a`; and the third allows it to compute -and incrementally parse :math:`b.` The maximum memory usage during this -process would be 128 bytes (for the cached :math:`c` or :math:`y`), plus two -BLAKE2b hash states. +encoding three times from a less memory-constrained device. It is essential +that the streamed value of :math:`d` is the same on each pass, which can be +verified using a MAC (with key held only by the Consumer) or +collision-resistant hash function. After the first pass of :math:`d`, the +implementation is able to compute :math:`y`; after the second pass it is +able to compute :math:`a`; and the third allows it to compute and +incrementally parse :math:`b.` The maximum memory usage during this process +would be 128 bytes (for the cached :math:`c` or :math:`y`), plus two BLAKE2b +hash states. Since this streaming implementation of :math:`F4Jumble^{-1}` is quite complicated, we do not require all Consumers to support it. If a Consumer From 0c146374293cc6f69fbb450d88c9652c89490fa7 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 13:52:55 +0100 Subject: [PATCH 04/16] ZIP 316: Cosmetics. Signed-off-by: Daira Hopwood --- zip-0316.rst | 86 +++++++++++++++++++++++++++------------------------- 1 file changed, 44 insertions(+), 42 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 4151433f..32eca790 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -327,13 +327,13 @@ of the consituent Receivers: above Priority List; * :math:`\mathtt{length} : \mathtt{compactSize}` — the length in bytes of - :math:`\mathtt{addr}`; + :math:`\mathtt{addr};` * :math:`\mathtt{addr} : \mathtt{byte[length]}` — the Receiver Encoding. A Receiver Encoding is the raw encoding of a Shielded Payment Address, -or the :math:`160`-bit script hash of a P2SH address [#P2SH]_, or the -:math:`160`-bit validating key hash of a P2PKH address [#P2PKH]_. +or the :math:`160\!`-bit script hash of a P2SH address [#P2SH]_, or the +:math:`160\!`-bit validating key hash of a P2PKH address [#P2PKH]_. Let ``padding`` be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append ``padding`` to @@ -440,15 +440,16 @@ Requirements for both Unified Addresses and Unified Viewing Keys 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 [#zip-0000]_. +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 [#zip-0000]_. -Experimental types MAY be added using the reserved Typecodes 0xFFFA to 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 +Experimental types MAY be added using the reserved Typecodes +:math:`\mathtt{0xFFFA}` to :math:`\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. @@ -489,8 +490,8 @@ properties of checksums, etc. The generic attack puts an upper bound on the achievable security: if it takes work :math:`w` to produce and verify a UA, and the size of the character -set is :math:`c`, then the generic attack costs :math:`\sim \frac{w \cdot -c^{n+m}}{q}`. +set is :math:`c,` then the generic attack costs :math:`\sim \frac{w \cdot +c^{n+m}}{q}.` There is also a generic brute force attack against nonmalleability. The adversary modifies the target Address slightly and computes the corresponding @@ -505,9 +506,9 @@ Solution We use an unkeyed 4-round Feistel construction to approximate a random permutation. (As explained below, 3 rounds would not be sufficient.) -Let :math:`H_i` be a hash personalized by :math:`i`, with maximum output +Let :math:`H_i` be a hash personalized by :math:`i,` with maximum output length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with -extendable output length) based on :math:`H`, personalized by :math:`i`. +extendable output length) based on :math:`H,` personalized by :math:`i.` Given input :math:`M` of length :math:`\ell_M` bytes such that :math:`48 \leq \ell_M \leq 4194368,` define :math:`\mathsf{F4Jumble}(M)` @@ -520,10 +521,10 @@ by: * let :math:`y = a \oplus H_0(x)` * let :math:`d = x \oplus G_1(y)` * let :math:`c = y \oplus H_1(d)` -* return :math:`c \,||\, d`. +* return :math:`c \,||\, d.` The inverse function :math:`\mathsf{F4Jumble}^{-1}` is obtained in the usual -way for a Feistel construction, by observing that :math:`r = p \oplus q` implies :math:`p = r \oplus q`. +way for a Feistel construction, by observing that :math:`r = p \oplus q` implies :math:`p = r \oplus q.` The first argument to BLAKE2b below is the personalization. @@ -579,31 +580,31 @@ A 3-round unkeyed Feistel, as shown, is not sufficient: Diagram of 3-round unkeyed Feistel construction Suppose that an adversary has a target input/output pair -:math:`(a \,||\, b, c \,||\, d)`, and that the input to :math:`H_0` is -:math:`x`. By fixing :math:`x`, we can obtain another pair +:math:`(a \,||\, b, c \,||\, d),` and that the input to :math:`H_0` is +:math:`x.` By fixing :math:`x,` we can obtain another pair :math:`((a \oplus t) \,||\, b', (c \oplus t) \,||\, d')` such that :math:`a \oplus t` is close to :math:`a` and :math:`c \oplus t` is close -to :math:`c`. -(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d`, +to :math:`c.` +(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d,` but that isn't necessarily required for a valid attack.) A 4-round Feistel thwarts this and similar attacks. Defining :math:`x` and :math:`y` as the intermediate values in the first diagram above: -* if :math:`(x', y')` are fixed to the same values as :math:`(x, y)`, then - :math:`(a', b', c', d') = (a, b, c, d)`; +* if :math:`(x', y')` are fixed to the same values as :math:`(x, y),` then + :math:`(a', b', c', d') = (a, b, c, d);` -* if :math:`x' = x` but :math:`y' \neq y`, then the adversary is able to - introduce a controlled :math:`\oplus`-difference - :math:`a \oplus a' = y \oplus y'`, but the other three pieces +* if :math:`x' = x` but :math:`y' \neq y,` then the adversary is able to + introduce a controlled :math:`\oplus\!`-difference + :math:`a \oplus a' = y \oplus y',` but the other three pieces :math:`(b, c, d)` are all randomized, which is sufficient; -* if :math:`y' = y` but :math:`x' \neq x`, then the adversary is able to - introduce a controlled :math:`\oplus`-difference - :math:`d \oplus d' = x \oplus x'`, but the other three pieces +* if :math:`y' = y` but :math:`x' \neq x,` then the adversary is able to + introduce a controlled :math:`\oplus\!`-difference + :math:`d \oplus d' = x \oplus x',` but the other three pieces :math:`(a, b, c)` are all randomized, which is sufficient; -* if :math:`x' \neq x` and :math:`y' \neq y`, all four pieces are +* if :math:`x' \neq x` and :math:`y' \neq y,` all four pieces are randomized. Note that the size of each piece is at least 24 bytes. @@ -633,23 +634,24 @@ compressions for :math:`192 < \ell_M \leq 256,` for example. The maximum cost for which the algorithm is defined would be 196608 BLAKE2b compressions at :math:`\ell_M = 4194368` bytes. -A naïve implementation of the :math:`F4Jumble^{-1}` function would require -roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state. However, -it is possible to reduce this by streaming the :math:`d` part of the jumbled -encoding three times from a less memory-constrained device. It is essential -that the streamed value of :math:`d` is the same on each pass, which can be -verified using a MAC (with key held only by the Consumer) or +A naïve implementation of the :math:`\mathsf{F4Jumble}^{-1}` function would +require roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state. +However, it is possible to reduce this by streaming the :math:`d` part of +the jumbled encoding three times from a less memory-constrained device. It +is essential that the streamed value of :math:`d` is the same on each pass, +which can be verified using a MAC (with key held only by the Consumer) or collision-resistant hash function. After the first pass of :math:`d`, the -implementation is able to compute :math:`y`; after the second pass it is -able to compute :math:`a`; and the third allows it to compute and +implementation is able to compute :math:`y;` after the second pass it is +able to compute :math:`a;` and the third allows it to compute and incrementally parse :math:`b.` The maximum memory usage during this process would be 128 bytes (for the cached :math:`c` or :math:`y`), plus two BLAKE2b hash states. -Since this streaming implementation of :math:`F4Jumble^{-1}` is quite -complicated, we do not require all Consumers to support it. If a Consumer -implementation cannot support UAs / UVKs up to the maximum length, it MUST -nevertheless support UAs / UVKs with :math:`\ell_M` of at least 256 bytes. +Since this streaming implementation of :math:`\mathsf{F4Jumble}^{-1}` is +quite complicated, we do not require all Consumers to support it. If a +Consumer implementation cannot support UAs / UVKs up to the maximum length, +it MUST nevertheless support UAs / UVKs with :math:`\ell_M` of at least +:math:`256` bytes. Dependencies From 986b9dedfe3a339627df9b2ce0b7ae593b227db4 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 13:30:54 +0100 Subject: [PATCH 05/16] ZIP 316: Improve definitions, requirements, and specification for viewing keys. Signed-off-by: Daira Hopwood --- zip-0316.rst | 124 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 97 insertions(+), 27 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 32eca790..3891a305 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -44,8 +44,10 @@ Receiver Receiver Encoding An encoding of a Receiver as a byte sequence. Viewing Key - The necessary information to view information about a payments to an Address, - or (in the case of a Full Viewing Key) from an Address. + The necessary information to view information about payments to an Address, + or (in the case of a Full Viewing Key) from an Address. An Incoming Viewing + Key can be derived from a Full Viewing Key, and an Address can be derived + from an Incoming Viewing Key. Viewing Key Encoding An encoding of a Viewing Key as a byte sequence. Legacy Address @@ -260,16 +262,15 @@ 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 [#protocol-nu5]_. -Transparent Addresses do not have separate corresponding viewing keys, -but the address itself can effectively be used as a viewing key. -Therefore, a UFVK or UIVK should be able to include a Transparent Address. +For a Transparent P2PKH Address that is derived according to BIP 32 +[#bip-0032]_ and BIP 44 [#bip-0044]_, 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 Unified Address from a UFVK, by -deriving a Receiver from each Full Viewing Key in the UFVK. Any -Transparent Address in the UFVK is left as-is. - -It is not possible to derive a Unified Address from a Unified Incoming -Viewing Key. +A wallet should support deriving a UIVK from a UFVK, and a Unified +Address from a UIVK. Open Issues and Known Concerns @@ -338,8 +339,8 @@ or the :math:`160\!`-bit script hash of a P2SH address [#P2SH]_, or the Let ``padding`` be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append ``padding`` to the concatenated encodings, and then apply the :math:`\mathsf{F4Jumble}` -algorithm as described in `Address Hardening`_. The output is then encoded -with Bech32m [#bip-0350]_, ignoring any length restrictions. This is chosen +algorithm as described in `Jumbling`_. The output is then encoded with +Bech32m [#bip-0350]_, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs. To decode a Unified Address Encoding, a Consumer MUST use the following @@ -368,21 +369,44 @@ 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. The same Priority List and the -same Typecodes are used. The Priority List only applies to situations -in which a Consumer needs to choose a particular Receiver. +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 Shielded Addresses, the encoding used in place of the -:math:`\mathtt{addr}` field is the raw encoding of the Full Viewing Key -or Incoming Viewing Key. +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. -Transparent Addresses do not have separate corresponding viewing keys, -but the address itself can effectively be used as a viewing key. -Therefore, a UFVK or UIVK MAY include a Transparent Address, which -is encoded using the same Typecode and Receiver Encoding as in a -Unified Address. +The following UFVK or UIVK Encodings are used in place of the +:math:`\mathtt{addr}` field: -The Human-Readable Parts (as defined in [#bip-0350]) of Unified Viewing +* An Orchard UFVK or UIVK Encoding, with Typecode :math:`\mathtt{0x03},` + is the raw encoding of the Full Viewing Key or Incoming Viewing Key + respectively. + +* 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]_. + +* 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}).` + +* There is no defined way to represent a viewing key for a Transparent + P2SH Address in a UFVK or UIVK. The Typecode :math:`\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 + [#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]_. + +The Human-Readable Parts (as defined in [#bip-0350]_) of Unified Viewing Keys are defined as follows: * “``uivk``” for Unified Incoming Viewing Keys on Mainnet; @@ -406,6 +430,9 @@ Requirements for both Unified Addresses and Unified Viewing Keys 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. + * For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding. @@ -453,8 +480,44 @@ either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued. -Address hardening ------------------ +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. + + +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” + [#zip-0032-sapling-diversifier-derivation]_. +* A Transparent diversifier index MUST be in the range :math:`0` to + :math:`2^{31}` 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 +[#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: + +* :math:`m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.` + + +Jumbling +--------- Security goal (**near second preimage resistance**): @@ -696,9 +759,16 @@ References .. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ .. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. 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-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 `_ +.. [#bip-0032] `BIP 32: Hierarchical Deterministic Wallets `_ +.. [#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 `_ .. [#bip-0350] `BIP 350: Bech32m format for v1+ witness addresses `_ .. [#P2PKH] `Transactions: P2PKH Script Validation — Bitcoin Developer Guide `_ .. [#P2SH] `Transactions: P2SH Scripts — Bitcoin Developer Guide `_ From d6a32d4757fca7110f33a90e6d7ceaf7d1c633f9 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 13:38:32 +0100 Subject: [PATCH 06/16] ZIP 316: Resolve a TODO by punting to ZIP 315. 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 3891a305..9c083846 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -276,9 +276,8 @@ Address from a UIVK. Open Issues and Known Concerns ------------------------------ -TODO: We have a few of these that will be added in future edits. -This is especially true of privacy impacts of transparent or cross-pool -transactions and the associated UX issues. +Privacy impacts of transparent or cross-pool transactions, and the +associated UX issues, will be addressed in ZIP 315 (in preparation). Specification From 460c5b2ccc704b3ae05567585b87ac435510766d Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 13:39:28 +0100 Subject: [PATCH 07/16] ZIP 316: Require that `typecode` and `length` are <= 0x2000000. Signed-off-by: Daira Hopwood --- zip-0316.rst | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 9c083846..82198f39 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -331,6 +331,9 @@ of the consituent Receivers: * :math:`\mathtt{addr} : \mathtt{byte[length]}` — the Receiver Encoding. +The values of the :math:`\mathtt{typecode}` and :math:`\mathtt{length}` +fields MUST be less than or equal to :math:`\mathtt{0x2000000}.` + A Receiver Encoding is the raw encoding of a Shielded Payment Address, or the :math:`160\!`-bit script hash of a P2SH address [#P2SH]_, or the :math:`160\!`-bit validating key hash of a P2PKH address [#P2PKH]_. @@ -423,11 +426,11 @@ Requirements for both Unified Addresses and Unified Viewing Keys P2SH and P2PKH transparent-only address formats suffice for this purpose and are already supported by the existing ecosystem. -* The :math:`\mathtt{length}` field is encoded as a - :math:`\mathtt{compactSize}.` [#Bitcoin-CompactSize]_ (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.) +* The :math:`\mathtt{typecode}` and :math:`\mathtt{length}` fields are + encoded as :math:`\mathtt{compactSize}.` [#Bitcoin-CompactSize]_ + (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. From 2d20028ecf2105eb56ca8081f0714da678574d3f Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 13:40:59 +0100 Subject: [PATCH 08/16] ZIP 316: Remove an incorrect parenthetical about the memory usage of streamed unjumbling. Signed-off-by: Daira Hopwood --- zip-0316.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 82198f39..ed339be1 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -709,8 +709,7 @@ collision-resistant hash function. After the first pass of :math:`d`, the implementation is able to compute :math:`y;` after the second pass it is able to compute :math:`a;` and the third allows it to compute and incrementally parse :math:`b.` The maximum memory usage during this process -would be 128 bytes (for the cached :math:`c` or :math:`y`), plus two BLAKE2b -hash states. +would be 128 bytes plus two BLAKE2b hash states. Since this streaming implementation of :math:`\mathsf{F4Jumble}^{-1}` is quite complicated, we do not require all Consumers to support it. If a From ed4ba8d38b482fa35c56c04a4dafb986e2f77211 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 13:47:13 +0100 Subject: [PATCH 09/16] ZIP 316: Update references to the protocol spec and add reference to spec notation. Signed-off-by: Daira Hopwood --- zip-0316.rst | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index ed339be1..a73d519f 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -74,6 +74,9 @@ Address Encoding The externally visible encoding of an Address (e.g. as a string of characters or a QR code). +Notation for sequences, conversions, and arithmetic operations follows the +Zcash protocol specification [#protocol-notation]_. + Abstract ======== @@ -756,9 +759,10 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-nu5] `Zcash Protocol Specification, Version 2020.2.14 or later [NU5 proposal] `_ -.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ -.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses `_ +.. [#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 `_ .. [#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 a00006d7bd7ea1b9e8887a57f86718d18f3eba2b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 14:03:43 +0100 Subject: [PATCH 10/16] ZIP 316: Clarify conformance levels. Signed-off-by: Daira Hopwood --- zip-0316.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/zip-0316.rst b/zip-0316.rst index a73d519f..a836ffa9 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -718,7 +718,9 @@ Since this streaming implementation of :math:`\mathsf{F4Jumble}^{-1}` is quite complicated, we do not require all Consumers to support it. If a Consumer implementation cannot support UAs / UVKs up to the maximum length, it MUST nevertheless support UAs / UVKs with :math:`\ell_M` of at least -:math:`256` bytes. +:math:`256` bytes. Note that this effectively defines two conformance levels +to this specification. A full implementation will support UAs / UVKs up to +the maximum length. Dependencies From 067befbb0852e1e2c7b4dc765b1180c25a58390f Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 14:21:18 +0100 Subject: [PATCH 11/16] ZIP 316: The P2PKH extended public key format can be used in place of a P2PKH-only UFVK/UIVK. 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 a836ffa9..58686f0f 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -426,8 +426,9 @@ Requirements for both Unified Addresses and Unified Viewing Keys * A Unified Address or Unified Viewing Key MUST NOT contain only transparent P2SH or P2PKH addresses (Typecodes :math:`\mathtt{0x00}` and :math:`\mathtt{0x01}`). The rationale is that the existing - P2SH and P2PKH transparent-only address formats suffice for this - purpose and are already supported by the existing ecosystem. + P2SH and P2PKH transparent-only address formats, and the existing + P2PKH extended public key format, suffice for this purpose and are + already supported by the existing ecosystem. * The :math:`\mathtt{typecode}` and :math:`\mathtt{length}` fields are encoded as :math:`\mathtt{compactSize}.` [#Bitcoin-CompactSize]_ From 17229163f96dbc1b102657218a9dd1826bedd773 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 14:22:56 +0100 Subject: [PATCH 12/16] ZIP 316: Define a named constant \ell^MAX_M to replace the magic number 4194368. Also define \ell_H = 64. Signed-off-by: Daira Hopwood --- zip-0316.rst | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 58686f0f..dd318d0c 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -579,9 +579,13 @@ Let :math:`H_i` be a hash personalized by :math:`i,` with maximum output length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with extendable output length) based on :math:`H,` personalized by :math:`i.` +Define :math:`\ell^\mathsf{MAX}_M = (2^{16} + 1) \cdot \ell_H.` +For the instantiation using BLAKE2b defined below, +:math:`\ell^\mathsf{MAX}_M = 4194368.` + Given input :math:`M` of length :math:`\ell_M` bytes such that -:math:`48 \leq \ell_M \leq 4194368,` define :math:`\mathsf{F4Jumble}(M)` -by: +:math:`48 \leq \ell_M \leq \ell^\mathsf{MAX}_M,` define +:math:`\mathsf{F4Jumble}(M)` by: * let :math:`\ell_L = \mathsf{min}(\ell_H, \mathsf{floor}(\ell_M/2))` * let :math:`\ell_R = \ell_M - \ell_L` @@ -599,7 +603,7 @@ The first argument to BLAKE2b below is the personalization. We instantiate :math:`H_i(u)` by :math:`\mathsf{BLAKE2b‐}(8\ell_L)(\texttt{“UA_F4Jumble_H”} \,||\,` -:math:`[i, 0, 0], u).` +:math:`[i, 0, 0], u),` with :math:`\ell_H = 64.` We instantiate :math:`G_i(u)` as the first :math:`\ell_R` bytes of the concatenation of @@ -627,14 +631,15 @@ zero bytes, to the raw encoding, then applies :math:`\mathsf{F4Jumble}` before encoding the result with Bech32m. The Consumer rejects any Bech32m-decoded byte sequence that is less than -48 bytes or greater than 4194368 bytes; otherwise it applies -:math:`\mathsf{F4Jumble}^{-1}.` It rejects any result that does not end -in the expected padding, before stripping these 16 bytes and parsing the -result. +48 bytes or greater than :math:`\ell^\mathsf{MAX}_M` bytes; otherwise it +applies :math:`\mathsf{F4Jumble}^{-1}.` It rejects any result that does +not end in the expected padding, before stripping these 16 bytes and +parsing the result. (48 bytes is the minimum size of a valid UA, UFVK, or UIVK raw encoding plus 16 zero bytes, corresponding to a single Sapling Incoming Viewing Key. -4194368 bytes is the largest input/output size supported by :math:`\mathsf{F4Jumble}.`) +:math:`\ell^\mathsf{MAX}_M` bytes is the largest input/output size +supported by :math:`\mathsf{F4Jumble}.`) Heuristic analysis '''''''''''''''''' @@ -701,7 +706,7 @@ For longer UAs (when other Typecodes are added), the cost increases to 6 BLAKE2b compressions for :math:`128 < \ell_M \leq 192,` and 10 BLAKE2b compressions for :math:`192 < \ell_M \leq 256,` for example. The maximum cost for which the algorithm is defined would be 196608 BLAKE2b compressions -at :math:`\ell_M = 4194368` bytes. +at :math:`\ell_M = \ell^\mathsf{MAX}_M` bytes. A naïve implementation of the :math:`\mathsf{F4Jumble}^{-1}` function would require roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state. From 0e057c3c8cca37f80d9c6ad10ee9c3030f14a9e1 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 14:33:50 +0100 Subject: [PATCH 13/16] ZIP 316: Clarify that the experimental Typecodes are for use before proposing a ZIP. Signed-off-by: Daira Hopwood --- zip-0316.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index dd318d0c..738310b1 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -477,13 +477,13 @@ 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 [#zip-0000]_. -Experimental types MAY be added using the reserved Typecodes -:math:`\mathtt{0xFFFA}` to :math:`\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. +For experimentation prior to proposing a ZIP, experimental types MAY +be added using the reserved Typecodes :math:`\mathtt{0xFFFA}` to +:math:`\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. Deriving a UIVK from a UFVK From 39998c226c7b85d5c105a51c6d25938f19ed70f7 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 14:37:02 +0100 Subject: [PATCH 14/16] ZIP 316: Clarify wording for UFVK or UIVK Encoding, and the reason why P2SH UFVK/UIVKs are not supported. Signed-off-by: Daira Hopwood --- zip-0316.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index 738310b1..df6cca0c 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -389,8 +389,8 @@ The following UFVK or UIVK 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 Full Viewing Key or Incoming Viewing Key - respectively. + is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming + Viewing Key respectively. * A Sapling UFVK Encoding, with Typecode :math:`\mathtt{0x02},` is the encoding of a Sapling Extended Full Viewing Key defined in @@ -400,9 +400,10 @@ The following UFVK or UIVK Encodings are used in place of the is an encoding of :math:`(\mathsf{dk}, \mathsf{ivk})` given by :math:`\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).` -* There is no defined way to represent a viewing key for a Transparent - P2SH Address in a UFVK or UIVK. The Typecode :math:`\mathtt{0x01}` - MUST not be included in a UFVK or UIVK by Producers, and MUST be +* 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 :math:`\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 From 96277a1a1490d89f79744d489c1ca700538497c2 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 15:30:56 +0100 Subject: [PATCH 15/16] ZIP 316: Expand "Message Authentication Code", and a wording improvement. Signed-off-by: Daira Hopwood --- zip-0316.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/zip-0316.rst b/zip-0316.rst index df6cca0c..4512ec6c 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -714,15 +714,15 @@ require roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state. However, it is possible to reduce this by streaming the :math:`d` part of the jumbled encoding three times from a less memory-constrained device. It is essential that the streamed value of :math:`d` is the same on each pass, -which can be verified using a MAC (with key held only by the Consumer) or -collision-resistant hash function. After the first pass of :math:`d`, the -implementation is able to compute :math:`y;` after the second pass it is -able to compute :math:`a;` and the third allows it to compute and -incrementally parse :math:`b.` The maximum memory usage during this process -would be 128 bytes plus two BLAKE2b hash states. +which can be verified using a Message Authentication Code (with key held +only by the Consumer) or collision-resistant hash function. After the first +pass of :math:`d`, the implementation is able to compute :math:`y;` after +the second pass it is able to compute :math:`a;` and the third allows it to +compute and incrementally parse :math:`b.` The maximum memory usage during +this process would be 128 bytes plus two BLAKE2b hash states. Since this streaming implementation of :math:`\mathsf{F4Jumble}^{-1}` is -quite complicated, we do not require all Consumers to support it. If a +quite complicated, we do not require all Consumers to support streaming. If a Consumer implementation cannot support UAs / UVKs up to the maximum length, it MUST nevertheless support UAs / UVKs with :math:`\ell_M` of at least :math:`256` bytes. Note that this effectively defines two conformance levels From f8529b31861524d382a414dc8138423009294690 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 17 Sep 2021 15:35:50 +0100 Subject: [PATCH 16/16] ZIP 316: Regenerate HTML. Signed-off-by: Daira Hopwood --- zip-0316.html | 405 ++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 293 insertions(+), 112 deletions(-) diff --git a/zip-0316.html b/zip-0316.html index dc9fa2f0..e6c86c8a 100644 --- a/zip-0316.html +++ b/zip-0316.html @@ -28,16 +28,20 @@ Discussions-To: <https://g
Recipient
A wallet or other software that can receive transfers of assets (such as ZEC) or in the future potentially other transaction-based state changes.
Producer
-
A wallet or other software that can create an Address (normally also a Recipient).
+
A wallet or other software that can create an Address (in which case it is normally also a Recipient) or a Viewing Key.
Consumer
-
A wallet or other software that can make use of an Address that it is given.
+
A wallet or other software that can make use of an Address or Viewing Key that it is given.
Sender
A wallet or other software that can send transfers of assets, or other consensus state side-effects defined in future. Senders are a subset of Consumers.
Receiver
The necessary information to transfer an asset to a Recipient that generated that Receiver using a specific Transfer Protocol. Each Receiver is associated unambiguously with a specific Receiver Type, identified by an integer Typecode.
Receiver Encoding
An encoding of a Receiver as a byte sequence.
-
Legacy Address (or LA)
+
Viewing Key
+
The necessary information to view information about payments to an Address, or (in the case of a Full Viewing Key) from an Address. An Incoming Viewing Key can be derived from a Full Viewing Key, and an Address can be derived from an Incoming Viewing Key.
+
Viewing Key Encoding
+
An encoding of a Viewing Key as a byte sequence.
+
Legacy Address
A Transparent, Sprout, or Sapling Address.
Unified Address (or UA)
A Unified Address combines multiple Receivers.
@@ -45,6 +49,8 @@ Discussions-To: <https://g
A Unified Full Viewing Key combines multiple Full Viewing Keys.
Unified Incoming Viewing Key (or UIVK)
A Unified Incoming Viewing Key combines multiple Incoming Viewing Keys.
+
Unified Viewing Key
+
Either a Unified Full Viewing Key or a Unified Incoming Viewing Key.
Address
Either a Legacy Address or a Unified Address.
Transfer Protocol
@@ -52,6 +58,7 @@ Discussions-To: <https://g
Address Encoding
The externally visible encoding of an Address (e.g. as a string of characters or a QR code).
+

Notation for sequences, conversions, and arithmetic operations follows the Zcash protocol specification 3.

Abstract

This proposal defines Unified Addresses, which bundle together Zcash Addresses of different types in a way that can be presented as a single Address Encoding. It also defines Unified Viewing Keys, which perform a similar function for Zcash viewing keys.

@@ -64,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 6 adds a new Address type, Orchard Addresses.

    +

    The Orchard proposal 10 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:

      @@ -83,7 +90,7 @@ Discussions-To: <https://g

      Overview

      Unified Addresses specify multiple methods for payment to a Recipient's Wallet. The Sender's Wallet can then non-interactively select the method of payment.

      Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending.

      -

      Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs 7 and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type.

      +

      Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs 11 and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type.

      Concepts

      Wallets follow a model Interaction Flow as follows:

      @@ -103,15 +110,15 @@ Discussions-To: <https://g

      When new Transport Protocols are introduced to the Zcash protocol after Unified Addresses are standardized, those should introduce new Receiver Types but not different Address types outside of the UA standard. There needs to be a compelling reason to deviate from the standard, since the benefits of UA come precisely from their applicability across all new protocol upgrades.

      Receivers

      -

      Every Wallet must properly parse a Unified Address containing unrecognized Receiver Types; and similarly for Unified Full Viewing Keys and Unified Incoming Viewing Keys.

      -

      A Wallet may process unrecognized Receiver Types by indicating to the user their presence or similar information for usability or diagnostic purposes.

      +

      Every Wallet must properly parse a Unified Address containing unrecognized Receiver Types; and similarly for Unified Viewing Keys containing unrecognized Viewing Key Types.

      +

      A Wallet may process unrecognized Receiver Types or Viewing Key Types by indicating to the user their presence or similar information for usability or diagnostic purposes.

      Transport Encoding

      The string encoding is “opaque” to human readers: it does not allow visual identification of which Receivers or Receiver Types are present.

      The string encoding is resilient against typos, transcription errors, cut-and-paste errors, unanticipated truncation, or other anticipated UX hazards.

      There is a well-defined encoding of a Unified Address (or UFVK or UIVK) as a QR Code, which produces QR codes that are reasonably compact and robust.

      There is a well-defined transformation between the QR Code and string encodings in either direction.

      -

      The string encoding fits into ZIP-321 Payment URIs 7 and general URIs without introducing parse ambiguities.

      +

      The string encoding fits into ZIP-321 Payment URIs 11 and general URIs without introducing parse ambiguities.

      The encoding must support sufficiently many Recipient Types to allow for reasonable future expansion.

      The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them.

      @@ -124,14 +131,16 @@ Discussions-To: <https://g
    • This property also allows Transparent-Only wallets to upgrade to shielded support without re-acquiring counterparty UAs. If they are re-acquired, the user flow and usability will be minimally disrupted.
    +

    Experimental Usage

    +

    Unified Addresses and Unified Viewing Keys must be able to include Receivers and Viewing Keys of experimental types, possibly alongside non-experimental ones. These experimental Receivers or Viewing Keys must be used only by wallets whose users have explicitly opted into the corresponding experiment.

    +

    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.

    -

    Transparent Addresses do not have separate corresponding viewing keys, but the address itself can effectively be used as a viewing key. Therefore, a UFVK or UIVK should be able to include a Transparent Address.

    -

    A wallet should support deriving a Unified Address from a UFVK, by deriving a Receiver from each Full Viewing Key in the UFVK. Any Transparent Address in the UFVK is left as-is.

    -

    It is not possible to derive a Unified Address from a Unified Incoming Viewing Key.

    +

    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.

    +

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

    Open Issues and Known Concerns

    -

    TODO: We have a few of these that will be added in future edits. This is especially true of privacy impacts of transparent or cross-pool transactions and the associated UX issues.

    +

    Privacy impacts of transparent or cross-pool transactions, and the associated UX issues, will be addressed in ZIP 315 (in preparation).

    Specification

    @@ -141,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. The same Priority List and the same Typecodes are used. The Priority List only applies to situations in which a Consumer needs to choose a particular Receiver.

    -

    For Shielded Addresses, the encoding used in place of the +

    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 \(\mathtt{addr}\) - field is the raw encoding of the Full Viewing Key or Incoming Viewing Key.

    -

    Transparent Addresses do not have separate corresponding viewing keys, but the address itself can effectively be used as a viewing key. Therefore, a UFVK or UIVK MAY include a Transparent Address, which is encoded using the same Typecode and Receiver Encoding as in a Unified Address.

    -

    The Human-Readable Parts (as defined in [#bip-0350]) of Unified Viewing Keys are defined as follows:

    + field:

    +
      +
    • An Orchard UFVK or UIVK 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 + \(\mathtt{0x02},\) + is the encoding of a Sapling Extended Full Viewing Key defined in 7.
      • +
    • A Sapling UIVK Encoding, also with Typecode + \(\mathtt{0x02},\) + is an encoding of + \((\mathsf{dk}, \mathsf{ivk})\) + given by + \(\mathsf{I2LEOSP}_{88}(\mathsf{dk})\,||\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk}).\) +
      • +
    • 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 + \(\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.
      • +
    +

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

    -

    Address hardening

    +

    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.

    +

    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.

    +
    +

    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.

    +
    +

    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 Transparent diversifier index MUST be in the range + \(0\) + to + \(2^{31}\) + 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}.\) +
      • +
    +
    +

    Jumbling

    Security goal (near second preimage resistance):

    Heuristic analysis

    A 3-round unkeyed Feistel, as shown, is not sufficient:

    @@ -381,14 +461,14 @@ c^{n+m}}{q}\)
    Diagram of 3-round unkeyed Feistel construction

    Suppose that an adversary has a target input/output pair - \((a \,||\, b, c \,||\, d)\) - , and that the input to + \((a \,||\, b, c \,||\, d),\) + and that the input to \(H_0\) is - \(x\) - . By fixing - \(x\) - , we can obtain another pair + \(x.\) + By fixing + \(x,\) + we can obtain another pair \(((a \oplus t) \,||\, b', (c \oplus t) \,||\, d')\) such that \(a \oplus t\) @@ -397,16 +477,16 @@ c^{n+m}}{q}\) and \(c \oplus t\) is close to - \(c\) - . ( + \(c.\) + ( \(b'\) and \(d'\) will not be close to \(b\) and - \(d\) - , but that isn't necessarily required for a valid attack.)

    + \(d,\) + but that isn't necessarily required for a valid attack.)

    A 4-round Feistel thwarts this and similar attacks. Defining \(x\) and @@ -416,37 +496,37 @@ c^{n+m}}{q}\)

  • if \((x', y')\) are fixed to the same values as - \((x, y)\) - , then - \((a', b', c', d') = (a, b, c, d)\) - ;
    • + \((x, y),\) + then + \((a', b', c', d') = (a, b, c, d);\) +
  • if \(x' = x\) but - \(y' \neq y\) - , then the adversary is able to introduce a controlled - \(\oplus\) + \(y' \neq y,\) + then the adversary is able to introduce a controlled + \(\oplus\!\) -difference - \(a \oplus a' = y \oplus y'\) - , but the other three pieces + \(a \oplus a' = y \oplus y',\) + but the other three pieces \((b, c, d)\) are all randomized, which is sufficient;
  • if \(y' = y\) but - \(x' \neq x\) - , then the adversary is able to introduce a controlled - \(\oplus\) + \(x' \neq x,\) + then the adversary is able to introduce a controlled + \(\oplus\!\) -difference - \(d \oplus d' = x \oplus x'\) - , but the other three pieces + \(d \oplus d' = x \oplus x',\) + but the other three pieces \((a, b, c)\) are all randomized, which is sufficient;
  • if \(x' \neq x\) and - \(y' \neq y\) - , all four pieces are randomized.
    • + \(y' \neq y,\) + all four pieces are randomized.

    Note that the size of each piece is at least 24 bytes.

    It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.

    @@ -459,15 +539,36 @@ c^{n+m}}{q}\) \(\ell_M = 128\) bytes. The restriction to a single Address with a given Typecode (and at most one Transparent Address) means that this is also the maximum length as of NU5 activation.

    For longer UAs (when other Typecodes are added), the cost increases to 6 BLAKE2b compressions for - \(128 < \ell_M \leq 192\) - , and 10 BLAKE2b compressions for - \(192 < \ell_M \leq 256\) - , for example. The maximum cost for which the algorithm is defined would be 768 BLAKE2b compressions at - \(\ell_M = 16448\) - bytes. We will almost certainly never add enough Typecodes to reach that, and we might want to define a smaller limit.

    -

    The memory usage, for a memory-optimized implementation, is roughly + \(128 < \ell_M \leq 192,\) + and 10 BLAKE2b compressions for + \(192 < \ell_M \leq 256,\) + for example. The maximum cost for which the algorithm is defined would be 196608 BLAKE2b compressions at + \(\ell_M = \ell^\mathsf{MAX}_M\) + bytes.

    +

    A naïve implementation of the + \(\mathsf{F4Jumble}^{-1}\) + function would require roughly \(\ell_M\) - bytes plus the size of a BLAKE2b hash state.

    + bytes plus the size of a BLAKE2b hash state. However, it is possible to reduce this by streaming the + \(d\) + part of the jumbled encoding three times from a less memory-constrained device. It is essential that the streamed value of + \(d\) + is the same on each pass, which can be verified using a Message Authentication Code (with key held only by the Consumer) or collision-resistant hash function. After the first pass of + \(d\) + , the implementation is able to compute + \(y;\) + after the second pass it is able to compute + \(a;\) + and the third allows it to compute and incrementally parse + \(b.\) + The maximum memory usage during this process would be 128 bytes plus two BLAKE2b hash states.

    +

    Since this streaming implementation of + \(\mathsf{F4Jumble}^{-1}\) + is quite complicated, we do not require all Consumers to support streaming. If a Consumer implementation cannot support UAs / UVKs up to the maximum length, it MUST nevertheless support UAs / UVKs with + \(\ell_M\) + of at least + \(256\) + bytes. Note that this effectively defines two conformance levels to this specification. A full implementation will support UAs / UVKs up to the maximum length.

    Dependencies

    BLAKE2b, with personalization and variable output length, is the only external dependency.

    @@ -489,7 +590,7 @@ c^{n+m}}{q}\)

    Acknowledgements

    -

    The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre, Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, and Teor for discussions on the subject of Unified Addresses.

    +

    The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre, Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, Teor, and Eran Tromer for discussions on the subject of Unified Addresses.

    References

    @@ -504,30 +605,62 @@ c^{n+m}}{q}\) - + + + +
    2Zcash Protocol Specification, Version 2020.1.24 or later [NU5 proposal]Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal]
    + + + + +
    3Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal]. Section 2: Notation
    - - + +
    3Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses4Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses
    - - + + + + +
    4Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses5Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses
    + + + + + + + +
    6ZIP 0: ZIP Process
    + + + + + + + +
    7ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys
    + + + + +
    8ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation
    - + @@ -535,7 +668,7 @@ c^{n+m}}{q}\)
    59 ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool
    - + @@ -543,15 +676,55 @@ c^{n+m}}{q}\)
    610 ZIP 224: Orchard Shielded Protocol
    - +
    711 ZIP 321: Payment Request URIs
    + + + + + + + +
    12BIP 32: Hierarchical Deterministic Wallets
    + + + + + + + +
    13BIP 32: Hierarchical Deterministic Wallets — Serialization Format
    + + + + + + + +
    14BIP 32: Hierarchical Deterministic Wallets — Child key derivation (CKD) functions: Public parent key → public child key
    + + + + + + + +
    15BIP 44: Multi-Account Hierarchy for Deterministic Wallets
    + + + + + + + +
    16BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Index
    - + @@ -559,7 +732,7 @@ c^{n+m}}{q}\)
    817 BIP 350: Bech32m format for v1+ witness addresses
    - + @@ -567,11 +740,19 @@ c^{n+m}}{q}\)
    918 Transactions: P2PKH Script Validation — Bitcoin Developer Guide
    - +
    1019 Transactions: P2SH Scripts — Bitcoin Developer Guide
    + + + + + + + +
    20Variable length integer. Bitcoin Wiki