mirror of https://github.com/zcash/zips.git
Merge pull request #403 from daira/zip-0321-addresses
ZIP 321 address-related updates
This commit is contained in:
Kris Nuttycombe
GitHub
commit
c41d94d53d
103
zip-0321.html
103
zip-0321.html
|
|
@ -18,6 +18,7 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/395">https://githu
|
|||
License: MIT</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" 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 RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol-networks">10</a>.</p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>payment</dt>
|
||||
|
|
@ -30,7 +31,7 @@ License: MIT</pre>
|
|||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>In order for a robust transactional ecosystem to evolve for Zcash, it is necessary for vendors to be able to issue requests for payment. At present, the best option available is to manually specify a payment address, a payment amount, and potentially memo field content. Of these three components, existing wallets only provide functionality for reading payment addresses in a semi-automated fashion. It is then necessary for the user to manually enter payment amounts and any associated memo information, which is tedious and may be error-prone, particularly if a payment is intended for multiple recipients or the memo field information contains structured data that must be faithfully reproduced.</p>
|
||||
<p>This ZIP seeks to eliminate these issues by proposing a standard format that wallet vendors may support so that human intervention is required only for approval, not creation, of such a payment transaction.</p>
|
||||
<p>In Bitcoin, two different standards exist to permit vendors to issue payment requests that are understood by wallets: BIP-0021 <a id="id2" class="footnote_reference" href="#bip-0021">4</a> and BIP-0070 <a id="id3" class="footnote_reference" href="#bip-0070">5</a>. BIP-0021 provides a URI format that can be interpreted by a wallet to construct simple, single-recipient transactions; while BIP-0070 uses a protobuf-based protocol that permits payment requests to specify the creation of transactions of arbitrary complexity.</p>
|
||||
<p>In Bitcoin, two different standards exist to permit vendors to issue payment requests that are understood by wallets: BIP-0021 <a id="id3" class="footnote_reference" href="#bip-0021">5</a> and BIP-0070 <a id="id4" class="footnote_reference" href="#bip-0070">6</a>. BIP-0021 provides a URI format that can be interpreted by a wallet to construct simple, single-recipient transactions; while BIP-0070 uses a protobuf-based protocol that permits payment requests to specify the creation of transactions of arbitrary complexity.</p>
|
||||
<p>The format proposed in this ZIP seeks a middle ground between these approaches: to provide a URI-based format which supports both the trivial use case and the slightly-more-complex situation where a payment may be intended for multiple recipients.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
|
|
@ -38,10 +39,10 @@ License: MIT</pre>
|
|||
<p>The format must permit the representation of one or more (payment address, amount, memo) tuples.</p>
|
||||
</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The following syntax specification uses ABNF <a id="id4" class="footnote_reference" href="#rfc5234">2</a>.</p>
|
||||
<p>URI Syntax:</p>
|
||||
<pre data-language="EBNF"><span class="k">zcashurn </span><span class="o">=</span> <span class="s2">"zcash:"</span> <span class="p">(</span> <span class="k">zcashaddress </span><span class="p">[</span> <span class="s2">"?"</span> <span class="k">zcashparams </span><span class="p">]</span> <span class="err">/</span> <span class="s2">"?"</span> <span class="k">zcashparams </span><span class="p">)</span>
|
||||
<span class="k">zcashaddress </span><span class="err">=</span> <span class="err">1*</span><span class="k">base58</span>
|
||||
<section id="uri-syntax"><h3><span class="section-heading">URI Syntax</span><span class="section-anchor"> <a rel="bookmark" href="#uri-syntax"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>The following syntax specification uses ABNF <a id="id5" class="footnote_reference" href="#rfc5234">2</a>.</p>
|
||||
<pre data-language="EBNF"><span class="k">zcashurn </span><span class="o">=</span> <span class="s2">"zcash:"</span> <span class="p">(</span> <span class="k">zcashaddress </span><span class="p">[</span> <span class="s2">"?"</span> <span class="k">zcashparams </span><span class="p">]</span> <span class="err">/</span> <span class="s2">"?"</span> <span class="k">zcashparams </span><span class="p">)</span>
|
||||
<span class="k">zcashaddress </span><span class="err">=</span> <span class="err">1*</span><span class="p">(</span> <span class="k">ALPHA </span><span class="err">/</span> <span class="k">DIGIT </span><span class="p">)</span>
|
||||
<span class="k">zcashparams </span><span class="err">=</span> <span class="k">zcashparam </span><span class="p">[</span> <span class="s2">"&"</span> <span class="k">zcashparams </span><span class="p">]</span>
|
||||
<span class="k">zcashparam </span><span class="err">=</span> <span class="p">[</span> <span class="k">addrparam </span><span class="err">/</span> <span class="k">amountparam </span><span class="err">/</span> <span class="k">memoparam </span><span class="err">/</span> <span class="k">messageparam </span><span class="err">/</span> <span class="k">labelparam </span><span class="err">/</span> <span class="k">reqparam </span><span class="err">/</span> <span class="k">otherparam </span><span class="p">]</span>
|
||||
<span class="k">NONZERO </span><span class="err">=</span> <span class="err">%</span><span class="k">x31-39</span>
|
||||
|
|
@ -57,14 +58,24 @@ License: MIT</pre>
|
|||
<span class="k">otherparam </span><span class="err">=</span> <span class="k">paramname </span><span class="p">[</span> <span class="k">paramindex </span><span class="p">]</span> <span class="p">[</span> <span class="s2">"="</span> <span class="err">*</span><span class="k">qchar </span><span class="p">]</span>
|
||||
<span class="k">qchar </span><span class="err">=</span> <span class="k">unreserved </span><span class="err">/</span> <span class="k">pct-encoded </span><span class="err">/</span> <span class="k">allowed-delims </span><span class="err">/</span> <span class="s2">":"</span> <span class="err">/</span> <span class="s2">"@"</span>
|
||||
<span class="k">allowed-delims </span><span class="err">=</span> <span class="s2">"!"</span> <span class="err">/</span> <span class="s2">"$"</span> <span class="err">/</span> <span class="s2">"'"</span> <span class="err">/</span> <span class="s2">"("</span> <span class="err">/</span> <span class="s2">")"</span> <span class="err">/</span> <span class="s2">"*"</span> <span class="err">/</span> <span class="s2">"+"</span> <span class="err">/</span> <span class="s2">","</span> <span class="err">/</span> <span class="s2">";"</span></pre>
|
||||
<p>Here, <code>ALPHA</code>, <code>unreserved</code> and <code>pct-encoded</code> are as defined in <a id="id5" class="footnote_reference" href="#rfc3986">3</a>. "base58" is defined as in <a id="id6" class="footnote_reference" href="#base58check">6</a>. "base64url" is defined as in <a id="id7" class="footnote_reference" href="#base64url">7</a> with padding omitted. (Note that this uses a different alphabet to the usual base64; the values 62 and 63 in the alphabet are encoded as <code>-</code> and <code>_</code> respectively.)</p>
|
||||
<p>A ZIP-321 URI represents a request for the construction of a transaction having one or more <em>payments</em>. In the case that only a single payment is being requested, the recipient address SHOULD be included in the <code>hier-part</code> component of the RFC 3986 URI; otherwise, multiple recipient addresses can be specified using <code>addrparam</code> parameters with different indices.</p>
|
||||
<p>Addresses, amounts, labels, and messages sharing the same <code>paramindex</code> (including the empty <code>paramindex</code>) are interpreted to be associated with the same payment for the purposes of payment construction. A <code>paramindex</code> MUST NOT have leading zero(s). There is no significance to the ordering of parameters, and <code>paramindex</code> values need not be sequential.</p>
|
||||
<p>Due to fundamental restrictions on transaction construction described in <a id="id8" class="footnote_reference" href="#saplingoutputs">8</a>, there may be no more than 2109 distinct payments requested by a single ZIP-321 URI.</p>
|
||||
<p>A URI of the form <code>zcash:<address>?...</code> MUST be considered equivalent to a URI of the form <code>zcash:?address=<address>&...</code> where <code><address></code> is an instance of <code>zcashaddress</code>.</p>
|
||||
<p>If there are any non-address parameters having a given <code>paramindex</code>, then the URI MUST contain an address parameter having that <code>paramindex</code>. There MUST NOT be more than one occurrence of a given parameter and <code>paramindex</code>.</p>
|
||||
<p>Productions of the form <code>1*x</code> indicate one or more successive instances of the production <code>x</code>. Productions of the form <code><n>*<m>x</code> indicate at least <cite><n></cite> and at most <cite><m></cite> instances of production <code>x</code>.</p>
|
||||
<p>Note that this grammar does not allow percent encoding outside the productions that use <code>qchar</code>, i.e. the values of label, message, <code>reqparam</code>, and <code>otherparam</code> parameters.</p>
|
||||
<p>Here, <code>ALPHA</code>, <code>unreserved</code> and <code>pct-encoded</code> are as defined in <a id="id6" class="footnote_reference" href="#rfc3986">3</a>. "base64url" is defined as in <a id="id7" class="footnote_reference" href="#base64url">4</a> with padding omitted. (Note that this uses a different alphabet to the usual base64; the values 62 and 63 in the alphabet are encoded as <code>-</code> and <code>_</code> respectively. Implementations MUST NOT accept the characters <code>+</code>, <code>/</code>, and <code>=</code> that occur only in the usual base64.)</p>
|
||||
<p>Productions of the form <code>1*x</code> indicate one or more successive instances of the production <code>x</code>. Productions of the form <code><n>*<m>x</code> indicate at least <cite><n></cite> and at most <cite><m></cite> instances of production <code>x</code>.</p>
|
||||
<p>Note that this grammar does not allow percent encoding outside the productions that use <code>qchar</code>, i.e. the values of label, message, <code>reqparam</code>, and <code>otherparam</code> parameters.</p>
|
||||
</section>
|
||||
<section id="uri-semantics"><h3><span class="section-heading">URI Semantics</span><span class="section-anchor"> <a rel="bookmark" href="#uri-semantics"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A ZIP-321 URI represents a request for the construction of a transaction having one or more <em>payments</em>. In the case that only a single payment is being requested, the recipient address SHOULD be included in the <code>hier-part</code> component of the RFC 3986 URI; otherwise, multiple recipient addresses can be specified using <code>addrparam</code> parameters with different indices.</p>
|
||||
<p>Addresses, amounts, labels, and messages sharing the same <code>paramindex</code> (including the empty <code>paramindex</code>) are interpreted to be associated with the same payment for the purposes of payment construction. A <code>paramindex</code> MUST NOT have leading zero(s). There is no significance to the ordering of parameters, and <code>paramindex</code> values need not be sequential.</p>
|
||||
<p>Due to restrictions on transaction construction described in <a id="id8" class="footnote_reference" href="#protocol-saplingbalance">11</a>, there may be no more than 2109 distinct payments requested by a single ZIP-321 URI.</p>
|
||||
<p>A URI of the form <code>zcash:<address>?...</code> MUST be considered equivalent to a URI of the form <code>zcash:?address=<address>&...</code> where <code><address></code> is an instance of <code>zcashaddress</code>.</p>
|
||||
<p>If there are any non-address parameters having a given <code>paramindex</code>, then the URI MUST contain an address parameter having that <code>paramindex</code>. There MUST NOT be more than one occurrence of a given parameter and <code>paramindex</code>.</p>
|
||||
<p>Implementations SHOULD check that each instance of <code>zcashaddress</code> is a valid string encoding of either:</p>
|
||||
<ul>
|
||||
<li>a Zcash transparent address, using Base58Check <a id="id9" class="footnote_reference" href="#base58check">7</a> as defined in <a id="id10" class="footnote_reference" href="#protocol-transparentaddrencoding">12</a>; or</li>
|
||||
<li>a Zcash Sapling address, using Bech32 <a id="id11" class="footnote_reference" href="#zip-0173">8</a> as defined in <a id="id12" class="footnote_reference" href="#protocol-saplingpaymentaddrencoding">13</a>.</li>
|
||||
</ul>
|
||||
<p>New address formats may be added in future. If the context of whether the payment URI is intended for Testnet or Mainnet is available, then each address SHOULD be checked to be for the correct network.</p>
|
||||
<p>Sprout addresses MUST NOT be supported in payment requests. The rationale for this is that transfers to Sprout addresses will, at activation of the Canopy network upgrade, be restricted by ZIP 211 <a id="id13" class="footnote_reference" href="#zip-0211">9</a>; and it cannot generally be expected that senders will have funds available in the Sprout pool with which to satisfy requests for payment to a Sprout address.</p>
|
||||
</section>
|
||||
<section id="transfer-amount"><h3><span class="section-heading">Transfer amount</span><span class="section-anchor"> <a rel="bookmark" href="#transfer-amount"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>If an amount is provided, it MUST be specified in decimal ZEC. If a decimal fraction is present then a period (<cite>.</cite>) MUST be used as the separating character to separate the whole number from the decimal fraction, and both the whole number and the decimal fraction MUST be nonempty. No other separators (such as commas for grouping or thousands) are permitted. Leading zeros in the whole number or trailing zeros in the decimal fraction are ignored. There MUST NOT be more than 8 digits in the decimal fraction.</p>
|
||||
<dl>
|
||||
|
|
@ -148,10 +159,18 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0021" class="footnote">
|
||||
<table id="base64url" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="https://www.rfc-editor.org/rfc/rfc4648.html#section-5">RFC 4648 section 5: Base64 Encoding with URL and Filename Safe Alphabet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0021" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki">BIP 21: URI Scheme</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
@ -159,32 +178,64 @@ zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1</pre>
|
|||
<table id="bip-0070" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<th>6</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki">BIP 70: Payment Protocol</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="base58check" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Base58Check_encoding">Base58Check encoding</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="base64url" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="https://tools.ietf.org/html/rfc4648#section-5">RFC 4648 section 5: Base64 Encoding with URL and Filename Safe Alphabet</a></td>
|
||||
<td><a href="https://en.bitcoin.it/wiki/Base58Check_encoding">Bitcoin Wiki: Base58Check encoding</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="saplingoutputs" class="footnote">
|
||||
<table id="zip-0173" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingbalance">Restrictions on number of outputs in Zcash transactions</a></td>
|
||||
<td><a href="zip-0173">ZIP 173: Bech32 Format</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0211" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="zip-0211">ZIP 211: Disabling Addition of New Value to the Sprout Value Pool</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-networks" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>10</th>
|
||||
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.14 or later. Section 3.11: Mainnet and Testnet</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingbalance" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>11</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingbalance">Zcash Protocol Specification, Version 2020.1.14 or later. Section 4.12: Balance and Binding Signature (Sapling)</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-transparentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>12</th>
|
||||
<td><a href="protocol/protocol.pdf#transparentaddrencoding">Zcash Protocol Specification, Version 2020.1.14 or later. Section 5.6.1: Transparent Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol-saplingpaymentaddrencoding" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>13</th>
|
||||
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2020.1.14 or later. Section 5.6.4: Sapling Payment Addresses</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
69
zip-0321.rst
69
zip-0321.rst
|
|
@ -18,6 +18,9 @@ Terminology
|
|||
The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this
|
||||
document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The terms "Testnet" and "Mainnet" are to be interpreted as described in
|
||||
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
payment
|
||||
|
|
@ -76,14 +79,15 @@ memo) tuples.
|
|||
Specification
|
||||
=============
|
||||
|
||||
The following syntax specification uses ABNF [#RFC5234]_.
|
||||
URI Syntax
|
||||
----------
|
||||
|
||||
URI Syntax:
|
||||
The following syntax specification uses ABNF [#RFC5234]_.
|
||||
|
||||
.. code-block:: EBNF
|
||||
|
||||
zcashurn = "zcash:" ( zcashaddress [ "?" zcashparams ] / "?" zcashparams )
|
||||
zcashaddress = 1*base58
|
||||
zcashaddress = 1*( ALPHA / DIGIT )
|
||||
zcashparams = zcashparam [ "&" zcashparams ]
|
||||
zcashparam = [ addrparam / amountparam / memoparam / messageparam / labelparam / reqparam / otherparam ]
|
||||
NONZERO = %x31-39
|
||||
|
|
@ -101,10 +105,22 @@ URI Syntax:
|
|||
allowed-delims = "!" / "$" / "'" / "(" / ")" / "*" / "+" / "," / ";"
|
||||
|
||||
Here, ``ALPHA``, ``unreserved`` and ``pct-encoded`` are as defined in
|
||||
[#RFC3986]_. "base58" is defined as in [#base58check]_. "base64url" is defined
|
||||
as in [#base64url]_ with padding omitted. (Note that this uses a different
|
||||
alphabet to the usual base64; the values 62 and 63 in the alphabet are encoded
|
||||
as ``-`` and ``_`` respectively.)
|
||||
[#RFC3986]_. "base64url" is defined as in [#base64url]_ with padding omitted.
|
||||
(Note that this uses a different alphabet to the usual base64; the values 62 and
|
||||
63 in the alphabet are encoded as ``-`` and ``_`` respectively. Implementations
|
||||
MUST NOT accept the characters ``+``, ``/``, and ``=`` that occur only in the
|
||||
usual base64.)
|
||||
|
||||
Productions of the form ``1*x`` indicate one or more successive instances of the
|
||||
production ``x``. Productions of the form ``<n>*<m>x`` indicate at least `<n>` and
|
||||
at most `<m>` instances of production ``x``.
|
||||
|
||||
Note that this grammar does not allow percent encoding outside the productions
|
||||
that use ``qchar``, i.e. the values of label, message, ``reqparam``, and
|
||||
``otherparam`` parameters.
|
||||
|
||||
URI Semantics
|
||||
-------------
|
||||
|
||||
A ZIP-321 URI represents a request for the construction of a transaction having
|
||||
one or more *payments*. In the case that only a single payment is being
|
||||
|
|
@ -118,9 +134,9 @@ the same payment for the purposes of payment construction. A ``paramindex``
|
|||
MUST NOT have leading zero(s). There is no significance to the ordering of
|
||||
parameters, and ``paramindex`` values need not be sequential.
|
||||
|
||||
Due to fundamental restrictions on transaction construction described in
|
||||
[#saplingoutputs]_, there may be no more than 2109 distinct payments requested
|
||||
by a single ZIP-321 URI.
|
||||
Due to restrictions on transaction construction described in
|
||||
[#protocol-saplingbalance]_, there may be no more than 2109 distinct payments
|
||||
requested by a single ZIP-321 URI.
|
||||
|
||||
A URI of the form ``zcash:<address>?...`` MUST be considered equivalent to a
|
||||
URI of the form ``zcash:?address=<address>&...`` where ``<address>`` is an
|
||||
|
|
@ -130,13 +146,23 @@ If there are any non-address parameters having a given ``paramindex``, then
|
|||
the URI MUST contain an address parameter having that ``paramindex``. There
|
||||
MUST NOT be more than one occurrence of a given parameter and ``paramindex``.
|
||||
|
||||
Productions of the form ``1*x`` indicate one or more successive instances of the
|
||||
production ``x``. Productions of the form ``<n>*<m>x`` indicate at least `<n>` and
|
||||
at most `<m>` instances of production ``x``.
|
||||
Implementations SHOULD check that each instance of ``zcashaddress`` is a valid
|
||||
string encoding of either:
|
||||
|
||||
Note that this grammar does not allow percent encoding outside the productions
|
||||
that use ``qchar``, i.e. the values of label, message, ``reqparam``, and
|
||||
``otherparam`` parameters.
|
||||
* a Zcash transparent address, using Base58Check [#base58check]_ as defined
|
||||
in [#protocol-transparentaddrencoding]_; or
|
||||
* a Zcash Sapling address, using Bech32 [#zip-0173]_ as defined in
|
||||
[#protocol-saplingpaymentaddrencoding]_.
|
||||
|
||||
New address formats may be added in future. If the context of whether the
|
||||
payment URI is intended for Testnet or Mainnet is available, then each address
|
||||
SHOULD be checked to be for the correct network.
|
||||
|
||||
Sprout addresses MUST NOT be supported in payment requests. The rationale for
|
||||
this is that transfers to Sprout addresses will, at activation of the Canopy
|
||||
network upgrade, be restricted by ZIP 211 [#zip-0211]_; and it cannot generally
|
||||
be expected that senders will have funds available in the Sprout pool with which
|
||||
to satisfy requests for payment to a Sprout address.
|
||||
|
||||
Transfer amount
|
||||
---------------
|
||||
|
|
@ -268,8 +294,13 @@ References
|
|||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#RFC5234] `RFC 5234: Augmented BNF for Syntax Specifications: ABNF <https://www.rfc-editor.org/rfc/rfc5234.html>`_
|
||||
.. [#RFC3986] `RFC 3986: URI Generic Syntax, Appendix A. Collected ABNF for URI <https://www.rfc-editor.org/rfc/rfc3986.html#appendix-A>`_
|
||||
.. [#base64url] `RFC 4648 section 5: Base64 Encoding with URL and Filename Safe Alphabet <https://www.rfc-editor.org/rfc/rfc4648.html#section-5>`_
|
||||
.. [#bip-0021] `BIP 21: URI Scheme <https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki>`_
|
||||
.. [#bip-0070] `BIP 70: Payment Protocol <https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki>`_
|
||||
.. [#base58check] `Base58Check encoding <https://en.bitcoin.it/wiki/Base58Check_encoding>`_
|
||||
.. [#base64url] `RFC 4648 section 5: Base64 Encoding with URL and Filename Safe Alphabet <https://tools.ietf.org/html/rfc4648#section-5>`_
|
||||
.. [#saplingoutputs] `Restrictions on number of outputs in Zcash transactions <https://zips.z.cash/protocol/protocol.pdf#saplingbalance>`_
|
||||
.. [#base58check] `Bitcoin Wiki: Base58Check encoding <https://en.bitcoin.it/wiki/Base58Check_encoding>`_
|
||||
.. [#zip-0173] `ZIP 173: Bech32 Format <zip-0173.rst>`_
|
||||
.. [#zip-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <zip-0211.rst>`_
|
||||
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.14 or later. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
|
||||
.. [#protocol-saplingbalance] `Zcash Protocol Specification, Version 2020.1.14 or later. Section 4.12: Balance and Binding Signature (Sapling) <protocol/protocol.pdf#saplingbalance>`_
|
||||
.. [#protocol-transparentaddrencoding] `Zcash Protocol Specification, Version 2020.1.14 or later. Section 5.6.1: Transparent Addresses <protocol/protocol.pdf#transparentaddrencoding>`_
|
||||
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.14 or later. Section 5.6.4: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue