mirror of https://github.com/zcash/zips.git
ZIP 320: Specify Alternative 2 in terms of a MUST-understand metadata item.
This commit is contained in:
Kris Nuttycombe
parent
fee271c03d
commit
1019792188
107
zip-0320.html
107
zip-0320.html
|
|
@ -21,7 +21,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/760">https://githu
|
|||
<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", "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 "Recipient", "Producer", "Consumer", "Sender", "Receiver", "Item", "Metadata Item", "Typecode", "Address", "Unified Address" (UA), "Unified Viewing Key" (UVK), "Unified Full Viewing Key" (UFVK), and "Unified Incoming Viewing Key" (UIVK) are to be interpreted as described in ZIP 316 <a id="footnote-reference-2" class="footnote_reference" href="#zip-0316-terminology">5</a>.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">9</a>.</p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification <a id="footnote-reference-3" class="footnote_reference" href="#protocol-networks">11</a>.</p>
|
||||
</section>
|
||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP defines a new encoding for transparent Zcash addresses. Wallets must ensure that no shielded notes are spent in transactions that send to a transparent address encoded in the specified fashion.</p>
|
||||
|
|
@ -44,7 +44,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/760">https://githu
|
|||
<section id="alternative-1"><h2><span class="section-heading">Alternative 1</span><span class="section-anchor"> <a rel="bookmark" href="#alternative-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This alternative was suggested by @hanh in <a id="footnote-reference-7" class="footnote_reference" href="#hanh-suggestion">4</a>.</p>
|
||||
<section id="tex-addresses"><h3><span class="section-heading">TEX Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#tex-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A TEX Address is a Bech32m <a id="footnote-reference-8" class="footnote_reference" href="#bip-0350">14</a> reencoding of a transparent Zcash P2PKH address <a id="footnote-reference-9" class="footnote_reference" href="#protocol-transparentaddrencoding">10</a>.</p>
|
||||
<p>A TEX Address is a Bech32m <a id="footnote-reference-8" class="footnote_reference" href="#bip-0350">16</a> reencoding of a transparent Zcash P2PKH address <a id="footnote-reference-9" class="footnote_reference" href="#protocol-transparentaddrencoding">12</a>.</p>
|
||||
</section>
|
||||
<section id="motivations-for-alternative-1"><h3><span class="section-heading">Motivations for Alternative 1</span><span class="section-anchor"> <a rel="bookmark" href="#motivations-for-alternative-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The TEX Address is the simplest possible approach to creating a new address type that indicates that only transparent sources of funds should be used.</p>
|
||||
|
|
@ -52,11 +52,11 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/760">https://githu
|
|||
<section id="specification-alternative-1"><h3><span class="section-heading">Specification (Alternative 1)</span><span class="section-anchor"> <a rel="bookmark" href="#specification-alternative-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A TEX address is produced from a Mainnet Zcash P2PKH Address by executing the following steps:</p>
|
||||
<ol type="1">
|
||||
<li>Decode the address to a byte sequence using the Base58Check decoding algorithm <a id="footnote-reference-10" class="footnote_reference" href="#base58check">12</a>.</li>
|
||||
<li>Decode the address to a byte sequence using the Base58Check decoding algorithm <a id="footnote-reference-10" class="footnote_reference" href="#base58check">14</a>.</li>
|
||||
<li>If the length of the resulting byte sequence is not 22 bytes or if its two-byte address prefix is not
|
||||
<span class="math">\([\mathtt{0x1C}, \mathtt{0xB8}]\)</span>
|
||||
, return an error. Otherwise, let the <strong>validating key hash</strong> be the remaining 20 bytes of the sequence after removing the two-byte address prefix.</li>
|
||||
<li>Reencode the 20-byte <strong>validating key hash</strong> using the Bech32m encoding defined in <a id="footnote-reference-11" class="footnote_reference" href="#bip-0350">14</a> with the human-readable prefix (HRP) <code>"tex"</code>.</li>
|
||||
<li>Reencode the 20-byte <strong>validating key hash</strong> using the Bech32m encoding defined in <a id="footnote-reference-11" class="footnote_reference" href="#bip-0350">16</a> with the human-readable prefix (HRP) <code>"tex"</code>.</li>
|
||||
</ol>
|
||||
<p>For Testnet addresses, the required lead bytes of a P2PKH address in step 2 are
|
||||
<span class="math">\([\mathtt{0x1D}, \mathtt{0x25}]\)</span>
|
||||
|
|
@ -90,14 +90,20 @@ console.log(t1)</pre>
|
|||
<p>A Traceable Unified Address is a reencoding of a transparent Zcash P2PKH address into a Unified Address <a id="footnote-reference-12" class="footnote_reference" href="#zip-0316-unified-addresses">6</a>.</p>
|
||||
</section>
|
||||
<section id="motivations-for-alternative-2"><h3><span class="section-heading">Motivations for Alternative 2</span><span class="section-anchor"> <a rel="bookmark" href="#motivations-for-alternative-2"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Traceable Unified Addresses fit into the existing Zcash Unified Address ecosystem. Existing Consumers that support Unified Addresses will automatically be able to recognize a Traceable Unified Address as a valid Zcash address, but will not be able to send to that address unless they update their code to understand the new Receiver Typecode defined in this ZIP. Even in the case that Traceable P2PKH Receivers are not understood by the sending wallet, a Unified Address-supporting wallet will be able to automatically provide good error messages for their users to indicate that the wallet needs to be updated to understand and send to these addresses.</p>
|
||||
<p>In addition, by integrating with the Unified Address framework, it becomes possible for the addresses being generated to include extra metadata; in particular, metadata items such as an Address Expiry Height or Address Expiry Date <a id="footnote-reference-13" class="footnote_reference" href="#zip-0316-address-expiry">8</a> may be included. For exchange use cases such as Binance's, it is useful to ensure that an address provided to a user has a limited utility life, such that after expiration the user must obtain a new address in order to be able to continue to send funds <a id="footnote-reference-14" class="footnote_reference" href="#binance-address-expiry">11</a>.</p>
|
||||
<p>Traceable Unified Addresses fit into the Zcash Unified Address ecosystem defined by ZIP 316, Revision 1 <a id="footnote-reference-13" class="footnote_reference" href="#zip-0316-revision-1">7</a>. Existing Consumers of Unified Addresses will not be able to send to these address unless they update their code to understand the new MUST-understand Metadata Typecode defined in this ZIP.</p>
|
||||
<p>By integrating with the Unified Address framework, it becomes possible for the addresses being generated to include extra metadata; in particular, metadata items such as an Address Expiry Height or Address Expiry Date <a id="footnote-reference-14" class="footnote_reference" href="#zip-0316-address-expiry">9</a> may be included. For exchange use cases such as Binance's, it is useful to ensure that an address provided to a user has a limited utility life, such that after expiration the user must obtain a new address in order to be able to continue to send funds <a id="footnote-reference-15" class="footnote_reference" href="#binance-address-expiry">13</a>.</p>
|
||||
</section>
|
||||
<section id="specification-alternative-2"><h3><span class="section-heading">Specification (Alternative 2)</span><span class="section-anchor"> <a rel="bookmark" href="#specification-alternative-2"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Upon activation of this ZIP, the section <cite>Encoding of Unified Addresses</cite> of ZIP 316 <a id="footnote-reference-15" class="footnote_reference" href="#zip-0316-unified-addresses">6</a> will be modified to define a new Traceable P2PKH Receiver Type having Typecode
|
||||
<span class="math">\(\mathtt{0x04}\)</span>
|
||||
, the value of which MUST be the 20-byte <strong>validating key hash</strong> of a Zcash P2PKH Address as defined in <a id="footnote-reference-16" class="footnote_reference" href="#protocol-transparentaddrencoding">10</a>.</p>
|
||||
<p>The "Requirements for both Unified Addresses and Unified Viewing Keys" section of ZIP 316 <a id="footnote-reference-17" class="footnote_reference" href="#zip-0316-unified-requirements">7</a> will be modified as follows — the text:</p>
|
||||
<p>Upon activation of this ZIP, the section <cite>Metadata Items</cite> of ZIP 316 <a id="footnote-reference-16" class="footnote_reference" href="#zip-0316-metadata-items">10</a> will be modified to define a new MUST-understand Metadata Item type: Source Restriction Metadata, having Typecode
|
||||
<span class="math">\(\mathtt{0xE2}\)</span>
|
||||
, the value of which must be a single byte:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<span class="math">\(\mathtt{0x00}\)</span>
|
||||
- Transparent Source Only</li>
|
||||
</ul>
|
||||
<p>Additional Source Restriction Metadata values may be defined in the future.</p>
|
||||
<p>The "Requirements for both Unified Addresses and Unified Viewing Keys" section of ZIP 316 <a id="footnote-reference-17" class="footnote_reference" href="#zip-0316-unified-requirements">8</a> will be modified as follows — the text:</p>
|
||||
<blockquote>
|
||||
<p>A Unified Address or Unified Viewing Key MUST contain at least one shielded Item (Typecodes
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
|
|
@ -113,12 +119,18 @@ console.log(t1)</pre>
|
|||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
and
|
||||
<span class="math">\(\mathtt{0x03}\)</span>
|
||||
), and no Traceable P2PKH Receiver (Typecode
|
||||
<span class="math">\(\mathtt{0x04}\)</span>
|
||||
); <strong>or</strong></li>
|
||||
<li>contain <strong>only</strong> a Traceable P2PKH Receiver (Typecode
|
||||
<span class="math">\(\mathtt{0x04}\)</span>
|
||||
).</li>
|
||||
), and <strong>no</strong> Source Restriction Metadata Item having value
|
||||
<span class="math">\(\mathtt{0x00}\)</span>
|
||||
; <strong>or</strong></li>
|
||||
<li>contain <strong>both</strong> a Transparent Receiver (Typecode
|
||||
<span class="math">\(\mathtt{0x00}\)</span>
|
||||
or Typecode
|
||||
<span class="math">\(\mathtt{0x01}\)</span>
|
||||
) <strong>and</strong> a Source Restriction Metadata Item (Typecode
|
||||
<span class="math">\(\mathtt{0xE2}\)</span>
|
||||
) having value
|
||||
<span class="math">\(\mathtt{0x00}\)</span>
|
||||
, and <strong>no other</strong> Receivers.</li>
|
||||
</ul>
|
||||
<p>A Unified Viewing Key MUST contain at least one shielded Item (Typecodes
|
||||
<span class="math">\(\mathtt{0x02}\)</span>
|
||||
|
|
@ -126,24 +138,32 @@ console.log(t1)</pre>
|
|||
<span class="math">\(\mathtt{0x03}\)</span>
|
||||
).</p>
|
||||
</blockquote>
|
||||
<p>In the following, the “<code>u+</code>” Human Readable Part of Revision 1 Unified Addresses is a placeholder value, pending the finalization of Revision 1 <a id="footnote-reference-18" class="footnote_reference" href="#zip-0316-revision-1">7</a>.</p>
|
||||
<p>A Traceable Unified Address is produced from a Mainnet Zcash P2PKH address by executing the following steps:</p>
|
||||
<ol type="1">
|
||||
<li>Decode the address to a byte sequence using the Base58Check decoding algorithm <a id="footnote-reference-18" class="footnote_reference" href="#base58check">12</a>.</li>
|
||||
<li>Decode the address to a byte sequence using the Base58Check decoding algorithm <a id="footnote-reference-19" class="footnote_reference" href="#base58check">14</a>.</li>
|
||||
<li>If the length of the resulting byte sequence is not 22 bytes or if its two-byte address prefix is not
|
||||
<span class="math">\([\mathtt{0x1C}, \mathtt{0xB8}]\)</span>
|
||||
, return an error. Otherwise, let the <strong>validating key hash</strong> be the remaining 20 bytes of the array after removing the two-byte address prefix.</li>
|
||||
<li>Construct a new Unified Address using a single Traceable P2PKH Receiver
|
||||
<li>Construct a new Revision 1 Unified Address using a single P2PKH Receiver
|
||||
<span class="math">\(\mathtt{0x04}\)</span>
|
||||
with the 20-byte <strong>validating key hash</strong> as its value. In addition, metadata items such as an Address Expiry Height or Address Expiry Date <a id="footnote-reference-19" class="footnote_reference" href="#zip-0316-address-expiry">8</a> MAY be included.</li>
|
||||
with the 20-byte <strong>validating key hash</strong> as its value, and a Source Restriction Metadata Item (Typecode
|
||||
<span class="math">\(\mathtt{0xE2}\)</span>
|
||||
) having value
|
||||
<span class="math">\(\mathtt{0x00}\)</span>
|
||||
(Transparent Source Only). In addition, metadata items such as an Address Expiry Height or Address Expiry Date <a id="footnote-reference-20" class="footnote_reference" href="#zip-0316-address-expiry">9</a> MAY be included.</li>
|
||||
<li>Encode the Unified Address using the “<code>u+</code>” Human Readable Part as specified for Revision 1 of ZIP 316 <a id="footnote-reference-21" class="footnote_reference" href="#zip-0316-unified-addresses">6</a>.</li>
|
||||
</ol>
|
||||
<p>For Testnet addresses, the required lead bytes of a P2PKH address in step 2 are
|
||||
<span class="math">\([\mathtt{0x1D}, \mathtt{0x25}]\)</span>
|
||||
.</p>
|
||||
<p>The HRP of the resulting Unified Address is the same as for any other Unified Address on the relevant network as specified in <a id="footnote-reference-20" class="footnote_reference" href="#zip-0316-unified-addresses">6</a>, i.e. <code>"u"</code> for Mainnet and <code>"utest"</code> for Testnet.</p>
|
||||
<p>Wallets and other Senders sending to a Traceable P2PKH Receiver MUST ensure that only transparent UTXOs are spent in the creation of a transaction.</p>
|
||||
<p>The HRP of the resulting Unified Address is the same as for any other Revision 1 Unified Address on the relevant network as specified in <a id="footnote-reference-22" class="footnote_reference" href="#zip-0316-revision-1">7</a>, i.e. <code>"u+"</code> for Mainnet and <code>"u+test"</code> for Testnet.</p>
|
||||
<p>Wallets and other Senders MUST ensure that only transparent UTXOs are spent in the creation of a transaction to any Unified Address containing a Source Restriction Metadata Item having value
|
||||
<span class="math">\(\mathtt{0x00}\)</span>
|
||||
.</p>
|
||||
</section>
|
||||
<section id="reference-implementation-alternative-2"><h3><span class="section-heading">Reference Implementation (Alternative 2)</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation-alternative-2"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Javascript using <cite>zcash_address_wasm</cite> <a id="footnote-reference-21" class="footnote_reference" href="#zcash-address-wasm">15</a>:</p>
|
||||
<p>Javascript using <cite>zcash_address_wasm</cite> <a id="footnote-reference-23" class="footnote_reference" href="#zcash-address-wasm">17</a>:</p>
|
||||
<pre>import init, { to_traceable_address, traceable_to_p2pkh, addr_expiry_time } from 'zcash_address_wasm';
|
||||
init().then(() => {
|
||||
var t_address = "t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC";
|
||||
|
|
@ -183,7 +203,7 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<section id="cons-to-alternative-1"><h3><span class="section-heading">Cons to Alternative 1</span><span class="section-anchor"> <a rel="bookmark" href="#cons-to-alternative-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>Existing wallets and other Consumers will regard the new address type as entirely invalid, and will not automatically prompt their users that they need to upgrade in order to send to this type of address.</li>
|
||||
<li>Creation of a new fully distinct address type further fragments the Zcash address ecosystem. Avoiding such fragmentation and providing smooth upgrade paths and good error messages to users is exactly the problem that Unified Addresses <a id="footnote-reference-22" class="footnote_reference" href="#zip-0316-unified-addresses">6</a> were intended to avoid.</li>
|
||||
<li>Creation of a new fully distinct address type further fragments the Zcash address ecosystem. Avoiding such fragmentation and providing smooth upgrade paths and good error messages to users is exactly the problem that Unified Addresses <a id="footnote-reference-24" class="footnote_reference" href="#zip-0316-unified-addresses">6</a> were intended to avoid.</li>
|
||||
<li>The TEX address type does not provide any mechanism for address expiration. One of the questions Binance has asked has been what to do about users who have stored their existing transparent deposit address in their wallets, or use them as a withdrawal address for other exchanges or services. This is a challenging problem to mitigate now because address expiration was not previously implemented. We should not further compound this problem by defining a new distinct address type that does not provide a mechanism for address expiry.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
|
@ -191,9 +211,9 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<section id="analysis-of-alternative-2"><h2><span class="section-heading">Analysis of Alternative 2</span><span class="section-anchor"> <a rel="bookmark" href="#analysis-of-alternative-2"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<section id="pros-to-alternative-2"><h3><span class="section-heading">Pros To Alternative 2</span><span class="section-anchor"> <a rel="bookmark" href="#pros-to-alternative-2"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>By integrating with the Unified Address framework, Consumers of Traceable Unified Addresses that have not yet been upgraded to recognize these addresses can automatically be prompted to upgrade their wallets or services to understand the unrecognized Receiver Typecode.</li>
|
||||
<li>By integrating with the Unified Address framework, Consumers of Revision 1 Unified Addresses that have not yet been upgraded to recognize these addresses can automatically be prompted to upgrade their wallets or services to understand the unrecognized MUST-understand Metadata Typecode.</li>
|
||||
<li>It is possible to include address expiration metadata in a Traceable Unified Address, which can help to mitigate problems related to stored addresses in the future.</li>
|
||||
<li>Traceable Unified Addresses benefit from the robustness to errors and protection against malleation of Unified Addresses <a id="footnote-reference-23" class="footnote_reference" href="#f4jumble">13</a>.</li>
|
||||
<li>Traceable Unified Addresses benefit from the robustness to errors and protection against malleation of Unified Addresses <a id="footnote-reference-25" class="footnote_reference" href="#f4jumble">15</a>.</li>
|
||||
<li>Regardless of which proposal is adopted, the Zcash Community will need to work with exchanges other than Binance to update their address parsing logic to understand the new address format. By encouraging Consumers such as exchanges to adopt parsing for Unified Addresses, this proposal furthers the original goal of Unified Addresses to reduce fragmentation in the address ecosystem.
|
||||
<p>Whenever any new feature is added, wallets have a choice whether or not to support that new feature. The point of Unified Address parsing is that wallets don’t have to upgrade to recognize a different address format as a valid Zcash address. Instead of returning a “Not a valid Zcash address” error, which could be confusing for users, they can return an error more like “This is a valid Zcash address, but this wallet does not support sending to it.” This can be used as a prompt to upgrade the wallet to a version (or alternative) that does support that feature.</p>
|
||||
<p>For example: numerous wallets have already upgraded to being able to parse Unified Addresses. Those wallets, on seeing a Traceable Unified Address from Binance, will report to their users that the address is a valid Zcash address, but not yet supported by the wallet. Instead of a user thinking that Binance has made some error, they can contact the wallet’s developer and ask that the wallet be updated.</p>
|
||||
|
|
@ -202,7 +222,8 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
</section>
|
||||
<section id="cons-to-alternative-2"><h3><span class="section-heading">Cons to Alternative 2</span><span class="section-anchor"> <a rel="bookmark" href="#cons-to-alternative-2"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<ul>
|
||||
<li>Unified Address encoding is slightly more complex than the proposed TEX address encoding, and requires use of the F4Jumble encoding algorithm <a id="footnote-reference-24" class="footnote_reference" href="#f4jumble">13</a>. However, this can be readily mitigated by providing a purpose-built library for Traceable Unified Address encoding to Producers.</li>
|
||||
<li>Existing wallets and other Consumers of Revision 0 Unified Addresses will regard the new address type as entirely invalid, and will not automatically prompt their users that they need to upgrade in order to send to this type of address.</li>
|
||||
<li>Unified Address encoding is slightly more complex than the proposed TEX address encoding, and requires use of the F4Jumble encoding algorithm <a id="footnote-reference-26" class="footnote_reference" href="#f4jumble">15</a>. However, this can be readily mitigated by providing a purpose-built library for Traceable Unified Address encoding to Producers.</li>
|
||||
<li>A Traceable Unified Address is somewhat longer than a TEX address, although not excessively so.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
|
@ -256,10 +277,18 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0316-unified-requirements" class="footnote">
|
||||
<table id="zip-0316-revision-1" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="https://github.com/zcash/zips/pull/765">ZIP 316: Unified Addresses and Unified Viewing Keys — Revision 1</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0316-unified-requirements" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="zip-0316#requirements-for-both-unified-addresses-and-unified-viewing-keys">ZIP 316: Unified Addresses and Unified Viewing Keys — Requirements for both Unified Addresses and Unified Viewing Keys</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -267,15 +296,23 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<table id="zip-0316-address-expiry" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0316#address-expiration-metadata">ZIP 316: Unified Addresses and Unified Viewing Keys — Address Expiration Metadata</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0316-metadata-items" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="zip-0316#metadata-items">ZIP 316: Unified Addresses and Unified Viewing Keys — Metadata Items</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -283,7 +320,7 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<table id="protocol-transparentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<th>12</th>
|
||||
<td><a href="protocol/protocol.pdf#transparentaddrencoding">Zcash Protocol Specification, Version 2023.4.0. Section 5.6.1.1 Transparent Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -291,7 +328,7 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<table id="binance-address-expiry" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<th>13</th>
|
||||
<td><a href="https://forum.zcashcommunity.com/t/unified-address-expiration/46564/6">Zcash Community Forum post describing motivations for address expiry</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -299,7 +336,7 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<table id="base58check" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<th>14</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Base58Check_encoding">Base58Check encoding — Bitcoin Wiki</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -307,7 +344,7 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<table id="f4jumble" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<th>15</th>
|
||||
<td><a href="zip-0316#jumbling">ZIP 316: Unified Addresses and Unified Viewing Keys — Jumbling</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -315,7 +352,7 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<table id="bip-0350" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>14</th>
|
||||
<th>16</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>
|
||||
|
|
@ -323,7 +360,7 @@ expiry time: Mon Feb 13 2024 01:14:18 GMT</pre>
|
|||
<table id="zcash-address-wasm" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>15</th>
|
||||
<th>17</th>
|
||||
<td><a href="https://github.com/nuttycom/zcash_address_wasm">zcash_address_wasm: Proof-of-concept library for Traceable Unified Address Encoding</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
83
zip-0320.rst
83
zip-0320.rst
|
|
@ -157,21 +157,17 @@ address into a Unified Address [#zip-0316-unified-addresses]_.
|
|||
Motivations for Alternative 2
|
||||
-----------------------------
|
||||
|
||||
Traceable Unified Addresses fit into the existing Zcash Unified Address
|
||||
ecosystem. Existing Consumers that support Unified Addresses will automatically
|
||||
be able to recognize a Traceable Unified Address as a valid Zcash address, but
|
||||
will not be able to send to that address unless they update their code to
|
||||
understand the new Receiver Typecode defined in this ZIP. Even in the case that
|
||||
Traceable P2PKH Receivers are not understood by the sending wallet, a Unified
|
||||
Address-supporting wallet will be able to automatically provide good error
|
||||
messages for their users to indicate that the wallet needs to be updated to
|
||||
understand and send to these addresses.
|
||||
Traceable Unified Addresses fit into the Zcash Unified Address ecosystem
|
||||
defined by ZIP 316, Revision 1 [#zip-0316-revision-1]_. Existing Consumers of
|
||||
Unified Addresses will not be able to send to these address unless they update
|
||||
their code to understand the new MUST-understand Metadata Typecode defined in
|
||||
this ZIP.
|
||||
|
||||
In addition, by integrating with the Unified Address framework, it becomes
|
||||
possible for the addresses being generated to include extra metadata; in
|
||||
particular, metadata items such as an Address Expiry Height or Address Expiry
|
||||
Date [#zip-0316-address-expiry]_ may be included. For exchange use cases such
|
||||
as Binance's, it is useful to ensure that an address provided to a user has a
|
||||
By integrating with the Unified Address framework, it becomes possible for the
|
||||
addresses being generated to include extra metadata; in particular, metadata
|
||||
items such as an Address Expiry Height or Address Expiry Date
|
||||
[#zip-0316-address-expiry]_ may be included. For exchange use cases such as
|
||||
Binance's, it is useful to ensure that an address provided to a user has a
|
||||
limited utility life, such that after expiration the user must obtain a new
|
||||
address in order to be able to continue to send funds
|
||||
[#binance-address-expiry]_.
|
||||
|
|
@ -179,11 +175,14 @@ address in order to be able to continue to send funds
|
|||
Specification (Alternative 2)
|
||||
-----------------------------
|
||||
|
||||
Upon activation of this ZIP, the section `Encoding of Unified Addresses` of ZIP
|
||||
316 [#zip-0316-unified-addresses]_ will be modified to define a new Traceable
|
||||
P2PKH Receiver Type having Typecode :math:`\mathtt{0x04}`, the value of which
|
||||
MUST be the 20-byte **validating key hash** of a Zcash P2PKH Address as defined
|
||||
in [#protocol-transparentaddrencoding]_.
|
||||
Upon activation of this ZIP, the section `Metadata Items` of ZIP 316
|
||||
[#zip-0316-metadata-items]_ will be modified to define a new MUST-understand
|
||||
Metadata Item type: Source Restriction Metadata, having Typecode
|
||||
:math:`\mathtt{0xE2}`, the value of which must be a single byte:
|
||||
|
||||
* :math:`\mathtt{0x00}` - Transparent Source Only
|
||||
|
||||
Additional Source Restriction Metadata values may be defined in the future.
|
||||
|
||||
The "Requirements for both Unified Addresses and Unified Viewing Keys" section
|
||||
of ZIP 316 [#zip-0316-unified-requirements]_ will be modified as follows — the
|
||||
|
|
@ -203,13 +202,20 @@ will be replaced by:
|
|||
such that a Unified Address MUST **either**:
|
||||
|
||||
* contain at least one shielded Receiver (Typecodes :math:`\mathtt{0x02}`
|
||||
and :math:`\mathtt{0x03}`), and no Traceable P2PKH Receiver (Typecode
|
||||
:math:`\mathtt{0x04}`); **or**
|
||||
* contain **only** a Traceable P2PKH Receiver (Typecode :math:`\mathtt{0x04}`).
|
||||
and :math:`\mathtt{0x03}`), and **no** Source Restriction Metadata Item
|
||||
having value :math:`\mathtt{0x00}`; **or**
|
||||
* contain **both** a Transparent Receiver (Typecode :math:`\mathtt{0x00}` or
|
||||
Typecode :math:`\mathtt{0x01}`) **and** a Source Restriction Metadata Item
|
||||
(Typecode :math:`\mathtt{0xE2}`) having value :math:`\mathtt{0x00}`, and
|
||||
**no other** Receivers.
|
||||
|
||||
A Unified Viewing Key MUST contain at least one shielded Item (Typecodes
|
||||
:math:`\mathtt{0x02}` and :math:`\mathtt{0x03}`).
|
||||
|
||||
In the following, the “``u+``” Human Readable Part of Revision 1 Unified
|
||||
Addresses is a placeholder value, pending the finalization of Revision 1
|
||||
[#zip-0316-revision-1]_.
|
||||
|
||||
A Traceable Unified Address is produced from a Mainnet Zcash P2PKH address by
|
||||
executing the following steps:
|
||||
|
||||
|
|
@ -219,20 +225,25 @@ executing the following steps:
|
|||
two-byte address prefix is not :math:`[\mathtt{0x1C}, \mathtt{0xB8}]`,
|
||||
return an error. Otherwise, let the **validating key hash** be the remaining
|
||||
20 bytes of the array after removing the two-byte address prefix.
|
||||
3. Construct a new Unified Address using a single Traceable P2PKH Receiver
|
||||
:math:`\mathtt{0x04}` with the 20-byte **validating key hash** as its value.
|
||||
In addition, metadata items such as an Address Expiry Height or Address
|
||||
Expiry Date [#zip-0316-address-expiry]_ MAY be included.
|
||||
3. Construct a new Revision 1 Unified Address using a single P2PKH Receiver
|
||||
:math:`\mathtt{0x04}` with the 20-byte **validating key hash** as its value,
|
||||
and a Source Restriction Metadata Item (Typecode :math:`\mathtt{0xE2}`)
|
||||
having value :math:`\mathtt{0x00}` (Transparent Source Only). In addition,
|
||||
metadata items such as an Address Expiry Height or Address Expiry Date
|
||||
[#zip-0316-address-expiry]_ MAY be included.
|
||||
4. Encode the Unified Address using the “``u+``” Human Readable Part as
|
||||
specified for Revision 1 of ZIP 316 [#zip-0316-unified-addresses]_.
|
||||
|
||||
For Testnet addresses, the required lead bytes of a P2PKH address in step 2
|
||||
are :math:`[\mathtt{0x1D}, \mathtt{0x25}]`.
|
||||
|
||||
The HRP of the resulting Unified Address is the same as for any other Unified
|
||||
Address on the relevant network as specified in [#zip-0316-unified-addresses]_,
|
||||
i.e. ``"u"`` for Mainnet and ``"utest"`` for Testnet.
|
||||
The HRP of the resulting Unified Address is the same as for any other Revision 1
|
||||
Unified Address on the relevant network as specified in [#zip-0316-revision-1]_,
|
||||
i.e. ``"u+"`` for Mainnet and ``"u+test"`` for Testnet.
|
||||
|
||||
Wallets and other Senders sending to a Traceable P2PKH Receiver MUST ensure
|
||||
that only transparent UTXOs are spent in the creation of a transaction.
|
||||
Wallets and other Senders MUST ensure that only transparent UTXOs are spent in
|
||||
the creation of a transaction to any Unified Address containing a Source
|
||||
Restriction Metadata Item having value :math:`\mathtt{0x00}`.
|
||||
|
||||
Reference Implementation (Alternative 2)
|
||||
----------------------------------------
|
||||
|
|
@ -304,10 +315,10 @@ Analysis of Alternative 2
|
|||
Pros To Alternative 2
|
||||
---------------------
|
||||
|
||||
- By integrating with the Unified Address framework, Consumers of Traceable
|
||||
- By integrating with the Unified Address framework, Consumers of Revision 1
|
||||
Unified Addresses that have not yet been upgraded to recognize these
|
||||
addresses can automatically be prompted to upgrade their wallets or services
|
||||
to understand the unrecognized Receiver Typecode.
|
||||
to understand the unrecognized MUST-understand Metadata Typecode.
|
||||
- It is possible to include address expiration metadata in a Traceable Unified
|
||||
Address, which can help to mitigate problems related to stored addresses in
|
||||
the future.
|
||||
|
|
@ -339,6 +350,10 @@ Pros To Alternative 2
|
|||
Cons to Alternative 2
|
||||
---------------------
|
||||
|
||||
- Existing wallets and other Consumers of Revision 0 Unified Addresses will
|
||||
regard the new address type as entirely invalid, and will not automatically
|
||||
prompt their users that they need to upgrade in order to send to this type of
|
||||
address.
|
||||
- Unified Address encoding is slightly more complex than the proposed TEX
|
||||
address encoding, and requires use of the F4Jumble encoding algorithm
|
||||
[#F4Jumble]_. However, this can be readily mitigated by providing a
|
||||
|
|
@ -355,8 +370,10 @@ References
|
|||
.. [#hanh-suggestion] `Ywallet developer @hanh's proposal <https://forum.zcashcommunity.com/t/important-potential-binance-delisting/45954/112>`_
|
||||
.. [#zip-0316-terminology] `ZIP 316: Unified Addresses and Unified Viewing Keys — Terminology <zip-0316#terminology>`_
|
||||
.. [#zip-0316-unified-addresses] `ZIP 316: Unified Addresses and Unified Viewing Keys — Encoding of Unified Addresses <zip-0316#encoding-of-unified-addresses>`_
|
||||
.. [#zip-0316-revision-1] `ZIP 316: Unified Addresses and Unified Viewing Keys — Revision 1 <https://github.com/zcash/zips/pull/765>`_
|
||||
.. [#zip-0316-unified-requirements] `ZIP 316: Unified Addresses and Unified Viewing Keys — Requirements for both Unified Addresses and Unified Viewing Keys <zip-0316#requirements-for-both-unified-addresses-and-unified-viewing-keys>`_
|
||||
.. [#zip-0316-address-expiry] `ZIP 316: Unified Addresses and Unified Viewing Keys — Address Expiration Metadata <zip-0316#address-expiration-metadata>`_
|
||||
.. [#zip-0316-metadata-items] `ZIP 316: Unified Addresses and Unified Viewing Keys — Metadata Items <zip-0316#metadata-items>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||
.. [#protocol-transparentaddrencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.1.1 Transparent Addresses <protocol/protocol.pdf#transparentaddrencoding>`_
|
||||
.. [#binance-address-expiry] `Zcash Community Forum post describing motivations for address expiry <https://forum.zcashcommunity.com/t/unified-address-expiration/46564/6>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue