mirror of https://github.com/zcash/zips.git
Merge pull request #764 from nuttycom/revert_316_r1
Revert "Merge pull request #759 from nuttycom/zip-316/ua-expiry"
This commit is contained in:
Conrado Gouvea
GitHub
commit
fee271c03d
246
zip-0316.html
246
zip-0316.html
|
|
@ -24,7 +24,7 @@ Created: 2021-04-07
|
|||
License: MIT
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://github.com/zcash/zips/issues/482</a>></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
|
||||
<p>The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>Recipient</dt>
|
||||
|
|
@ -67,8 +67,6 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<dd>An encoding of a UA/UVK as a QR code, intended for display and transfer by Zcash end-users in situations where usability advantages of a 2D bar code may be relevant.</dd>
|
||||
<dt>Address Encoding</dt>
|
||||
<dd>The externally visible encoding of an Address (e.g. as a string of characters or a QR code).</dd>
|
||||
<dt>Unix Epoch Time</dt>
|
||||
<dd>An integer representing a UTC time in seconds relative to the Unix Epoch of 1970-01-01T00:00:00Z.</dd>
|
||||
</dl>
|
||||
<p>Notation for sequences, conversions, and arithmetic operations follows the Zcash protocol specification <a id="footnote-reference-2" class="footnote_reference" href="#protocol-notation">3</a>.</p>
|
||||
</section>
|
||||
|
|
@ -82,8 +80,8 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<li>Sprout Addresses</li>
|
||||
<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 as described in <a id="footnote-reference-3" class="footnote_reference" href="#protocol-addressandkeyencoding">9</a>, for many purposes it suffices to consider the string encoding.)</p>
|
||||
<p>The Orchard proposal <a id="footnote-reference-4" class="footnote_reference" href="#zip-0224">26</a> adds a new Address type, Orchard Addresses.</p>
|
||||
<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 as described in <a id="footnote-reference-3" class="footnote_reference" href="#protocol-addressandkeyencoding">8</a>, for many purposes it suffices to consider the string encoding.)</p>
|
||||
<p>The Orchard proposal <a id="footnote-reference-4" class="footnote_reference" href="#zip-0224">24</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>
|
||||
|
|
@ -103,7 +101,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" class="section-anchor" 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="footnote-reference-5" class="footnote_reference" href="#zip-0321">28</a> and similar schemes. Since Payment Requests encode addresses as alphanumeric strings, no change to ZIP 321 is required in order to use Unified Addresses in Payment Requests.</p>
|
||||
<p>Despite having some similar characteristics, the Unified Address standard is orthogonal to Payment Request URIs <a id="footnote-reference-5" class="footnote_reference" href="#zip-0321">26</a> and similar schemes. Since Payment Requests encode addresses as alphanumeric strings, no change to ZIP 321 is required in order to use Unified Addresses in Payment Requests.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Wallets follow a model <em>Interaction Flow</em> as follows:</p>
|
||||
|
|
@ -123,21 +121,21 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<p>When new Transport Protocols are introduced to the Zcash protocol after Unified Addresses are standardized, those should introduce new Receiver Types but <em>not</em> 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.</p>
|
||||
</section>
|
||||
<section id="receivers"><h3><span class="section-heading">Receivers</span><span class="section-anchor"> <a rel="bookmark" href="#receivers"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Every wallet must properly <em>parse</em> encodings of a Unified Address or Unified Viewing Key containing unrecognised Items.</p>
|
||||
<p>A wallet may process unrecognised Items by indicating to the user their presence or similar information for usability or diagnostic purposes.</p>
|
||||
<p>Every wallet must properly <em>parse</em> encodings of a Unified Address or Unified Viewing Key containing unrecognized Items.</p>
|
||||
<p>A wallet may process unrecognized Items by indicating to the user their presence or similar information for usability or diagnostic purposes.</p>
|
||||
</section>
|
||||
<section id="transport-encoding"><h3><span class="section-heading">Transport Encoding</span><span class="section-anchor"> <a rel="bookmark" href="#transport-encoding"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The Unified String Encoding is “opaque” to human readers: it does <em>not</em> allow visual identification of which Receivers or Receiver Types are present.</p>
|
||||
<p>The Unified String Encoding is resilient against typos, transcription errors, cut-and-paste errors, truncation, or other likely UX hazards.</p>
|
||||
<p>There is a well-defined Unified QR 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 Unified QR Encoding and Unified String Encoding of a given UA/UVK in either direction.</p>
|
||||
<p>The Unified String Encoding fits into ZIP-321 Payment URIs <a id="footnote-reference-6" class="footnote_reference" href="#zip-0321">28</a> and general URIs without introducing parse ambiguities.</p>
|
||||
<p>The Unified String Encoding fits into ZIP-321 Payment URIs <a id="footnote-reference-6" class="footnote_reference" href="#zip-0321">26</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 unrecognised Receiver Types well enough to ignore them.</p>
|
||||
<p>The encoding must allow all wallets to safely and correctly parse out unrecognized Receiver Types well enough to ignore them.</p>
|
||||
</section>
|
||||
<section id="transfers"><h3><span class="section-heading">Transfers</span><span class="section-anchor"> <a rel="bookmark" href="#transfers"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When executing a Transfer the Sender selects a Receiver via a Selection process.</p>
|
||||
<p>Given a valid UA, Selection must treat any unrecognised Item as though it were absent.</p>
|
||||
<p>Given a valid UA, Selection must treat any unrecognized Item as though it were absent.</p>
|
||||
<ul>
|
||||
<li>This property is crucial for forward compatibility to ensure users who upgrade to newer protocols / UAs don't lose the ability to smoothly interact with older wallets.</li>
|
||||
<li>This property is crucial for allowing Transparent-Only UA-Conformant wallets to interact with newer shielded wallets, removing a disincentive for adopting newer shielded wallets.</li>
|
||||
|
|
@ -148,19 +146,14 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<p>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.</p>
|
||||
</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" class="section-anchor" 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="footnote-reference-7" class="footnote_reference" href="#protocol">2</a>.</p>
|
||||
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="footnote-reference-8" class="footnote_reference" href="#bip-0032">29</a> and BIP 44 <a id="footnote-reference-9" class="footnote_reference" href="#bip-0044">32</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 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="footnote-reference-7" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
|
||||
<p>For a Transparent P2PKH Address that is derived according to BIP 32 <a id="footnote-reference-8" class="footnote_reference" href="#bip-0032">27</a> and BIP 44 <a id="footnote-reference-9" class="footnote_reference" href="#bip-0044">30</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Privacy impacts of transparent or cross-pool transactions, and the associated UX issues, will be addressed in ZIP 315 (in preparation).</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="revision-history"><h2><span class="section-heading">Revision History</span><span class="section-anchor"> <a rel="bookmark" href="#revision-history"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<ul id="revision-1">
|
||||
<li>Revision 1: <a href="#must-understand-typecodes">MUST-understand Typecodes</a> and <a href="#address-expiration-metadata">Address Expiration Metadata</a></li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="encoding-of-unified-addresses"><h3><span class="section-heading">Encoding of Unified Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Rather than defining a Bech32 string encoding of Orchard Shielded Payment Addresses, we instead define a Unified Address format that is able to encode a set of Receivers of different types. This enables the Consumer of a Unified Address to choose the Receiver of the best type it supports, providing a better user experience as new Receiver Types are added in the future.</p>
|
||||
|
|
@ -168,10 +161,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="footnote-reference-10" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">11</a>;</li>
|
||||
— an Orchard raw address as defined in <a id="footnote-reference-10" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">10</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
— a Sapling raw address as defined in <a id="footnote-reference-11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">10</a>;</li>
|
||||
— a Sapling raw address as defined in <a id="footnote-reference-11" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">9</a>;</li>
|
||||
<li>Typecode
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
— a Transparent P2SH address, <em>or</em> Typecode
|
||||
|
|
@ -209,9 +202,9 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
in practice.)</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="footnote-reference-12" class="footnote_reference" href="#p2sh">37</a>, or the
|
||||
-bit script hash of a P2SH address <a id="footnote-reference-12" class="footnote_reference" href="#p2sh">35</a>, or the
|
||||
<span class="math">\(160\!\)</span>
|
||||
-bit validating key hash of a P2PKH address <a id="footnote-reference-13" class="footnote_reference" href="#p2pkh">36</a>.</p>
|
||||
-bit validating key hash of a P2PKH address <a id="footnote-reference-13" class="footnote_reference" href="#p2pkh">34</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>. (In order for the limitation on the
|
||||
|
|
@ -220,7 +213,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\ell^\mathsf{MAX}_M - 16\)</span>
|
||||
bytes, where
|
||||
<span class="math">\(\ell^\mathsf{MAX}_M\)</span>
|
||||
is defined in <a href="#jumbling">Jumbling</a>.) The output is then encoded with Bech32m <a id="footnote-reference-14" class="footnote_reference" href="#bip-0350">35</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
|
||||
is defined in <a href="#jumbling">Jumbling</a>.) The output is then encoded with Bech32m <a id="footnote-reference-14" class="footnote_reference" href="#bip-0350">33</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>
|
||||
|
|
@ -230,7 +223,7 @@ 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="footnote-reference-15" class="footnote_reference" href="#bip-0350">35</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="footnote-reference-15" class="footnote_reference" href="#bip-0350">33</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, except by opting into experiments.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
|
|
@ -251,7 +244,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<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="footnote-reference-16" class="footnote_reference" href="#zip-0032-sapling-helper-functions">15</a>. This SHOULD be derived from the Extended Full Viewing Key at the Account level of the ZIP 32 hierarchy.</li>
|
||||
is defined in <a id="footnote-reference-16" class="footnote_reference" href="#zip-0032-sapling-helper-functions">14</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
|
||||
|
|
@ -261,20 +254,20 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</li>
|
||||
<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 unrecognised by Consumers.</li>
|
||||
<li>For Transparent P2PKH Addresses that are derived according to BIP 32 <a id="footnote-reference-17" class="footnote_reference" href="#bip-0032">29</a> and BIP 44 <a id="footnote-reference-18" class="footnote_reference" href="#bip-0044">32</a>, the FVK and IVK Encodings have Typecode
|
||||
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="footnote-reference-17" class="footnote_reference" href="#bip-0032">27</a> and BIP 44 <a id="footnote-reference-18" class="footnote_reference" href="#bip-0044">30</a>, the FVK and IVK Encodings have Typecode
|
||||
<span class="math">\(\mathtt{0x00}.\)</span>
|
||||
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="footnote-reference-19" class="footnote_reference" href="#bip-0032-serialization-format">30</a>.) However, the FVK uses the key at the Account level, i.e. at path
|
||||
. (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="footnote-reference-19" class="footnote_reference" href="#bip-0032-serialization-format">28</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="footnote-reference-20" class="footnote_reference" href="#bip-0350">35</a>) of Unified Viewing Keys are defined as follows:</p>
|
||||
<p>The Human-Readable Parts (as defined in <a id="footnote-reference-20" class="footnote_reference" href="#bip-0350">33</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>
|
||||
|
|
@ -301,13 +294,13 @@ 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="footnote-reference-21" class="footnote_reference" href="#bitcoin-compactsize">38</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>
|
||||
<a id="footnote-reference-21" class="footnote_reference" href="#bitcoin-compactsize">36</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="footnote-reference-22" class="footnote_reference" href="#zip-0211">25</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>Consumers MUST ignore constituent Items with Typecodes they do not recognise.</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="footnote-reference-22" class="footnote_reference" href="#zip-0211">23</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
|
||||
<li>Consumers MUST ignore constituent Items 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 Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification <a id="footnote-reference-23" class="footnote_reference" href="#protocol">2</a>.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification <a id="footnote-reference-23" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
|
||||
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the constituent Items are not ordered in ascending Typecode order. Note that this is different to priority order, and does not affect which Receiver in a Unified Address should be used by a Sender.</li>
|
||||
<li>There MUST NOT be additional bytes at the end of the raw encoding that cannot be interpreted as specified above.</li>
|
||||
<li>If the encoding of a Unified Address/Viewing Key is shown to a user in an abridged form due to lack of space, at least the first 20 characters MUST be included.</li>
|
||||
|
|
@ -315,7 +308,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<section id="rationale-for-item-ordering"><h4><span class="section-heading">Rationale for Item ordering</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-item-ordering"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<details>
|
||||
<summary>Click to show/hide</summary>
|
||||
<p>The rationale for requiring Items to be canonically ordered by Typecode is that it enables implementations to use an in-memory representation that discards ordering, while retaining the same round-trip serialization of a UA / UVK (provided that unrecognised Items are retained).</p>
|
||||
<p>The rationale for requiring Items to be canonically ordered by Typecode is that it enables implementations to use an in-memory representation that discards ordering, while retaining the same round-trip serialization of a UA / UVK (provided that unrecognized Items are retained).</p>
|
||||
</details></section>
|
||||
<section id="rationale-for-showing-at-least-the-first-20-characters"><h4><span class="section-heading">Rationale for showing at least the first 20 characters</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-showing-at-least-the-first-20-characters"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<details>
|
||||
|
|
@ -324,7 +317,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</details></section>
|
||||
</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" class="section-anchor" 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="footnote-reference-24" class="footnote_reference" href="#zip-0000">14</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="footnote-reference-24" class="footnote_reference" href="#zip-0000">13</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
|
||||
|
|
@ -338,58 +331,8 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
to
|
||||
<span class="math">\(\mathtt{0xFC}\)</span>
|
||||
inclusive are reserved to indicate Metadata Items other than Receivers or Viewing Keys. These Items MAY affect the overall interpretation of the UA / UVK (for example, by specifying an expiration date).</p>
|
||||
<p id="must-understand-typecodes">As of <a href="#revision-1">Revision 1</a>, the subset of Metadata Typecodes in the range
|
||||
<span class="math">\(mathtt{0xE0}\)</span>
|
||||
to
|
||||
<span class="math">\(mathtt{0xEF}\)</span>
|
||||
inclusive are designated as "MUST-understand": if a Consumer is unable to recognise the meaning of a Metadata Item with a Typecode in this range, then it MUST regard the entire UA/UVK as unsupported and not process it further.</p>
|
||||
<p>Since Metadata Items are not Receivers, they MUST NOT be selected by a Sender when choosing a Receiver to send to, and since they are not Viewing Keys, they MUST NOT provide additional authority to view information about transactions.</p>
|
||||
<p>New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="footnote-reference-25" class="footnote_reference" href="#zip-0000">14</a>.</p>
|
||||
</section>
|
||||
<section id="address-expiration-metadata"><h3><span class="section-heading">Address Expiration Metadata</span><span class="section-anchor"> <a rel="bookmark" href="#address-expiration-metadata"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As of <a href="#revision-1">Revision 1</a>, Typecodes
|
||||
<span class="math">\(\mathtt{0xE0}\)</span>
|
||||
and
|
||||
<span class="math">\(\mathtt{0xE1}\)</span>
|
||||
are reserved for optional address expiry metadata. A producer MAY choose to generate Unified Addresses containing either or both of the following Metadata Item Types, or none.</p>
|
||||
<p>The value of a
|
||||
<span class="math">\(\mathtt{0xE0}\)</span>
|
||||
item MUST be an unsigned 32-bit integer in little-endian order specifying the Address Expiry Height, a block height of the Zcash chain associated with the UA/UVK. A Unified Address containing metadata Typecode
|
||||
<span class="math">\(\mathtt{0xE0}\)</span>
|
||||
MUST be considered expired when the height of the Zcash chain is greater than this value.</p>
|
||||
<p>The value of a
|
||||
<span class="math">\(\mathtt{0xE1}\)</span>
|
||||
item MUST be an unsigned 64-bit integer in little-endian order specifying a Unix Epoch Time, hereafter referred to as the Address Expiry Time. A Unified Address containing Metadata Typecode
|
||||
<span class="math">\(\mathtt{0xE1}\)</span>
|
||||
MUST be considered expired when the current time is after the Address Expiry Time.</p>
|
||||
<p>A Sender that supports <a href="#revision-1">Revision 1</a> of this specification MUST set a non-zero <code>nExpiryHeight</code> field in transactions that it creates. If the <code>nExpiryHeight</code> normally constructed by the Sender would be greater than the Address Expiry Height, then the transaction MUST NOT be sent. If only an Address Expiry Time is specified, then the Sender SHOULD choose a value for <code>nExpiryHeight</code> such that the transaction will expire no more than 24 hours after the current time. If both
|
||||
<span class="math">\(\mathtt{0xE0}\)</span>
|
||||
and
|
||||
<span class="math">\(\mathtt{0xE1}\)</span>
|
||||
Metadata Items are present, then both restrictions apply.</p>
|
||||
<p>If wallet user attempts to send to an expired address, the error presented to the user by the wallet SHOULD include a suggestion that the user should attempt to obtain a currently-valid address for the intended recipient. A wallet MUST NOT send to an address that it knows to have expired.</p>
|
||||
<p>Address expiration imposes no constraints on the Producer of an address. A Producer MAY generate multiple Unified Addresses with the same Receivers but different expiration metadata and/or any number of distinct Diversified Unified Addresses with the same or different expiry metadata, in any combination.</p>
|
||||
<p>When deriving a UIVK from a UFVK containing Typecodes
|
||||
<span class="math">\(\mathtt{0xE0}\)</span>
|
||||
and/or
|
||||
<span class="math">\(\mathtt{0xE1}\)</span>
|
||||
, these Metadata Items MUST be retained unmodified in the derived UIVK.</p>
|
||||
<p>When deriving a Unified Address from a UFVK or UIVK containing a Metadata Item having Typecode
|
||||
<span class="math">\(\mathtt{0xE0}\)</span>
|
||||
, the derived Unified Address MUST contain a Metadata Item having Typecode
|
||||
<span class="math">\(\mathtt{0xE0}\)</span>
|
||||
such that the Address Expiry Height of the resulting address is less than or equal to the Expiry Height of the viewing key.</p>
|
||||
<p>When deriving a Unified Address from a UFVK or UIVK containing a Metadata Item having Typecode
|
||||
<span class="math">\(\mathtt{0xE1}\)</span>
|
||||
, the derived Unified Address MUST contain a Metadata Item having Typecode
|
||||
<span class="math">\(\mathtt{0xE1}\)</span>
|
||||
such that the Address Expiry Time of the resulting address is less than or equal to the Expiry Time of the viewing key.</p>
|
||||
<p>Producers of Diversified Unified Addresses should be aware that the expiration metadata could potentially be used to link addresses from the same source. Normally, if Diversified Unified Addresses derived from the same UIVK contain only Sapling and/or Orchard Receivers and no Metadata Items, they will be unlinkable as described in <a id="footnote-reference-26" class="footnote_reference" href="#protocol-concretediversifyhash">8</a>; this property does not hold when Metadata Items are present. It is RECOMMENDED that when deriving Unified Addresses from a UFVK or UIVK containing expiry metadata that the Expiry Height and Expiry Time of each distinct address vary from one another, so as to reduce the likelihood that addresses may be linked via their expiry metadata.</p>
|
||||
<section id="rationale"><h4><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<p>The intent of this specification is that Consumers of Unified Addresses must not send to expired addresses. If only an Address Expiry Time is specified, a transaction to the associated address could be mined after the Address Expiry Time within a 24-hour window.</p>
|
||||
<p>The reason that the transaction MUST NOT be sent when its <code>nExpiryHeight</code> as normally constructed is greater than the Address Expiry Height is to avoid unnecessary information leakage in that field about which address was used as the destination. If a sender were to instead use the expiry height to directly set the <code>nExpiryHeight</code> field, this would leak the expiry information of the destination address, which may then be identifiable.</p>
|
||||
<p>When honoring an Address Expiry Time, the reason that a sender SHOULD choose a <code>nExpiryHeight</code> that is expected to occur within 24 hours of the time of transaction construction is to, when possible, ensure that the expiry time is respected to within a day. Address Expiry Times are advisory and do not represent hard bounds because computer clocks often disagree, but every effort should be made to ensure that transactions expire instead of being mined more than 24 hours after a recipient address's expiry time. When chain height information is available to the Sender, it is both permissible and advisable to set this bound more tightly; a common expiry delta used by many wallets is 40 blocks from the current chain tip, as suggested in ZIP 203 <a id="footnote-reference-27" class="footnote_reference" href="#zip-0203-default-expiry">24</a>.</p>
|
||||
</section>
|
||||
<p>Currently no Metadata Types are defined. New Metadata Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="footnote-reference-25" class="footnote_reference" href="#zip-0000">13</a>.</p>
|
||||
</section>
|
||||
<section id="deriving-internal-keys"><h3><span class="section-heading">Deriving Internal Keys</span><span class="section-anchor"> <a rel="bookmark" href="#deriving-internal-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>In addition to external addresses suitable for giving out to Senders, a wallet typically requires addresses for internal operations such as change and auto-shielding.</p>
|
||||
|
|
@ -413,7 +356,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathsf{CRH^{ivk}}\)</span>
|
||||
or
|
||||
<span class="math">\(\mathsf{Commit^{ivk}}\)</span>
|
||||
(for Sapling and Orchard respectively). Derivation of an internal shielded FVK from an external shielded FVK is specified in the "Sapling internal key derivation" <a id="footnote-reference-28" class="footnote_reference" href="#zip-0032-sapling-internal-key-derivation">18</a> and "Orchard internal key derivation" <a id="footnote-reference-29" class="footnote_reference" href="#zip-0032-orchard-internal-key-derivation">20</a> sections of ZIP 32.</p>
|
||||
(for Sapling and Orchard respectively). Derivation of an internal shielded FVK from an external shielded FVK is specified in the "Sapling internal key derivation" <a id="footnote-reference-26" class="footnote_reference" href="#zip-0032-sapling-internal-key-derivation">17</a> and "Orchard internal key derivation" <a id="footnote-reference-27" class="footnote_reference" href="#zip-0032-orchard-internal-key-derivation">19</a> sections of ZIP 32.</p>
|
||||
<p>To satisfy the above properties for transparent (P2PKH) keys, we derive the external and internal
|
||||
<span class="math">\(\mathsf{ovk}\)</span>
|
||||
components from the transparent FVK
|
||||
|
|
@ -426,7 +369,7 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(\mathsf{ser_P}(pk)\)</span>
|
||||
is
|
||||
<span class="math">\(33\)</span>
|
||||
bytes, as specified in <a id="footnote-reference-30" class="footnote_reference" href="#bip-0032-serialization-format">30</a>.</li>
|
||||
bytes, as specified in <a id="footnote-reference-28" class="footnote_reference" href="#bip-0032-serialization-format">28</a>.</li>
|
||||
<li>Let
|
||||
<span class="math">\(\mathsf{ovk_{external}}\)</span>
|
||||
be the first
|
||||
|
|
@ -441,28 +384,24 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
<span class="math">\(I_\mathsf{ovk}\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>Since an external P2PKH FVK encodes the chain code and public key at the Account level, we can derive both external and internal child keys from it, as described in BIP 44 <a id="footnote-reference-31" class="footnote_reference" href="#bip-0044-path-change">33</a>. It is possible to derive an internal P2PKH FVK from the external P2PKH FVK (i.e. its parent) without having the external spending key, because child derivation at the Change level is non-hardened.</p>
|
||||
<p>Since an external P2PKH FVK encodes the chain code and public key at the Account level, we can derive both external and internal child keys from it, as described in BIP 44 <a id="footnote-reference-29" class="footnote_reference" href="#bip-0044-path-change">31</a>. It is possible to derive an internal P2PKH FVK from the external P2PKH FVK (i.e. its parent) without having the external spending key, because child derivation at the Change level is non-hardened.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As a consequence of the specification in <a href="#must-understand-typecodes">MUST-understand Typecodes</a>, as of <a href="#revision-1">Revision 1</a> a Consumer of a UFVK MUST understand the meaning of all "MUST-understand" Metadata Item Typecodes present in the UFVK in order to derive a UIVK from it.</p>
|
||||
<p>For Metadata Items recognised by the Consumer, the processing of the Item when deriving a UIVK is specified in the section or ZIP describing that Item.</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="footnote-reference-32" 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="footnote-reference-33" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Sapling FVK, the corresponding Sapling IVK is obtained as specified in <a id="footnote-reference-30" 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="footnote-reference-31" 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="footnote-reference-34" class="footnote_reference" href="#bip-0032-public-to-public">31</a>.</li>
|
||||
as described in <a id="footnote-reference-32" class="footnote_reference" href="#bip-0032-public-to-public">29</a>.</li>
|
||||
</ul>
|
||||
<p>In each case, the Typecode remains the same as in the FVK.</p>
|
||||
<p>Items (including Metadata Items that are not "MUST-understand") that are unrecognised by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a UIVK from a UFVK.</p>
|
||||
<p>Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a UIVK from a UFVK.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As a consequence of the specification in <a href="#must-understand-typecodes">MUST-understand Typecodes</a>, as of <a href="#revision-1">Revision 1</a> a Consumer of a UIVK MUST understand the meaning of all "MUST-understand" Metadata Item Typecodes present in the UIVK in order to derive a Unified Address from it.</p>
|
||||
<p>For Metadata Items recognised by the Consumer, the processing of the Item when deriving a Unified Address is specified in the section or ZIP describing that Item.</p>
|
||||
<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="footnote-reference-35" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">17</a>.</li>
|
||||
<li>A Sapling diversifier index MUST generate a valid diversifier as defined in ZIP 32 section “Sapling diversifier derivation” <a id="footnote-reference-33" class="footnote_reference" href="#zip-0032-sapling-diversifier-derivation">16</a>.</li>
|
||||
<li>A Transparent diversifier index MUST be in the range
|
||||
<span class="math">\(0\)</span>
|
||||
to
|
||||
|
|
@ -472,19 +411,18 @@ Discussions-To: <<a href="https://github.com/zcash/zips/issues/482">https://g
|
|||
</ul>
|
||||
<p>The following derivations are applied to each component IVK using the diversifier index:</p>
|
||||
<ul>
|
||||
<li>For a Sapling IVK, the corresponding Sapling Receiver is obtained as specified in <a id="footnote-reference-36" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard IVK, the corresponding Orchard Receiver is obtained as specified in <a id="footnote-reference-37" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level <a id="footnote-reference-38" class="footnote_reference" href="#bip-0044-path-index">34</a> to derive the corresponding Transparent P2PKH Receiver. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation <a id="footnote-reference-39" class="footnote_reference" href="#bip-0032-public-to-public">31</a> MUST be used. The IVK is assumed to correspond to the extended public key for the external (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
|
||||
<li>For a Sapling IVK, the corresponding Sapling Receiver is obtained as specified in <a id="footnote-reference-34" class="footnote_reference" href="#protocol-saplingkeycomponents">4</a>.</li>
|
||||
<li>For an Orchard IVK, the corresponding Orchard Receiver is obtained as specified in <a id="footnote-reference-35" class="footnote_reference" href="#protocol-orchardkeycomponents">5</a>.</li>
|
||||
<li>For a Transparent P2PKH IVK, the diversifier index is used as a BIP 44 child key index at the Index level <a id="footnote-reference-36" class="footnote_reference" href="#bip-0044-path-index">32</a> to derive the corresponding Transparent P2PKH Receiver. As is usual for derivations below the BIP 44 Account level, non-hardened (public) derivation <a id="footnote-reference-37" class="footnote_reference" href="#bip-0032-public-to-public">29</a> MUST be used. The IVK is assumed to correspond to the extended public key for the external (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>
|
||||
</li>
|
||||
</ul>
|
||||
<p>In each case, the Typecode remains the same as in the IVK.</p>
|
||||
<p>Items (including Metadata Items that are not "MUST-understand") that are unrecognised by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a Unified Address from a UIVK.</p>
|
||||
<p>See <a href="#address-expiration-metadata">Address Expiration Metadata</a> for discussion of potential linking of Diversified Unified Addresses via their metadata.</p>
|
||||
<p>Items (including Metadata Items) that are unrecognized by a given Consumer, or that are specified in experiments that the user has not opted into (see <a href="#experimental-usage">Experimental Usage</a>), MUST be dropped when deriving a Receiver from a UIVK.</p>
|
||||
</section>
|
||||
<section id="usage-of-outgoing-viewing-keys"><h3><span class="section-heading">Usage of Outgoing Viewing Keys</span><span class="section-anchor"> <a rel="bookmark" href="#usage-of-outgoing-viewing-keys"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>When a Sender constructs a transaction that creates Sapling or Orchard notes, it uses an outgoing viewing key, as described in <a id="footnote-reference-40" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="footnote-reference-41" class="footnote_reference" href="#protocol-orchardsend">7</a>, to encrypt an outgoing ciphertext. Decryption with the outgoing viewing key allows recovering the sent note plaintext, including destination address, amount, and memo. The intention is that this outgoing viewing key should be associated with the source of the funds.</p>
|
||||
<p>However, the specification of which outgoing viewing key should be used is left somewhat open in <a id="footnote-reference-42" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="footnote-reference-43" class="footnote_reference" href="#protocol-orchardsend">7</a>; in particular, it was unclear whether transfers should be considered as being sent from an address, or from a ZIP 32 account <a id="footnote-reference-44" class="footnote_reference" href="#zip-0032-specification-wallet-usage">21</a>. The adoption of multiple shielded protocols that support outgoing viewing keys (i.e. Sapling and Orchard) further complicates this question, since from NU5 activation, nothing at the consensus level prevents a wallet from spending both Sapling and Orchard notes in the same transaction. (Recommendations about wallet usage of multiple pools will be given in ZIP 315 <a id="footnote-reference-45" class="footnote_reference" href="#zip-0315">27</a>.)</p>
|
||||
<p>When a Sender constructs a transaction that creates Sapling or Orchard notes, it uses an outgoing viewing key, as described in <a id="footnote-reference-38" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="footnote-reference-39" class="footnote_reference" href="#protocol-orchardsend">7</a>, to encrypt an outgoing ciphertext. Decryption with the outgoing viewing key allows recovering the sent note plaintext, including destination address, amount, and memo. The intention is that this outgoing viewing key should be associated with the source of the funds.</p>
|
||||
<p>However, the specification of which outgoing viewing key should be used is left somewhat open in <a id="footnote-reference-40" class="footnote_reference" href="#protocol-saplingsend">6</a> and <a id="footnote-reference-41" class="footnote_reference" href="#protocol-orchardsend">7</a>; in particular, it was unclear whether transfers should be considered as being sent from an address, or from a ZIP 32 account <a id="footnote-reference-42" class="footnote_reference" href="#zip-0032-specification-wallet-usage">20</a>. The adoption of multiple shielded protocols that support outgoing viewing keys (i.e. Sapling and Orchard) further complicates this question, since from NU5 activation, nothing at the consensus level prevents a wallet from spending both Sapling and Orchard notes in the same transaction. (Recommendations about wallet usage of multiple pools will be given in ZIP 315 <a id="footnote-reference-43" class="footnote_reference" href="#zip-0315">25</a>.)</p>
|
||||
<p>Here we refine the protocol specification in order to allow more precise determination of viewing authority for UFVKs.</p>
|
||||
<p>A Sender will attempt to determine a "sending Account" for each transfer. The preferred approach is for the API used to perform a transfer to directly specify a sending Account. Otherwise, if the Sender can ascertain that all funds used in the transfer are from addresses associated with some Account, then it SHOULD treat that as the sending Account. If not, then the sending Account is undetermined.</p>
|
||||
<p>The Sender also determines a "preferred sending protocol" —one of "transparent", "Sapling", or "Orchard"— corresponding to the most preferred Receiver Type (as given in <a href="#encoding-of-unified-addresses">Encoding of Unified Addresses</a>) of any funds sent in the transaction.</p>
|
||||
|
|
@ -802,11 +740,11 @@ c^{n+m}}{q}.\)</span>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol" class="footnote">
|
||||
<table id="protocol-nu5" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2023.4.0 or later</a></td>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -814,7 +752,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="protocol/protocol.pdf#notation">Zcash Protocol Specification, Version 2023.4.0. Section 2: Notation</a></td>
|
||||
<td><a href="protocol/protocol.pdf#notation">Zcash Protocol Specification, Version 2022.2.19. Section 2: Notation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -822,7 +760,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2023.4.0. Section 4.2.2: Sapling Key Components</a></td>
|
||||
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -830,7 +768,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2023.4.0. Section 4.2.3: Orchard Key Components</a></td>
|
||||
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -838,7 +776,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2023.4.0. Section 4.7.2: Sending Notes (Sapling)</a></td>
|
||||
<td><a href="protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2022.2.19. Section 4.7.2: Sending Notes (Sapling)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -846,62 +784,54 @@ c^{n+m}}{q}.\)</span>
|
|||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardsend">Zcash Protocol Specification, Version 2023.4.0. Section 4.7.3: Sending Notes (Orchard)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-concretediversifyhash" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2023.4.0. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
|
||||
<td><a href="protocol/protocol.pdf#orchardsend">Zcash Protocol Specification, Version 2022.2.19. Section 4.7.3: Sending Notes (Orchard)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-addressandkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/protocol.pdf#addressandkeyencoding">Zcash Protocol Specification, Version 2023.4.0. Section 5.6: Encodings of Addresses and Keys</a></td>
|
||||
<th>8</th>
|
||||
<td><a href="protocol/protocol.pdf#addressandkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6: Encodings of Addresses and Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2023.4.0. Section 5.6.3.1: Sapling Payment Addresses</a></td>
|
||||
<th>9</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.1: Sapling Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.2: Orchard Raw Payment Addresses</a></td>
|
||||
<th>10</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.2: Orchard Raw Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardinviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys</a></td>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-orchardfullviewingkeyencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.4: Orchard Raw Full Viewing Keys</a></td>
|
||||
<th>12</th>
|
||||
<td><a href="protocol/protocol.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0000" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<th>13</th>
|
||||
<td><a href="zip-0000">ZIP 0: ZIP Process</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -909,7 +839,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-helper-functions" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<th>14</th>
|
||||
<td><a href="zip-0032#sapling-helper-functions">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -917,7 +847,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-extfvk" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>16</th>
|
||||
<th>15</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>
|
||||
|
|
@ -925,7 +855,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-diversifier-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>17</th>
|
||||
<th>16</th>
|
||||
<td><a href="zip-0032#sapling-diversifier-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling diversifier derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -933,7 +863,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-internal-key-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>18</th>
|
||||
<th>17</th>
|
||||
<td><a href="zip-0032#sapling-internal-key-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling internal key derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -941,7 +871,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-orchard-child-key-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>19</th>
|
||||
<th>18</th>
|
||||
<td><a href="zip-0032#orchard-child-key-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -949,7 +879,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-orchard-internal-key-derivation" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>20</th>
|
||||
<th>19</th>
|
||||
<td><a href="zip-0032#orchard-internal-key-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard internal key derivation</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -957,7 +887,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-specification-wallet-usage" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>21</th>
|
||||
<th>20</th>
|
||||
<td><a href="zip-0032#specification-wallet-usage">ZIP 32: Shielded Hierarchical Deterministic Wallets — Specification: Wallet usage</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -965,7 +895,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-sapling-key-path" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>22</th>
|
||||
<th>21</th>
|
||||
<td><a href="zip-0032#sapling-key-path">ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -973,23 +903,15 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0032-orchard-key-path" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>23</th>
|
||||
<th>22</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-0203-default-expiry" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>24</th>
|
||||
<td><a href="zip-0203#changes-for-blossom">ZIP 203: Transaction Expiry — Changes for Blossom</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0211" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>25</th>
|
||||
<th>23</th>
|
||||
<td><a href="zip-0211">ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -997,7 +919,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0224" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>26</th>
|
||||
<th>24</th>
|
||||
<td><a href="zip-0224">ZIP 224: Orchard Shielded Protocol</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -1005,7 +927,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0315" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>27</th>
|
||||
<th>25</th>
|
||||
<td><a href="zip-0315">ZIP 315: Best Practices for Wallet Handling of Multiple Pools</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -1013,7 +935,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="zip-0321" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>28</th>
|
||||
<th>26</th>
|
||||
<td><a href="zip-0321">ZIP 321: Payment Request URIs</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -1021,7 +943,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0032" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>29</th>
|
||||
<th>27</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki">BIP 32: Hierarchical Deterministic Wallets</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -1029,7 +951,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0032-serialization-format" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>30</th>
|
||||
<th>28</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>
|
||||
|
|
@ -1037,7 +959,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0032-public-to-public" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>31</th>
|
||||
<th>29</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>
|
||||
|
|
@ -1045,7 +967,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0044" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>32</th>
|
||||
<th>30</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>
|
||||
|
|
@ -1053,7 +975,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0044-path-change" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>33</th>
|
||||
<th>31</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#change">BIP 44: Multi-Account Hierarchy for Deterministic Wallets — Path levels: Change</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -1061,7 +983,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0044-path-index" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>34</th>
|
||||
<th>32</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>
|
||||
|
|
@ -1069,7 +991,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bip-0350" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>35</th>
|
||||
<th>33</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>
|
||||
|
|
@ -1077,7 +999,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="p2pkh" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>36</th>
|
||||
<th>34</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>
|
||||
|
|
@ -1085,7 +1007,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="p2sh" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>37</th>
|
||||
<th>35</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>
|
||||
|
|
@ -1093,7 +1015,7 @@ c^{n+m}}{q}.\)</span>
|
|||
<table id="bitcoin-compactsize" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>38</th>
|
||||
<th>36</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer">Variable length integer. Bitcoin Wiki</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
198
zip-0316.rst
198
zip-0316.rst
|
|
@ -21,9 +21,9 @@
|
|||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this
|
||||
document are to be interpreted as described in BCP 14 [#BCP14]_ when, and only
|
||||
when, they appear in all capitals.
|
||||
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are
|
||||
to be interpreted as described in BCP 14 [#BCP14]_ when, and only when, they
|
||||
appear in all capitals.
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
|
|
@ -90,9 +90,6 @@ Unified QR Encoding
|
|||
Address Encoding
|
||||
The externally visible encoding of an Address (e.g. as a string of
|
||||
characters or a QR code).
|
||||
Unix Epoch Time
|
||||
An integer representing a UTC time in seconds relative to the Unix Epoch
|
||||
of 1970-01-01T00:00:00Z.
|
||||
|
||||
Notation for sequences, conversions, and arithmetic operations follows the
|
||||
Zcash protocol specification [#protocol-notation]_.
|
||||
|
|
@ -218,9 +215,9 @@ Receivers
|
|||
---------
|
||||
|
||||
Every wallet must properly *parse* encodings of a Unified Address or
|
||||
Unified Viewing Key containing unrecognised Items.
|
||||
Unified Viewing Key containing unrecognized Items.
|
||||
|
||||
A wallet may process unrecognised Items by indicating to the user their
|
||||
A wallet may process unrecognized Items by indicating to the user their
|
||||
presence or similar information for usability or diagnostic purposes.
|
||||
|
||||
Transport Encoding
|
||||
|
|
@ -247,7 +244,7 @@ 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
|
||||
unrecognised Receiver Types well enough to ignore them.
|
||||
unrecognized Receiver Types well enough to ignore them.
|
||||
|
||||
Transfers
|
||||
---------
|
||||
|
|
@ -255,7 +252,7 @@ Transfers
|
|||
When executing a Transfer the Sender selects a Receiver via a Selection
|
||||
process.
|
||||
|
||||
Given a valid UA, Selection must treat any unrecognised Item as though
|
||||
Given a valid UA, Selection must treat any unrecognized Item as though
|
||||
it were absent.
|
||||
|
||||
- This property is crucial for forward compatibility to ensure users
|
||||
|
|
@ -284,7 +281,7 @@ 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 [#protocol]_.
|
||||
as described in the Zcash Protocol Specification [#protocol-nu5]_.
|
||||
|
||||
For a Transparent P2PKH Address that is derived according to BIP 32
|
||||
[#bip-0032]_ and BIP 44 [#bip-0044]_, the nearest equivalent to a
|
||||
|
|
@ -303,12 +300,6 @@ Open Issues and Known Concerns
|
|||
Privacy impacts of transparent or cross-pool transactions, and the
|
||||
associated UX issues, will be addressed in ZIP 315 (in preparation).
|
||||
|
||||
Revision History
|
||||
================
|
||||
|
||||
.. _`Revision 1`:
|
||||
|
||||
* Revision 1: `MUST-understand Typecodes`_ and `Address Expiration Metadata`_
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
|
@ -447,7 +438,7 @@ The following FVK or IVK Encodings are used in place of the
|
|||
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 unrecognised by Consumers.
|
||||
treated as unrecognized by Consumers.
|
||||
|
||||
* For Transparent P2PKH Addresses that are derived according to BIP 32
|
||||
[#bip-0032]_ and BIP 44 [#bip-0044]_, the FVK and IVK Encodings have
|
||||
|
|
@ -521,7 +512,7 @@ Requirements for both Unified Addresses and Unified Viewing Keys
|
|||
pool, this would not be generally useful.
|
||||
|
||||
* Consumers MUST ignore constituent Items with Typecodes they do not
|
||||
recognise.
|
||||
recognize.
|
||||
|
||||
* Consumers MUST reject Unified Addresses/Viewing Keys in which the
|
||||
same Typecode appears more than once, or that include both P2SH and
|
||||
|
|
@ -531,7 +522,7 @@ Requirements for both Unified Addresses and Unified Viewing Keys
|
|||
* Consumers MUST reject Unified Addresses/Viewing Keys in which *any*
|
||||
constituent Item does not meet the validation requirements of its
|
||||
encoding, as specified in this ZIP and the Zcash Protocol Specification
|
||||
[#protocol]_.
|
||||
[#protocol-nu5]_.
|
||||
|
||||
* Consumers MUST reject Unified Addresses/Viewing Keys in which the
|
||||
constituent Items are not ordered in ascending Typecode order. Note
|
||||
|
|
@ -556,7 +547,7 @@ Rationale for Item ordering
|
|||
The rationale for requiring Items to be canonically ordered by Typecode
|
||||
is that it enables implementations to use an in-memory representation
|
||||
that discards ordering, while retaining the same round-trip serialization
|
||||
of a UA / UVK (provided that unrecognised Items are retained).
|
||||
of a UA / UVK (provided that unrecognized Items are retained).
|
||||
|
||||
.. raw:: html
|
||||
|
||||
|
|
@ -613,114 +604,15 @@ are reserved to indicate Metadata Items other than Receivers or
|
|||
Viewing Keys. These Items MAY affect the overall interpretation of
|
||||
the UA / UVK (for example, by specifying an expiration date).
|
||||
|
||||
.. _`MUST-understand Typecodes`:
|
||||
|
||||
As of `Revision 1`_, the subset of Metadata Typecodes in the range
|
||||
:math:`mathtt{0xE0}` to :math:`mathtt{0xEF}` inclusive are designated
|
||||
as "MUST-understand": if a Consumer is unable to recognise the meaning
|
||||
of a Metadata Item with a Typecode in this range, then it MUST regard
|
||||
the entire UA/UVK as unsupported and not process it further.
|
||||
|
||||
Since Metadata Items are not Receivers, they MUST NOT be selected by
|
||||
a Sender when choosing a Receiver to send to, and since they are not
|
||||
Viewing Keys, they MUST NOT provide additional authority to view
|
||||
information about transactions.
|
||||
|
||||
New Metadata Types SHOULD be introduced either by a modification to this
|
||||
ZIP or by a new ZIP, in accordance with the ZIP Process [#zip-0000]_.
|
||||
Currently no Metadata Types are defined. New Metadata Types SHOULD be
|
||||
introduced either by a modification to this ZIP or by a new ZIP, in
|
||||
accordance with the ZIP Process [#zip-0000]_.
|
||||
|
||||
Address Expiration Metadata
|
||||
---------------------------
|
||||
|
||||
As of `Revision 1`_, Typecodes :math:`\mathtt{0xE0}` and :math:`\mathtt{0xE1}`
|
||||
are reserved for optional address expiry metadata. A producer MAY choose to
|
||||
generate Unified Addresses containing either or both of the following Metadata
|
||||
Item Types, or none.
|
||||
|
||||
The value of a :math:`\mathtt{0xE0}` item MUST be an unsigned 32-bit integer in
|
||||
little-endian order specifying the Address Expiry Height, a block height of the
|
||||
Zcash chain associated with the UA/UVK. A Unified Address containing metadata
|
||||
Typecode :math:`\mathtt{0xE0}` MUST be considered expired when the height of
|
||||
the Zcash chain is greater than this value.
|
||||
|
||||
The value of a :math:`\mathtt{0xE1}` item MUST be an unsigned 64-bit integer in
|
||||
little-endian order specifying a Unix Epoch Time, hereafter referred to as the
|
||||
Address Expiry Time. A Unified Address containing Metadata Typecode
|
||||
:math:`\mathtt{0xE1}` MUST be considered expired when the current time is
|
||||
after the Address Expiry Time.
|
||||
|
||||
A Sender that supports `Revision 1`_ of this specification MUST set
|
||||
a non-zero ``nExpiryHeight`` field in transactions that it creates. If the
|
||||
``nExpiryHeight`` normally constructed by the Sender would be greater than the
|
||||
Address Expiry Height, then the transaction MUST NOT be sent. If only an
|
||||
Address Expiry Time is specified, then the Sender SHOULD choose a value for
|
||||
``nExpiryHeight`` such that the transaction will expire no more than 24 hours
|
||||
after the current time. If both :math:`\mathtt{0xE0}` and :math:`\mathtt{0xE1}`
|
||||
Metadata Items are present, then both restrictions apply.
|
||||
|
||||
If wallet user attempts to send to an expired address, the error presented to
|
||||
the user by the wallet SHOULD include a suggestion that the user should
|
||||
attempt to obtain a currently-valid address for the intended recipient. A
|
||||
wallet MUST NOT send to an address that it knows to have expired.
|
||||
|
||||
Address expiration imposes no constraints on the Producer of an address. A
|
||||
Producer MAY generate multiple Unified Addresses with the same Receivers but
|
||||
different expiration metadata and/or any number of distinct Diversified Unified
|
||||
Addresses with the same or different expiry metadata, in any combination.
|
||||
|
||||
When deriving a UIVK from a UFVK containing Typecodes :math:`\mathtt{0xE0}`
|
||||
and/or :math:`\mathtt{0xE1}`, these Metadata Items MUST be retained unmodified
|
||||
in the derived UIVK.
|
||||
|
||||
When deriving a Unified Address from a UFVK or UIVK containing a Metadata Item
|
||||
having Typecode :math:`\mathtt{0xE0}`, the derived Unified Address MUST contain
|
||||
a Metadata Item having Typecode :math:`\mathtt{0xE0}` such that the Address
|
||||
Expiry Height of the resulting address is less than or equal to the Expiry Height
|
||||
of the viewing key.
|
||||
|
||||
When deriving a Unified Address from a UFVK or UIVK containing a Metadata Item
|
||||
having Typecode :math:`\mathtt{0xE1}`, the derived Unified Address MUST contain
|
||||
a Metadata Item having Typecode :math:`\mathtt{0xE1}` such that the Address
|
||||
Expiry Time of the resulting address is less than or equal to the Expiry Time
|
||||
of the viewing key.
|
||||
|
||||
Producers of Diversified Unified Addresses should be aware that the expiration
|
||||
metadata could potentially be used to link addresses from the same source.
|
||||
Normally, if Diversified Unified Addresses derived from the same UIVK contain
|
||||
only Sapling and/or Orchard Receivers and no Metadata Items, they will be
|
||||
unlinkable as described in [#protocol-concretediversifyhash]_; this property
|
||||
does not hold when Metadata Items are present. It is RECOMMENDED that when
|
||||
deriving Unified Addresses from a UFVK or UIVK containing expiry metadata that
|
||||
the Expiry Height and Expiry Time of each distinct address vary from one
|
||||
another, so as to reduce the likelihood that addresses may be linked via their
|
||||
expiry metadata.
|
||||
|
||||
Rationale
|
||||
'''''''''
|
||||
|
||||
The intent of this specification is that Consumers of Unified Addresses must
|
||||
not send to expired addresses. If only an Address Expiry Time is specified, a
|
||||
transaction to the associated address could be mined after the Address Expiry
|
||||
Time within a 24-hour window.
|
||||
|
||||
The reason that the transaction MUST NOT be sent when its ``nExpiryHeight`` as
|
||||
normally constructed is greater than the Address Expiry Height is to avoid
|
||||
unnecessary information leakage in that field about which address was used as
|
||||
the destination. If a sender were to instead use the expiry height to directly
|
||||
set the ``nExpiryHeight`` field, this would leak the expiry information of the
|
||||
destination address, which may then be identifiable.
|
||||
|
||||
When honoring an Address Expiry Time, the reason that a sender SHOULD choose a
|
||||
``nExpiryHeight`` that is expected to occur within 24 hours of the time of
|
||||
transaction construction is to, when possible, ensure that the expiry time is
|
||||
respected to within a day. Address Expiry Times are advisory and do not
|
||||
represent hard bounds because computer clocks often disagree, but every effort
|
||||
should be made to ensure that transactions expire instead of being mined more
|
||||
than 24 hours after a recipient address's expiry time. When chain height
|
||||
information is available to the Sender, it is both permissible and advisable to
|
||||
set this bound more tightly; a common expiry delta used by many wallets is 40
|
||||
blocks from the current chain tip, as suggested in ZIP 203
|
||||
[#zip-0203-default-expiry]_.
|
||||
|
||||
Deriving Internal Keys
|
||||
----------------------
|
||||
|
|
@ -772,15 +664,6 @@ Change level is non-hardened.
|
|||
Deriving a UIVK from a UFVK
|
||||
---------------------------
|
||||
|
||||
As a consequence of the specification in `MUST-understand Typecodes`_,
|
||||
as of `Revision 1`_ a Consumer of a UFVK MUST understand the meaning of
|
||||
all "MUST-understand" Metadata Item Typecodes present in the UFVK in
|
||||
order to derive a UIVK from it.
|
||||
|
||||
For Metadata Items recognised by the Consumer, the processing of the
|
||||
Item when deriving a UIVK is specified in the section or ZIP describing
|
||||
that Item.
|
||||
|
||||
The following derivations are applied to each component FVK:
|
||||
|
||||
* For a Sapling FVK, the corresponding Sapling IVK is obtained as
|
||||
|
|
@ -795,24 +678,15 @@ The following derivations are applied to each component FVK:
|
|||
|
||||
In each case, the Typecode remains the same as in the FVK.
|
||||
|
||||
Items (including Metadata Items that are not "MUST-understand") that
|
||||
are unrecognised by a given Consumer, or that are specified in experiments
|
||||
that the user has not opted into (see `Experimental Usage`_), MUST be
|
||||
dropped when deriving a UIVK from a UFVK.
|
||||
Items (including Metadata Items) that are unrecognized by a given
|
||||
Consumer, or that are specified in experiments that the user has not
|
||||
opted into (see `Experimental Usage`_), MUST be dropped when deriving
|
||||
a UIVK from a UFVK.
|
||||
|
||||
|
||||
Deriving a Unified Address from a UIVK
|
||||
--------------------------------------
|
||||
|
||||
As a consequence of the specification in `MUST-understand Typecodes`_,
|
||||
as of `Revision 1`_ a Consumer of a UIVK MUST understand the meaning of
|
||||
all "MUST-understand" Metadata Item Typecodes present in the UIVK in
|
||||
order to derive a Unified Address from it.
|
||||
|
||||
For Metadata Items recognised by the Consumer, the processing of the
|
||||
Item when deriving a Unified Address is specified in the section or
|
||||
ZIP describing that Item.
|
||||
|
||||
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,
|
||||
|
|
@ -847,13 +721,11 @@ diversifier index:
|
|||
|
||||
In each case, the Typecode remains the same as in the IVK.
|
||||
|
||||
Items (including Metadata Items that are not "MUST-understand") that
|
||||
are unrecognised by a given Consumer, or that are specified in experiments
|
||||
that the user has not opted into (see `Experimental Usage`_), MUST be
|
||||
dropped when deriving a Unified Address from a UIVK.
|
||||
Items (including Metadata Items) that are unrecognized by a given
|
||||
Consumer, or that are specified in experiments that the user has not
|
||||
opted into (see `Experimental Usage`_), MUST be dropped when deriving
|
||||
a Receiver from a UIVK.
|
||||
|
||||
See `Address Expiration Metadata`_ for discussion of potential linking of
|
||||
Diversified Unified Addresses via their metadata.
|
||||
|
||||
Usage of Outgoing Viewing Keys
|
||||
------------------------------
|
||||
|
|
@ -1158,18 +1030,17 @@ References
|
|||
==========
|
||||
|
||||
.. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" <https://www.rfc-editor.org/info/bcp14>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later <protocol/protocol.pdf>`_
|
||||
.. [#protocol-notation] `Zcash Protocol Specification, Version 2023.4.0. Section 2: Notation <protocol/protocol.pdf#notation>`_
|
||||
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2023.4.0. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
|
||||
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2023.4.0. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
|
||||
.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2023.4.0. Section 4.7.2: Sending Notes (Sapling) <protocol/protocol.pdf#saplingsend>`_
|
||||
.. [#protocol-orchardsend] `Zcash Protocol Specification, Version 2023.4.0. Section 4.7.3: Sending Notes (Orchard) <protocol/protocol.pdf#orchardsend>`_
|
||||
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2023.4.0. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions <protocol/protocol.pdf#concretediversifyhash>`_
|
||||
.. [#protocol-addressandkeyencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6: Encodings of Addresses and Keys <protocol/protocol.pdf#addressandkeyencoding>`_
|
||||
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.3.1: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_
|
||||
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.2: Orchard Raw Payment Addresses <protocol/protocol.pdf#orchardpaymentaddrencoding>`_
|
||||
.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys <protocol/protocol.pdf#orchardinviewingkeyencoding>`_
|
||||
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.4: Orchard Raw Full Viewing Keys <protocol/protocol.pdf#orchardfullviewingkeyencoding>`_
|
||||
.. [#protocol-nu5] `Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal] <protocol/protocol.pdf>`_
|
||||
.. [#protocol-notation] `Zcash Protocol Specification, Version 2022.2.19. Section 2: Notation <protocol/protocol.pdf#notation>`_
|
||||
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
|
||||
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
|
||||
.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2022.2.19. Section 4.7.2: Sending Notes (Sapling) <protocol/protocol.pdf#saplingsend>`_
|
||||
.. [#protocol-orchardsend] `Zcash Protocol Specification, Version 2022.2.19. Section 4.7.3: Sending Notes (Orchard) <protocol/protocol.pdf#orchardsend>`_
|
||||
.. [#protocol-addressandkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6: Encodings of Addresses and Keys <protocol/protocol.pdf#addressandkeyencoding>`_
|
||||
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.1: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_
|
||||
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.2: Orchard Raw Payment Addresses <protocol/protocol.pdf#orchardpaymentaddrencoding>`_
|
||||
.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys <protocol/protocol.pdf#orchardinviewingkeyencoding>`_
|
||||
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing Keys <protocol/protocol.pdf#orchardfullviewingkeyencoding>`_
|
||||
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
|
||||
.. [#zip-0032-sapling-helper-functions] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling helper functions <zip-0032#sapling-helper-functions>`_
|
||||
.. [#zip-0032-sapling-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling extended full viewing keys <zip-0032#sapling-extended-full-viewing-keys>`_
|
||||
|
|
@ -1180,7 +1051,6 @@ References
|
|||
.. [#zip-0032-specification-wallet-usage] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Specification: Wallet usage <zip-0032#specification-wallet-usage>`_
|
||||
.. [#zip-0032-sapling-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling key path <zip-0032#sapling-key-path>`_
|
||||
.. [#zip-0032-orchard-key-path] `ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path <zip-0032#orchard-key-path>`_
|
||||
.. [#zip-0203-default-expiry] `ZIP 203: Transaction Expiry — Changes for Blossom <zip-0203#changes-for-blossom>`_
|
||||
.. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Chain Value Pool <zip-0211.rst>`_
|
||||
.. [#zip-0224] `ZIP 224: Orchard Shielded Protocol <zip-0224.rst>`_
|
||||
.. [#zip-0315] `ZIP 315: Best Practices for Wallet Handling of Multiple Pools <zip-0315.rst>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue