mirror of https://github.com/zcash/zips.git
ZIP 321: rST fixes; generate HTML and index.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
70e5729e79
commit
a78a1291fa
|
|
@ -112,7 +112,7 @@ Index of ZIPs
|
|||
<tr> <td>310</td> <td class="left"><a href="zip-0310.rst">Security Properties of Sapling Viewing Keys</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">311</span></td> <td class="left"><a class="reserved" href="zip-0311.rst">Sapling Payment Disclosure</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">312</span></td> <td class="left"><a class="reserved" href="zip-0312.rst">Shielded Multisignatures using FROST</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">321</span></td> <td class="left"><a class="reserved" href="zip-0321.rst">Payment Request URIs</a></td> <td>Reserved</td>
|
||||
<tr> <td>321</td> <td class="left"><a href="zip-0321.rst">Payment Request URIs</a></td> <td>Proposed</td>
|
||||
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339.rst">Wallet Recovery Words</a></td> <td>Reserved</td>
|
||||
<tr> <td>400</td> <td class="left"><a href="zip-0400.rst">Wallet.dat format</a></td> <td>Draft</td>
|
||||
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing mempool denial-of-service</a></td> <td>Final</td>
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@
|
|||
<tr> <td>310</td> <td class="left"><a href="zip-0310">Security Properties of Sapling Viewing Keys</a></td> <td>Draft</td>
|
||||
<tr> <td><span class="reserved">311</span></td> <td class="left"><a class="reserved" href="zip-0311">Sapling Payment Disclosure</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">312</span></td> <td class="left"><a class="reserved" href="zip-0312">Shielded Multisignatures using FROST</a></td> <td>Reserved</td>
|
||||
<tr> <td><span class="reserved">321</span></td> <td class="left"><a class="reserved" href="zip-0321">Payment Request URIs</a></td> <td>Reserved</td>
|
||||
<tr> <td>321</td> <td class="left"><a href="zip-0321">Payment Request URIs</a></td> <td>Proposed</td>
|
||||
<tr> <td><span class="reserved">339</span></td> <td class="left"><a class="reserved" href="zip-0339">Wallet Recovery Words</a></td> <td>Reserved</td>
|
||||
<tr> <td>400</td> <td class="left"><a href="zip-0400">Wallet.dat format</a></td> <td>Draft</td>
|
||||
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing mempool denial-of-service</a></td> <td>Final</td>
|
||||
|
|
|
|||
163
zip-0321.html
163
zip-0321.html
|
|
@ -10,10 +10,169 @@
|
|||
Title: Payment Request URIs
|
||||
Owners: Kris Nuttycombe (kris@electriccoin.co)
|
||||
Daira Hopwood (daira@electriccoin.co)
|
||||
Status: Reserved
|
||||
Status: Proposed
|
||||
Category: Wallet
|
||||
Created: 2020-08-28
|
||||
Discussions-To: <<a href="https://github.com/zcash/zips/issues/347">https://github.com/zcash/zips/issues/347</a>>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/395">https://github.com/zcash/zips/pull/395</a>></pre>
|
||||
Pull-Request: <<a href="https://github.com/zcash/zips/pull/395">https://github.com/zcash/zips/pull/395</a>>
|
||||
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 below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>payment</dt>
|
||||
<dd>A transfer of funds implemented by a shielded or transparent output of a single Zcash transaction.</dd>
|
||||
</dl>
|
||||
</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP proposes a standard format for payment request URIs. Wallets that recognize this format enable users to construct payments simply by clicking links on webpages or scanning QR codes.</p>
|
||||
</section>
|
||||
<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>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>
|
||||
<p>The format must be a valid URI.</p>
|
||||
<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>
|
||||
<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>
|
||||
<span class="k">DIGIT </span><span class="err">=</span> <span class="err">%</span><span class="k">x30-39</span>
|
||||
<span class="k">paramindex </span><span class="err">=</span> <span class="s2">"."</span> <span class="k">NONZERO </span><span class="err">*</span><span class="k">DIGIT</span>
|
||||
<span class="k">addrparam </span><span class="err">=</span> <span class="s2">"address"</span> <span class="p">[</span> <span class="k">paramindex </span><span class="p">]</span> <span class="s2">"="</span> <span class="k">zcashaddress</span>
|
||||
<span class="k">amountparam </span><span class="err">=</span> <span class="s2">"amount"</span> <span class="p">[</span> <span class="k">paramindex </span><span class="p">]</span> <span class="s2">"="</span> <span class="err">1*</span><span class="k">DIGIT </span><span class="p">[</span> <span class="s2">"."</span> <span class="err">1*8</span><span class="k">DIGIT </span><span class="p">]</span>
|
||||
<span class="k">labelparam </span><span class="err">=</span> <span class="s2">"label"</span> <span class="p">[</span> <span class="k">paramindex </span><span class="p">]</span> <span class="s2">"="</span> <span class="err">*</span><span class="k">qchar</span>
|
||||
<span class="k">memoparam </span><span class="err">=</span> <span class="s2">"memo"</span> <span class="p">[</span> <span class="k">paramindex </span><span class="p">]</span> <span class="s2">"="</span> <span class="err">*</span><span class="k">base64url</span>
|
||||
<span class="k">messageparam </span><span class="err">=</span> <span class="s2">"message"</span> <span class="p">[</span> <span class="k">paramindex </span><span class="p">]</span> <span class="s2">"="</span> <span class="err">*</span><span class="k">qchar</span>
|
||||
<span class="k">paramname </span><span class="err">=</span> <span class="k">ALPHA </span><span class="err">*</span><span class="p">(</span> <span class="k">ALPHA </span><span class="err">/</span> <span class="k">DIGIT </span><span class="err">/</span> <span class="s2">"+"</span> <span class="err">/</span> <span class="s2">"-"</span> <span class="p">)</span>
|
||||
<span class="k">reqparam </span><span class="err">=</span> <span class="s2">"req-"</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">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 MAY 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>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>
|
||||
<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>
|
||||
<dt>For example,</dt>
|
||||
<dd>
|
||||
<ul>
|
||||
<li><code>amount=50.00</code> or <code>amount=50</code> or <code>amount=050</code> is treated as 50 ZEC;</li>
|
||||
<li><code>amount=0.5</code> or <code>amount=00.500</code> is treated as 0.5 ZEC; and</li>
|
||||
<li><code>amount=50,000.00</code> or <code>amount=50,00</code> or <code>amount=50.</code> or <code>amount=.5</code> or <code>amount=0.123456789</code> are invalid.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="query-keys"><h3><span class="section-heading">Query Keys</span><span class="section-anchor"> <a rel="bookmark" href="#query-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<dl>
|
||||
<dt>label</dt>
|
||||
<dd>Label for an address (e.g. name of receiver)</dd>
|
||||
<dt>address</dt>
|
||||
<dd>Zcash address string (shielded or transparent)</dd>
|
||||
<dt>memo</dt>
|
||||
<dd>Contents for the Zcash shielded memo field, encoded as base64url without <code>=</code> padding. The decoded memo contents MUST NOT exceed 512 bytes, and if shorter, will be filled with trailing zeros to 512 bytes. Parsers MUST consider the entire URI invalid if the address associated with the same <code>paramindex</code> is not a valid shielded address.</dd>
|
||||
<dt>message</dt>
|
||||
<dd>Message that clients can display for the purpose of presenting descriptive information about the transaction to the user.</dd>
|
||||
</dl>
|
||||
</section>
|
||||
<section id="examples"><h3><span class="section-heading">Examples</span><span class="section-anchor"> <a rel="bookmark" href="#examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<section id="valid-examples"><h4><span class="section-heading">Valid examples</span><span class="section-anchor"> <a rel="bookmark" href="#valid-examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<pre>zcash:ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez?amount=1&memo=VGhpcyBpcyBhIHNpbXBsZSBtZW1vLg&message=Thank%20you%20for%20your%20purchase</pre>
|
||||
<p>A valid payment request for a payment of 1 ZEC to a single shielded address, with a base64url-encoded memo and a message for display by the wallet.</p>
|
||||
<pre>zcash:?address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU&amount=123.456&memo=eyAia2V5IjogIlRoaXMgaXMgYSBKU09OLXN0cnVjdHVyZWQgbWVtby4iIH0&address.1=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez&amount.1=0.789&memo.1=VGhpcyBpcyBhIHVuaWNvZGUgbWVtbyDinKjwn6aE8J-PhvCfjok</pre>
|
||||
<p>A valid payment request with one transparent and one shielded recipient address, with encoded JSON and Unicode memos.</p>
|
||||
</section>
|
||||
<section id="invalid-examples"><h4><span class="section-heading">Invalid Examples</span><span class="section-anchor"> <a rel="bookmark" href="#invalid-examples"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
||||
<pre>zcash:?amount=3491405.05201255&address.1=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez&amount.1=5740296.87793245</pre>
|
||||
<p>An invalid payment request; this is missing a payment address with empty <code>paramindex</code>.</p>
|
||||
<pre>zcash:?address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU&amount=1&amount.1=2&address.2=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez</pre>
|
||||
<p>Also invalid; this request is missing <code>address.1=</code>.</p>
|
||||
<pre>zcash:?address.0=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez&amount.0=2</pre>
|
||||
<p>Also invalid; <code>address.0=</code> and <code>amount.0=</code> are not permitted as leading 0s are forbidden in <code>paramindex</code>.</p>
|
||||
<pre>zcash:?amount=1.234&amount=2.345&address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU
|
||||
|
||||
zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU"</pre>
|
||||
<p>Also invalid; duplicate <code>amount=</code> or <code>amount.1=</code> fields</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="forward-compatibility"><h3><span class="section-heading">Forward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#forward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Variables which are prefixed with a <code>req-</code> are considered required. If a parser does not recognize any variables which are prefixed with <code>req-</code>, it MUST consider the entire URI invalid. Any other variables that are not recognized, but that are not prefixed with a <code>req-</code>, SHOULD be ignored.</p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h3><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>As this ZIP is written, several clients already implement a <code>zcash:</code> URI scheme similar to this one, however usually without the additional <code>req-</code> prefix requirement or the facility to specify multiple payments using <code>paramindex</code>. Thus, it is RECOMMENDED that these features not be used in a mission-critical way until a grace period of 6 months from the finalization of this ZIP has passed, in order to allow client developers to release new versions, and users of old clients to upgrade.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<table id="rfc2119" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>1</th>
|
||||
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="rfc5234" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="https://www.rfc-editor.org/rfc/rfc5234.html">RFC 5234: Augmented BNF for Syntax Specifications: ABNF</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="rfc3986" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="https://www.rfc-editor.org/rfc/rfc3986.html#appendix-A">RFC 3986: URI Generic Syntax, Appendix A. Collected ABNF for URI</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0021" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki">BIP 21: URI Scheme</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip-0070" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</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>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
||||
16
zip-0321.rst
16
zip-0321.rst
|
|
@ -52,8 +52,8 @@ wallet vendors may support so that human intervention is required only for
|
|||
approval, not creation, of such a payment transaction.
|
||||
|
||||
In Bitcoin, two different standards exist to permit vendors to issue payment
|
||||
requests that are understood by wallets: BIP-0021 [#BIP0021]_ and BIP-0070
|
||||
[#BIP0070]_. BIP-0021 provides a URI format that can be interpreted by a
|
||||
requests that are understood by wallets: BIP-0021 [#bip-0021]_ and BIP-0070
|
||||
[#bip-0070]_. 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.
|
||||
|
|
@ -171,14 +171,14 @@ Examples
|
|||
Valid examples
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block::
|
||||
::
|
||||
|
||||
zcash:ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez?amount=1&memo=VGhpcyBpcyBhIHNpbXBsZSBtZW1vLg&message=Thank%20you%20for%20your%20purchase
|
||||
|
||||
A valid payment request for a payment of 1 ZEC to a single shielded address,
|
||||
with a base64url-encoded memo and a message for display by the wallet.
|
||||
|
||||
.. code-block::
|
||||
::
|
||||
|
||||
zcash:?address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU&amount=123.456&memo=eyAia2V5IjogIlRoaXMgaXMgYSBKU09OLXN0cnVjdHVyZWQgbWVtby4iIH0&address.1=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez&amount.1=0.789&memo.1=VGhpcyBpcyBhIHVuaWNvZGUgbWVtbyDinKjwn6aE8J-PhvCfjok
|
||||
|
||||
|
|
@ -188,26 +188,26 @@ with encoded JSON and Unicode memos.
|
|||
Invalid Examples
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block::
|
||||
::
|
||||
|
||||
zcash:?amount=3491405.05201255&address.1=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez&amount.1=5740296.87793245
|
||||
|
||||
An invalid payment request; this is missing a payment address with empty ``paramindex``.
|
||||
|
||||
.. code-block::
|
||||
::
|
||||
|
||||
zcash:?address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU&amount=1&amount.1=2&address.2=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez
|
||||
|
||||
Also invalid; this request is missing ``address.1=``.
|
||||
|
||||
.. code-block::
|
||||
::
|
||||
|
||||
zcash:?address.0=ztestsapling10yy2ex5dcqkclhc7z7yrnjq2z6feyjad56ptwlfgmy77dmaqqrl9gyhprdx59qgmsnyfska2kez&amount.0=2
|
||||
|
||||
Also invalid; ``address.0=`` and ``amount.0=`` are not permitted as leading 0s are
|
||||
forbidden in ``paramindex``.
|
||||
|
||||
.. code-block::
|
||||
::
|
||||
|
||||
zcash:?amount=1.234&amount=2.345&address=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue