mirror of https://github.com/zcash/zips.git
ZIPs 32 and 316: Regenerate HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
4a23875519
commit
12a1678681
|
|
@ -44,7 +44,7 @@ License: MIT</pre>
|
|||
<li>Wallets only need to store a single seed (particularly useful for hardware wallets).</li>
|
||||
<li>A one-time backup of the seed (usually stored as a word phrase <a id="id8" class="footnote_reference" href="#bip-0039">3</a>) can be used to recover funds from all future addresses.</li>
|
||||
<li>Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.</li>
|
||||
<li>View authority or spend authority can be delegated independently for sub-trees without compromising the master seed.</li>
|
||||
<li>Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.</li>
|
||||
</ul>
|
||||
<p>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.</p>
|
||||
</section>
|
||||
|
|
@ -670,7 +670,7 @@ License: MIT</pre>
|
|||
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.</li>
|
||||
<li>
|
||||
<span class="math">\(coin\_type\)</span>
|
||||
: 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 <a id="id21" class="footnote_reference" href="#slip-0044">6</a>. 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 <a id="id21" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cryptocurrency testnets share
|
||||
<span class="math">\(coin\_type\)</span>
|
||||
index
|
||||
<span class="math">\(1\)</span>
|
||||
|
|
@ -707,6 +707,11 @@ License: MIT</pre>
|
|||
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p><cite>zcashd</cite> version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account
|
||||
<span class="math">\(\mathtt{0x7FFFFFFF}\)</span>
|
||||
, using hardened derivation for
|
||||
<span class="math">\(address\_index\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="sprout-key-path"><h3><span class="section-heading">Sprout key path</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-key-path"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Wallets implementing Sprout ZIP 32 derivation MUST support the following path:</p>
|
||||
|
|
|
|||
194
zip-0316.html
194
zip-0316.html
|
|
@ -71,7 +71,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>Sapling Addresses</li>
|
||||
</ul>
|
||||
<p>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.)</p>
|
||||
<p>The Orchard proposal <a id="id3" class="footnote_reference" href="#zip-0224">10</a> adds a new Address type, Orchard Addresses.</p>
|
||||
<p>The Orchard proposal <a id="id3" class="footnote_reference" href="#zip-0224">18</a> adds a new Address type, Orchard Addresses.</p>
|
||||
<p>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.</p>
|
||||
<p>The goals for a Unified Address standard are as follows:</p>
|
||||
<ul>
|
||||
|
|
@ -90,7 +90,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<section id="overview"><h3><span class="section-heading">Overview</span><span class="section-anchor"> <a rel="bookmark" href="#overview"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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.</p>
|
||||
<p>Importantly, any wallet can support Unified Addresses, even when that wallet only supports a subset of payment methods for receiving and/or sending.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="id4" class="footnote_reference" href="#zip-0321">11</a> and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="id4" class="footnote_reference" href="#zip-0321">19</a> and similar schemes, and the Unified Address format is likely to be incorporated into such schemes as a new Address type.</p>
|
||||
</section>
|
||||
<section id="concepts"><h3><span class="section-heading">Concepts</span><span class="section-anchor"> <a rel="bookmark" href="#concepts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Wallets follow a model <em>Interaction Flow</em> as follows:</p>
|
||||
|
|
@ -118,7 +118,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<p>The string encoding is resilient against typos, transcription errors, cut-and-paste errors, unanticipated truncation, or other anticipated UX hazards.</p>
|
||||
<p>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.</p>
|
||||
<p>There is a well-defined transformation between the QR Code and string encodings in either direction.</p>
|
||||
<p>The string encoding fits into ZIP-321 Payment URIs <a id="id5" class="footnote_reference" href="#zip-0321">11</a> and general URIs without introducing parse ambiguities.</p>
|
||||
<p>The string encoding fits into ZIP-321 Payment URIs <a id="id5" class="footnote_reference" href="#zip-0321">19</a> and general URIs without introducing parse ambiguities.</p>
|
||||
<p>The encoding must support sufficiently many Recipient Types to allow for reasonable future expansion.</p>
|
||||
<p>The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them.</p>
|
||||
</section>
|
||||
|
|
@ -136,7 +136,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</section>
|
||||
<section id="viewing-keys"><h3><span class="section-heading">Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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 <a id="id6" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
|
||||
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="id7" class="footnote_reference" href="#bip-0032">12</a> and BIP 44 <a id="id8" class="footnote_reference" href="#bip-0044">15</a>, 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.</p>
|
||||
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="id7" class="footnote_reference" href="#bip-0032">20</a> and BIP 44 <a id="id8" class="footnote_reference" href="#bip-0044">23</a>, 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.</p>
|
||||
<p>A wallet should support deriving a UIVK from a UFVK, and a Unified Address from a UIVK.</p>
|
||||
</section>
|
||||
<section id="open-issues-and-known-concerns"><h3><span class="section-heading">Open Issues and Known Concerns</span><span class="section-anchor"> <a rel="bookmark" href="#open-issues-and-known-concerns"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -150,10 +150,10 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<ul>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x03}\)</span>
|
||||
— an Orchard raw address as defined in <a id="id9" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">5</a>;</li>
|
||||
— an Orchard raw address as defined in <a id="id9" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">7</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
— a Sapling raw address as defined in <a id="id10" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">4</a>;</li>
|
||||
— a Sapling raw address as defined in <a id="id10" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">6</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
— a Transparent P2SH address, <em>or</em> Typecode
|
||||
|
|
@ -188,12 +188,12 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</p>
|
||||
<p>A Receiver Encoding is the raw encoding of a Shielded Payment Address, or the
|
||||
<span class="math">\(160\!\)</span>
|
||||
-bit script hash of a P2SH address <a id="id11" class="footnote_reference" href="#p2sh">19</a>, or the
|
||||
-bit script hash of a P2SH address <a id="id11" class="footnote_reference" href="#p2sh">27</a>, or the
|
||||
<span class="math">\(160\!\)</span>
|
||||
-bit validating key hash of a P2PKH address <a id="id12" class="footnote_reference" href="#p2pkh">18</a>.</p>
|
||||
-bit validating key hash of a P2PKH address <a id="id12" class="footnote_reference" href="#p2pkh">26</a>.</p>
|
||||
<p>Let <code>padding</code> be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append <code>padding</code> to the concatenated encodings, and then apply the
|
||||
<span class="math">\(\mathsf{F4Jumble}\)</span>
|
||||
algorithm as described in <a href="#jumbling">Jumbling</a>. The output is then encoded with Bech32m <a id="id13" class="footnote_reference" href="#bip-0350">17</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
algorithm as described in <a href="#jumbling">Jumbling</a>. The output is then encoded with Bech32m <a id="id13" class="footnote_reference" href="#bip-0350">25</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
<p>To decode a Unified Address Encoding, a Consumer MUST use the following procedure:</p>
|
||||
<ul>
|
||||
<li>Decode using Bech32m, rejecting any address with an incorrect checksum.</li>
|
||||
|
|
@ -203,23 +203,29 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>Let <code>padding</code> be the Human-Readable Part, padded to 16 bytes as for encoding. If the result ends in <code>padding</code>, remove these 16 bytes; otherwise reject.</li>
|
||||
<li>Parse the result as a raw encoding as described above, rejecting the entire Unified Address if it does not parse correctly.</li>
|
||||
</ul>
|
||||
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id14" class="footnote_reference" href="#bip-0350">17</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
|
||||
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id14" class="footnote_reference" href="#bip-0350">25</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
|
||||
<p>A wallet MAY allow its user(s) to configure which Receiver Types it can send to. It MUST NOT allow the user(s) to change the order of the Priority List used to choose the Receiver Type.</p>
|
||||
</section>
|
||||
<section id="encoding-of-unified-full-incoming-viewing-keys"><h3><span class="section-heading">Encoding of Unified Full/Incoming Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-full-incoming-viewing-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>The following UFVK or UIVK Encodings are used in place of the
|
||||
<p>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.</p>
|
||||
<p>The following FVK or IVK Encodings are used in place of the
|
||||
<span class="math">\(\mathtt{addr}\)</span>
|
||||
field:</p>
|
||||
<ul>
|
||||
<li>An Orchard UFVK or UIVK Encoding, with Typecode
|
||||
<li>An Orchard FVK or IVK Encoding, with Typecode
|
||||
<span class="math">\(\mathtt{0x03},\)</span>
|
||||
is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively.</li>
|
||||
<li>A Sapling UFVK Encoding, with Typecode
|
||||
is is the raw encoding of the Orchard Full Viewing Key or Orchard Incoming Viewing Key respectively.</li>
|
||||
<li>A Sapling FVK Encoding, with Typecode
|
||||
<span class="math">\(\mathtt{0x02},\)</span>
|
||||
is the encoding of a Sapling Extended Full Viewing Key defined in <a id="id15" class="footnote_reference" href="#zip-0032-sapling-extfvk">7</a>.</li>
|
||||
<li>A Sapling UIVK Encoding, also with Typecode
|
||||
is the encoding of
|
||||
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)</span>
|
||||
given by
|
||||
<span class="math">\(\mathsf{EncodeExtFVKParts}(\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\)</span>
|
||||
, where
|
||||
<span class="math">\(\mathsf{EncodeExtFVKParts}\)</span>
|
||||
is defined in <a id="id15" class="footnote_reference" href="#zip-0032-sapling-helper-functions">11</a>. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.</li>
|
||||
<li>A Sapling IVK Encoding, also with Typecode
|
||||
<span class="math">\(\mathtt{0x02},\)</span>
|
||||
is an encoding of
|
||||
<span class="math">\((\mathsf{dk}, \mathsf{ivk})\)</span>
|
||||
|
|
@ -229,11 +235,19 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>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
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
MUST NOT be included in a UFVK or UIVK by Producers, and MUST be treated as unrecognized by Consumers.</li>
|
||||
<li>For Transparent P2PKH Addresses that are derived according to BIP 32 <a id="id16" class="footnote_reference" href="#bip-0032">12</a> and BIP 44 <a id="id17" class="footnote_reference" href="#bip-0044">15</a>, the UFVK and UIVK Encodings have Typecode
|
||||
<li>For Transparent P2PKH Addresses that are derived according to BIP 32 <a id="id16" class="footnote_reference" href="#bip-0032">20</a> and BIP 44 <a id="id17" class="footnote_reference" href="#bip-0044">23</a>, the FVK and IVK Encodings have Typecode
|
||||
<span class="math">\(\mathtt{0x00}.\)</span>
|
||||
These encodings are identical and are the serialization of an extended public key, defined in the section “Serialization format” of BIP 32 <a id="id18" class="footnote_reference" href="#bip-0032-serialization-format">13</a>.</li>
|
||||
Both of these are encodings of the chain code and public key
|
||||
<span class="math">\((\mathsf{c}, \mathsf{pk})\)</span>
|
||||
given by
|
||||
<span class="math">\(\mathsf{c}\,||\,\mathsf{ser_P}(\mathsf{pk})\)</span>
|
||||
. (This is the same as the last 65 bytes of the extended public key format defined in section “Serialization format” of BIP 32 <a id="id18" class="footnote_reference" href="#bip-0032-serialization-format">21</a>.) However, the FVK uses the key at the Account level, i.e. at path
|
||||
<span class="math">\(m / 44' / coin\_type' / account'\)</span>
|
||||
, while the IVK uses the external (non-change) child key at the Change level, i.e. at path
|
||||
<span class="math">\(m / 44' / coin\_type' / account' / 0\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>The Human-Readable Parts (as defined in <a id="id19" class="footnote_reference" href="#bip-0350">17</a>) of Unified Viewing Keys are defined as follows:</p>
|
||||
<p>The Human-Readable Parts (as defined in <a id="id19" class="footnote_reference" href="#bip-0350">25</a>) of Unified Viewing Keys are defined as follows:</p>
|
||||
<ul>
|
||||
<li>“<code>uivk</code>” for Unified Incoming Viewing Keys on Mainnet;</li>
|
||||
<li>“<code>uivktest</code>” for Unified Incoming Viewing Keys on Testnet;</li>
|
||||
|
|
@ -254,10 +268,10 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathtt{length}\)</span>
|
||||
fields are encoded as
|
||||
<span class="math">\(\mathtt{compactSize}.\)</span>
|
||||
<a id="id20" class="footnote_reference" href="#bitcoin-compactsize">20</a> (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.)</li>
|
||||
<li>Each Receiver, UFVK, or UIVK SHOULD represent an Address or Viewing Key at the ZIP 32 or BIP 44 Account level.</li>
|
||||
<a id="id20" class="footnote_reference" href="#bitcoin-compactsize">28</a> (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.)</li>
|
||||
<li>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).</li>
|
||||
<li>For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding.</li>
|
||||
<li>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 <a id="id21" class="footnote_reference" href="#zip-0211">9</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>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 <a id="id21" class="footnote_reference" href="#zip-0211">17</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>Consumers MUST ignore constituent Addresses/Viewing Keys with Typecodes they do not recognize.</li>
|
||||
<li>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.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent address does not meet the validation requirements of its Receiver Encoding, as specified in the Zcash Protocol Specification <a id="id22" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
|
||||
|
|
@ -266,33 +280,39 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</ul>
|
||||
</section>
|
||||
<section id="adding-new-types"><h3><span class="section-heading">Adding new types</span><span class="section-anchor"> <a rel="bookmark" href="#adding-new-types"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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 <a id="id23" class="footnote_reference" href="#zip-0000">6</a>.</p>
|
||||
<p>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 <a id="id23" class="footnote_reference" href="#zip-0000">10</a>.</p>
|
||||
<p>For experimentation prior to proposing a ZIP, experimental types MAY be added using the reserved Typecodes
|
||||
<span class="math">\(\mathtt{0xFFFA}\)</span>
|
||||
to
|
||||
<span class="math">\(\mathtt{0xFFFF}\)</span>
|
||||
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.</p>
|
||||
<p>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).</p>
|
||||
</section>
|
||||
<section id="deriving-a-uivk-from-a-ufvk"><h3><span class="section-heading">Deriving a UIVK from a UFVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-uivk-from-a-ufvk"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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.</p>
|
||||
<p>The following derivations are applied to each component FVK:</p>
|
||||
<ul>
|
||||
<li>For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard FVK, the corresponding Orchard IVK is obtained as specified in <a id="id25" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH FVK, the corresponding Transparent P2PKH IVK is obtained by deriving the child key with non-hardened index
|
||||
<span class="math">\(0\)</span>
|
||||
as described in <a id="id26" class="footnote_reference" href="#bip-0032-public-to-public">22</a>.</li>
|
||||
</ul>
|
||||
<p>In each case, the Typecode remains the same as in the FVK.</p>
|
||||
</section>
|
||||
<section id="deriving-a-unified-address-from-a-uivk"><h3><span class="section-heading">Deriving a Unified Address from a UIVK</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-a-unified-address-from-a-uivk"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>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,</p>
|
||||
<ul>
|
||||
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="id24" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">8</a>.</li>
|
||||
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="id27" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">13</a>.</li>
|
||||
<li>A Transparent diversifier index MUST be in the range
|
||||
<span class="math">\(0\)</span>
|
||||
to
|
||||
<span class="math">\(2^{31}\)</span>
|
||||
<span class="math">\(2^{31} - 1\)</span>
|
||||
inclusive.</li>
|
||||
</ul>
|
||||
<p>There are no additional constraints on an Orchard diversifier index.</p>
|
||||
<p>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 <a id="id25" class="footnote_reference" href="#bip-0032-public-to-public">14</a> MUST be used, with the Change element of the path being 0, and the Index element of the path being the diversifier index <a id="id26" class="footnote_reference" href="#bip-0044-path-index">16</a>. That is, the BIP 44 path of the Transparent P2PKH Receiver MUST be:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.\)</span>
|
||||
</li>
|
||||
</ul>
|
||||
<p>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 <a id="id28" class="footnote_reference" href="#bip-0044-path-index">24</a> to derive the address. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation <a id="id29" class="footnote_reference" href="#bip-0032-public-to-public">22</a> 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
|
||||
<span class="math">\(m / 44' / \mathit{coin\_type\kern0.05em'} / \mathit{account\kern0.1em'} / 0 / \mathit{diversifier\_index}.\)</span>
|
||||
</p>
|
||||
</section>
|
||||
<section id="jumbling"><h3><span class="section-heading">Jumbling</span><span class="section-anchor"> <a rel="bookmark" href="#jumbling"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Security goal (<strong>near second preimage resistance</strong>):</p>
|
||||
|
|
@ -605,7 +625,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal]</a></td>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.2.16 or later [NU5 proposal]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -613,38 +633,78 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf#notation">Zcash Protocol Specification, Version 2020.2.15 or later [NU5 proposal]. Section 2: Notation</a></td>
|
||||
<td><a href="protocol/protocol.pdf#notation">Zcash Protocol Specification, Version 2020.2.16. Section 2: Notation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingkeycomponents" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2020.2.16. Section 4.2.2: Sapling Key Components</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardkeycomponents" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2020.2.16. Section 4.2.3: Orchard Key Components</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses</a></td>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2020.2.16. Section 5.6.3.1: Sapling Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2020.2.15 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses</a></td>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.2: Orchard Raw Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardinviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardfullviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.2.16. Section 5.6.4.4: Orchard Raw Full Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0000" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0000">ZIP 0: ZIP Process</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-sapling-helper-functions" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="zip-0032#sapling-helper-functions">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-sapling-extfvk" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<th>12</th>
|
||||
<td><a href="zip-0032#sapling-extended-full-viewing-keys">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -652,15 +712,39 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-diversifier-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<th>13</th>
|
||||
<td><a href="zip-0032#sapling-diversifier-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-orchard-child-key-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<td><a href="zip-0032#orchard-child-key-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-sapling-key-path" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<td><a href="zip-0032#sapling-key-path">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0032-orchard-key-path" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<td><a href="zip-0032#orchard-key-path">ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0211" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<th>17</th>
|
||||
<td><a href="zip-0211">ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -668,7 +752,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0224" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<th>18</th>
|
||||
<td><a href="zip-0224">ZIP 224: Orchard Shielded Protocol</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -676,7 +760,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0321" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<th>19</th>
|
||||
<td><a href="zip-0321">ZIP 321: Payment Request URIs</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -684,7 +768,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0032" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<th>20</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki">BIP 32: Hierarchical Deterministic Wallets</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -692,15 +776,15 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0032-serialization-format" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format">BIP 32: Hierarchical Deterministic Wallets — Serialization Format</a></td>
|
||||
<th>21</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format">BIP 32: Hierarchical Deterministic Wallets — Serialization Format</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0032-public-to-public" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<th>22</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#public-parent-key--public-child-key">BIP 32: Hierarchical Deterministic Wallets — Child key derivation (CKD) functions: Public parent key → public child key</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -708,7 +792,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0044" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<th>23</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki">BIP 44: Multi-Account Hierarchy for Deterministic Wallets</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -716,7 +800,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0044-path-index" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<th>24</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#index">BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Index</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -724,7 +808,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0350" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>17</th>
|
||||
<th>25</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki">BIP 350: Bech32m format for v1+ witness addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -732,7 +816,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="p2pkh" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>18</th>
|
||||
<th>26</th>
|
||||
<td><a href="https://developer.bitcoin.org/devguide/transactions.html#p2pkh-script-validation">Transactions: P2PKH Script Validation — Bitcoin Developer Guide</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -740,7 +824,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="p2sh" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>19</th>
|
||||
<th>27</th>
|
||||
<td><a href="https://developer.bitcoin.org/devguide/transactions.html#pay-to-script-hash-p2sh">Transactions: P2SH Scripts — Bitcoin Developer Guide</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -748,7 +832,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bitcoin-compactsize" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>20</th>
|
||||
<th>28</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer">Variable length integer. Bitcoin Wiki</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
Loading…
Reference in New Issue