zecfoundation
/
zips
mirror of https://github.com/ZcashFoundation/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update references to protocol spec from process and consensus ZIPs (0 to 252 inclusive, and 1014). 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-10-02 00:44:09 +01:00
parent 1ac6d917b8
commit 5ced374bf1
56 changed files with 490 additions and 484 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
zip-0032.html
View File

@ -25,7 +25,7 @@ License: MIT</pre>
<p>The key words "MUST", "MUST NOT", 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>"Jubjub" refers to the elliptic curve defined in <a id="id2" class="footnote_reference" href="#protocol-jubjub">13</a>.</p>
<p>A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id3" 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="id3" class="footnote_reference" href="#protocol-networks">9</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 <a id="id4" class="footnote_reference" href="#bip-0032">2</a>, to support Zcash's shielded addresses.</p>
@ -984,7 +984,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2020.1.24 or later [NU5 proposal]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]</a></td>
</tr>
</tbody>
</table>
@ -992,7 +992,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/nu5.pdf#networks">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -1000,7 +1000,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/nu5.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 4.2.2: Sapling Key Components</a></td>
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.2: Sapling Key Components</a></td>
</tr>
</tbody>
</table>
@ -1008,7 +1008,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/nu5.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.1.6: DiversifyHash Hash Function</a></td>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
</tr>
</tbody>
</table>
@ -1016,7 +1016,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/nu5.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature</a></td>
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature</a></td>
</tr>
</tbody>
</table>
@ -1024,7 +1024,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/nu5.pdf#jubjub">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.8.3: Jubjub</a></td>
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub</a></td>
</tr>
</tbody>
</table>
@ -1032,7 +1032,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/nu5.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.2.1: Sprout Shielded Payment Addresses</a></td>
<td><a href="protocol/protocol.pdf#sproutpaymentaddrencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.1: Sprout Payment Addresses</a></td>
</tr>
</tbody>
</table>
@ -1040,7 +1040,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>15</th>
<td><a href="protocol/nu5.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys</a></td>
<td><a href="protocol/protocol.pdf#sproutspendingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys</a></td>
</tr>
</tbody>
</table>
@ -1048,7 +1048,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>16</th>
<td><a href="protocol/nu5.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys</a></td>
<td><a href="protocol/protocol.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys</a></td>
</tr>
</tbody>
</table>
@ -1056,7 +1056,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>17</th>
<td><a href="protocol/nu5.pdf#saplingspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys</a></td>
<td><a href="protocol/protocol.pdf#saplingspendingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys</a></td>
</tr>
</tbody>
</table>
@ -1064,7 +1064,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>18</th>
<td><a href="protocol/nu5.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.3: Orchard Full Viewing Keys</a></td>
<td><a href="protocol/protocol.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys</a></td>
</tr>
</tbody>
</table>
@ -1072,7 +1072,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>19</th>
<td><a href="protocol/nu5.pdf#orchardspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.4: Orchard Spending Keys</a></td>
<td><a href="protocol/protocol.pdf#orchardspendingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys</a></td>
</tr>
</tbody>
</table>

26
zip-0032.rst
View File

@ -25,7 +25,7 @@ The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpret
A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive
descendant keys and addresses of that key.
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash
Protocol Specification [#protocol-networks]_.
@ -630,16 +630,16 @@ References
.. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>`_
.. [#slip-0044] `SLIP 44: Registered coin types for BIP-0044 <https://github.com/satoshilabs/slips/blob/master/slip-0044.md>`_
.. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs <https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.24 or later [NU5 proposal] <protocol/nu5.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet <protocol/nu5.pdf#networks>`_
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 4.2.2: Sapling Key Components <protocol/nu5.pdf#saplingkeycomponents>`_
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.1.6: DiversifyHash Hash Function <protocol/nu5.pdf#concretediversifyhash>`_
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature <protocol/nu5.pdf#concretespendauthsig>`_
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.8.3: Jubjub <protocol/nu5.pdf#jubjub>`_
.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.2.1: Sprout Shielded Payment Addresses <protocol/nu5.pdf#sproutpaymentaddrencoding>`_
.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys <protocol/nu5.pdf#sproutspendingkeyencoding>`_
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys <protocol/nu5.pdf#saplingfullviewingkeyencoding>`_
.. [#protocol-saplingspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys <protocol/nu5.pdf#saplingspendingkeyencoding>`_
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.3: Orchard Full Viewing Keys <protocol/nu5.pdf#orchardfullviewingkeyencoding>`_
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.4: Orchard Spending Keys <protocol/nu5.pdf#orchardspendingkeyencoding>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions <protocol/protocol.pdf#concretediversifyhash>`_
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature <protocol/protocol.pdf#concretespendauthsig>`_
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub <protocol/protocol.pdf#jubjub>`_
.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.1: Sprout Payment Addresses <protocol/protocol.pdf#sproutpaymentaddrencoding>`_
.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys <protocol/protocol.pdf#sproutspendingkeyencoding>`_
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
.. [#protocol-saplingspendingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys <protocol/protocol.pdf#saplingspendingkeyencoding>`_
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys <protocol/protocol.pdf#orchardfullviewingkeyencoding>`_
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys <protocol/protocol.pdf#orchardspendingkeyencoding>`_
.. [#NIST-SP-800-38G] `NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption <https://dx.doi.org/10.6028/NIST.SP.800-38G>`_

2
zip-0143.html
View File

@ -360,7 +360,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#sproutsend">Zcash Protocol Specification, Version 2020.1.15. Section 4.6: Sending Notes (Sprout)</a></td>
<td><a href="protocol/protocol.pdf#sproutsend">Zcash Protocol Specification, Version 2021.2.16. Section 4.7.1: Sending Notes (Sprout)</a></td>
</tr>
</tbody>
</table>

2
zip-0143.rst
View File

@ -455,7 +455,7 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-sproutsend] `Zcash Protocol Specification, Version 2020.1.15. Section 4.6: Sending Notes (Sprout) <protocol/protocol.pdf#sproutsend>`_
.. [#protocol-sproutsend] `Zcash Protocol Specification, Version 2021.2.16. Section 4.7.1: Sending Notes (Sprout) <protocol/protocol.pdf#sproutsend>`_
.. [#wiki-checksig] `OP\_CHECKSIG. Bitcoin Wiki <https://en.bitcoin.it/wiki/OP_CHECKSIG>`_
.. [#quadratic]
* `CVE-2013-2292 <https://nvd.nist.gov/vuln/detail/CVE-2013-2292>`_

4
zip-0155.html
View File

@ -20,7 +20,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 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 term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</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="id3" class="footnote_reference" href="#protocol-networks">2</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="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
<p>"P2P network" means the Zcash peer-to-peer network.</p>
<p><code>uint8</code>, <code>uint16</code>, and <code>uint32</code> denote unsigned integer data types of the corresponding length (8, 16, or 32 bits respectively).</p>
</section>
@ -196,7 +196,7 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 3.12 Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>

4
zip-0155.rst
View File

@ -23,7 +23,7 @@ The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
"P2P network" means the Zcash peer-to-peer network.
@ -236,7 +236,7 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 3.12 Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#bip-0155] `BIP 155: addrv2 message <https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0239] `ZIP 239: Relay of Version 5 Transactions <zip-0239.rst>`_

2
zip-0173.html
View File

@ -362,7 +362,7 @@ def bech32_verify_checksum(hrp, data):
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>

2
zip-0173.rst
View File

@ -462,7 +462,7 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_

6
zip-0203.html
View File

@ -50,7 +50,7 @@ License: MIT</pre>
<p>On Blossom activation <a id="id1" class="footnote_reference" href="#zip-0206">2</a>, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.</p>
</section>
<section id="changes-for-nu5"><h3><span class="section-heading">Changes for NU5</span><span class="section-anchor"> <a rel="bookmark" href="#changes-for-nu5"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <a id="id2" class="footnote_reference" href="#zip-0252">3</a>, the <code>nExpiryHeight</code> field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on <code>nExpiryHeight</code> is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencodingandconsensus">4</a>.</p>
<p>As mentioned above, <code>nExpiryHeight</code> is ignored for coinbase transactions. However, from NU5 activation <a id="id2" class="footnote_reference" href="#zip-0252">3</a>, the <code>nExpiryHeight</code> field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on <code>nExpiryHeight</code> is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencoding">4</a>.</p>
</section>
<section id="wallet-behavior-and-ui"><h3><span class="section-heading">Wallet behavior and UI</span><span class="section-anchor"> <a rel="bookmark" href="#wallet-behavior-and-ui"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.</p>
@ -99,11 +99,11 @@ License: MIT</pre>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.2.6. Section 7.1: Transaction Encoding and Consensus</a></td>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>

4
zip-0203.rst
View File

@ -93,7 +93,7 @@ NU5 activation [#zip-0252]_, the ``nExpiryHeight`` field of a coinbase transacti
be set equal to the block height. Also, for coinbase transactions only, the bound of
499999999 on ``nExpiryHeight`` is removed. The motivation is to ensure that transaction
IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol
specification [#protocol-txnencodingandconsensus]_.
specification [#protocol-txnencoding]_.
Wallet behavior and UI
----------------------
@ -145,4 +145,4 @@ References
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.2.6. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencodingandconsensus>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_

14
zip-0205.html
View File

@ -17,7 +17,7 @@ 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" and "SHOULD" 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 "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">7</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="id3" class="footnote_reference" href="#protocol-networks">3</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="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Sapling</dt>
@ -61,7 +61,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
</section>
<section id="change-to-difficulty-adjustment-on-testnet"><h3><span class="section-heading">Change to difficulty adjustment on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#change-to-difficulty-adjustment-on-testnet"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Section 7.6.3 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">5</a> describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the <code>nTime</code> and <code>nBits</code> fields of preceding blocks.</p>
<p>This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.6.4 of that specification <a id="id12" class="footnote_reference" href="#protocol-nbits">6</a>.</p>
<p>This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id11" class="footnote_reference" href="#protocol-constants">4</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id12" class="footnote_reference" href="#protocol-nbits">6</a>.</p>
<p>Note: a previous revision of this ZIP incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
<p>This change does not affect Mainnet.</p>
</section>
@ -86,7 +86,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
@ -94,7 +94,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -102,7 +102,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants</a></td>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
@ -110,7 +110,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment</a></td>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
</tr>
</tbody>
</table>
@ -118,7 +118,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#nbits">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion</a></td>
<td><a href="protocol/protocol.pdf#nbits">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion</a></td>
</tr>
</tbody>
</table>

14
zip-0205.rst
View File

@ -20,7 +20,7 @@ The terms "consensus branch" and "network upgrade" in this document are to be
interpreted as described in ZIP 200. [#zip-0200]_
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
The terms below are to be interpreted as follows:
@ -109,7 +109,7 @@ is greater than 15 minutes after that of the preceding block, then the block is
minimum-difficulty block. In that case its ``nBits`` field MUST be set to
ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3
of the Zcash Protocol Specification [#protocol-constants]_, and ToCompact is as
defined in section 7.6.4 of that specification [#protocol-nbits]_.
defined in section 7.7.4 of that specification [#protocol-nbits]_.
Note: a previous revision of this ZIP incorrectly said that only the target
threshold of minimum-difficulty blocks is affected. In fact the ``nBits`` field
@ -144,11 +144,11 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-nbits] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion <protocol/protocol.pdf#nbits>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-nbits] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion <protocol/protocol.pdf#nbits>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling <zip-0243.rst>`_

2
zip-0206.html
View File

@ -83,7 +83,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>

2
zip-0206.rst
View File

@ -122,7 +122,7 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

34
zip-0207.html
View File

@ -17,16 +17,16 @@ Created: 2019-01-04
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", "SHOULD", "SHOULD NOT", 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 "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">4</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">7</a></p>
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">7</a></p>
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">10</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Canopy</dt>
<dd>Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</dd>
<dt>Testnet</dt>
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol-networks">3</a></dd>
<dd>The Zcash test network, as defined in the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#protocol-networks">4</a></dd>
<dt>Mainnet</dt>
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol-networks">3</a></dd>
<dd>The Zcash production network, as defined in the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#protocol-networks">4</a></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>
@ -235,23 +235,23 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-subsidyconcepts" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/canopy.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -259,7 +259,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/canopy.pdf#constants">Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants</a></td>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
@ -267,7 +267,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/canopy.pdf#diffadjustment">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment</a></td>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
</tr>
</tbody>
</table>
@ -275,7 +275,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/canopy.pdf#subsidies">Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
<td><a href="protocol/protocol.pdf#subsidies">Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward</a></td>
</tr>
</tbody>
</table>
@ -283,7 +283,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/canopy.pdf#foundersreward">Zcash Protocol Specification, Version 2020.1.15. Section 7.8: Payment of Founders' Reward</a></td>
<td><a href="protocol/protocol.pdf#foundersreward">Zcash Protocol Specification, Version 2021.2.16. Section 7.9: Payment of Founders' Reward</a></td>
</tr>
</tbody>
</table>

14
zip-0207.rst
View File

@ -234,13 +234,13 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/canopy.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidyconcepts>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants <protocol/canopy.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment <protocol/canopy.pdf#diffadjustment>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/canopy.pdf#subsidies>`_
.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2020.1.15. Section 7.8: Payment of Founders' Reward <protocol/canopy.pdf#foundersreward>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidyconcepts>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward <protocol/protocol.pdf#subsidies>`_
.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2021.2.16. Section 7.9: Payment of Founders' Reward <protocol/protocol.pdf#foundersreward>`_
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_

24
zip-0208.html
View File

@ -20,7 +20,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<p>The key words "MUST" and "SHOULD" 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 "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in <a id="id2" class="footnote_reference" href="#zip-0200">9</a>.</p>
<p>The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-diffadjustment">6</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="id4" class="footnote_reference" href="#protocol-networks">4</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="id4" class="footnote_reference" href="#protocol-networks">4</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade <a id="id5" class="footnote_reference" href="#zip-0206">11</a>.</p>
@ -42,7 +42,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<p>In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing to the list of integer constants.</p>
<p>In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.</p>
<p>For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in <a id="id9" class="footnote_reference" href="#zip-0206">11</a>.</p>
<p>In section 7.6.3 (Difficulty adjustment), make the following changes:</p>
<p>In section 7.6.3 (Difficulty adjustment) [later moved to section 7.7.3], make the following changes:</p>
<p>Define IsBlossomActivated(<em>height</em>) to return true if <em>height</em> ≥ BlossomActivationHeight, otherwise false.</p>
<p>This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.</p>
<p>Define:</p>
@ -64,7 +64,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<li>add a <em>height</em> parameter to each of these functions that does not already have one;</li>
<li>ensure that each reference to any of these values, or to PoWTargetSpacing, are replaced with a function call passing the <em>height</em> parameter.</li>
</ul>
<p>In section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the Halving and BlockSubsidy functions as follows:</p>
<p>In section 7.7 (Calculation of Block Subsidy and Founders’ Reward) [later moved to section 7.8], redefine the Halving and BlockSubsidy functions as follows:</p>
<ul>
<li>Halving(<em>height</em>) :=
<ul>
@ -86,7 +86,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<li>(BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (<em>height</em> - BlossomActivationHeight) / PostBlossomHalvingInterval) is exactly 1 for some integer <em>height</em>.</li>
<li>MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2<sup>Halving(*height*)</sup>) is an integer for the next few periods.</li>
</ul>
<p>In section 7.8 (Payment of Founders’ Reward), define:</p>
<p>In section 7.8 (Payment of Founders’ Reward) [later moved to section 7.9], define:</p>
<ul>
<li>FounderAddressAdjustedHeight(<em>height</em>) :=
<ul>
@ -112,7 +112,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
<p>Note that the change in AveragingWindowTimespan(height) takes effect immediately when calculating the target difficulty starting from the block at the Blossom activation height, even though the difficulty of the preceding PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target spacing. Therefore it is likely that the difficulty adjustment for the first few blocks after activation will be limited by PoWMaxAdjustDown. This is not anticipated to cause any problem.</p>
<section id="minimum-difficulty-blocks-on-testnet"><h4><span class="section-heading">Minimum difficulty blocks on Testnet</span><span class="section-anchor"> <a rel="bookmark" href="#minimum-difficulty-blocks-on-testnet"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>On Testnet from block height 299188 onward, the difficulty adjustment algorithm <a id="id10" class="footnote_reference" href="#protocol-diffadjustment">6</a> allows minimum-difficulty blocks, as described in <a id="id11" class="footnote_reference" href="#zip-0205">10</a>, when the block time is greater than a given threshold. This specification changes this threshold to be proportional to the block target spacing.</p>
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is greater than 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, and ToCompact is as defined in section 7.6.4 of that specification <a id="id13" class="footnote_reference" href="#protocol-nbits">7</a>.</p>
<p>That is, if the block time of a block at height <em>height</em> ≥ 299188 is greater than 6 · PoWTargetSpacing(<em>height</em>) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its <code>nBits</code> field MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification <a id="id12" class="footnote_reference" href="#protocol-constants">5</a>, and ToCompact is as defined in section 7.7.4 of that specification <a id="id13" class="footnote_reference" href="#protocol-nbits">7</a>.</p>
<p>Note: a previous revision of this ZIP (and <a id="id14" class="footnote_reference" href="#zip-0205">10</a>) incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the <code>nBits</code> field is modified as well, and this affects difficulty adjustment for subsequent blocks.</p>
<p>This change does not affect Mainnet.</p>
</section>
@ -137,7 +137,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/237">https://githu
// chain if they are valid, and no more than a month older (both in time, and in
// best equivalent proof of work) than the best header chain we know about.</pre>
<p>We make no assertion about the significance of fingerprinting for Zcash, and (despite the word "prevent" in the above comment) no claim about the effectiveness of this mitigation.</p>
<p>In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in section 7.6.5 of the Zcash Protocol Specification <a id="id16" class="footnote_reference" href="#protocol-workdef">8</a>, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
<p>In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in section 7.7.5 of the Zcash Protocol Specification <a id="id16" class="footnote_reference" href="#protocol-workdef">8</a>, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.</p>
<p>It is not a requirement of the Zcash protocol that this fingerprinting mitigation is used; however, if it is used, then it SHOULD use the target block spacing at the same block height that is used for the current work estimate.</p>
</section>
<section id="monitoring-for-quicker-or-slower-than-expected-blocks"><h4><span class="section-heading">Monitoring for quicker- or slower-than-expected blocks</span><span class="section-anchor"> <a rel="bookmark" href="#monitoring-for-quicker-or-slower-than-expected-blocks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
@ -223,7 +223,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
@ -231,7 +231,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -239,7 +239,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants</a></td>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
@ -247,7 +247,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment</a></td>
<td><a href="protocol/protocol.pdf#diffadjustment">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment</a></td>
</tr>
</tbody>
</table>
@ -255,7 +255,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/protocol.pdf#nbits">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion</a></td>
<td><a href="protocol/protocol.pdf#nbits">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion</a></td>
</tr>
</tbody>
</table>
@ -263,7 +263,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf#workdef">Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work</a></td>
<td><a href="protocol/protocol.pdf#workdef">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work</a></td>
</tr>
</tbody>
</table>

27
zip-0208.rst
View File

@ -28,7 +28,7 @@ but "block target spacing" is the term used in the Zcash Protocol Specification
[#protocol-diffadjustment]_.)
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
Abstract
@ -84,7 +84,8 @@ In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.
For a given network (production or test), define BlossomActivationHeight as the
height at which Blossom activates on that network, as specified in [#zip-0206]_.
In section 7.6.3 (Difficulty adjustment), make the following changes:
In section 7.6.3 (Difficulty adjustment) [later moved to section 7.7.3], make the
following changes:
Define IsBlossomActivated(*height*) to return true if *height* ≥ BlossomActivationHeight,
otherwise false.
@ -112,8 +113,8 @@ ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:
- ensure that each reference to any of these values, or to PoWTargetSpacing,
are replaced with a function call passing the *height* parameter.
In section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the
Halving and BlockSubsidy functions as follows:
In section 7.7 (Calculation of Block Subsidy and Founders’ Reward) [later moved
to section 7.8], redefine the Halving and BlockSubsidy functions as follows:
- Halving(*height*) :=
@ -134,7 +135,7 @@ Note: BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTarget
- MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ )
is an integer for the next few periods.
In section 7.8 (Payment of Founders’ Reward), define:
In section 7.8 (Payment of Founders’ Reward) [later moved to section 7.9], define:
- FounderAddressAdjustedHeight(*height*) :=
@ -193,7 +194,7 @@ That is, if the block time of a block at height *height* ≥ 299188 is greater t
then the block is a minimum-difficulty block. In that case its ``nBits`` field
MUST be set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet
in section 5.3 of the Zcash Protocol Specification [#protocol-constants]_, and
ToCompact is as defined in section 7.6.4 of that specification [#protocol-nbits]_.
ToCompact is as defined in section 7.7.4 of that specification [#protocol-nbits]_.
Note: a previous revision of this ZIP (and [#zip-0205]_) incorrectly said that
only the target threshold of minimum-difficulty blocks is affected. In fact
@ -264,7 +265,7 @@ effectiveness of this mitigation.
In any case, to estimate the "best equivalent proof of work" of a given block
chain (measured in units of time), we take the total work of the chain as
defined in section 7.6.5 of the Zcash Protocol Specification [#protocol-workdef]_,
defined in section 7.7.5 of the Zcash Protocol Specification [#protocol-workdef]_,
divide by the work of the block at the active tip, and multiply by the target
block spacing of that block.
@ -395,12 +396,12 @@ References
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) <https://github.com/zcash/zips/blob/9515d73aac0aea3494f77bcd634e1e4fbd744b97/protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-nbits] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion <protocol/protocol.pdf#nbits>`_
.. [#protocol-workdef] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work <protocol/protocol.pdf#workdef>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment <protocol/protocol.pdf#diffadjustment>`_
.. [#protocol-nbits] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion <protocol/protocol.pdf#nbits>`_
.. [#protocol-workdef] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work <protocol/protocol.pdf#workdef>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade <zip-0206.rst>`_

4
zip-0209.html
View File

@ -20,7 +20,7 @@ License: MIT</pre>
<p>The "Sprout chain value pool balance" for a given block chain is the sum of all <code>vpub_old</code> fields for transactions in the block chain, minus the sum of all <code>vpub_new</code> fields for transactions in the block chain.</p>
<p>The "Sapling chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceSapling</code> fields for transactions in the block chain.</p>
<p>The "Orchard chain value pool balance" for a given block chain is the negation of the sum of all <code>valueBalanceOrchard</code> fields for transactions in the block chain. (Before NU5 has activated, the Orchard chain value pool balance is zero.)</p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</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="id3" class="footnote_reference" href="#protocol-networks">2</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines how the consensus rules are altered such that blocks that produce negative shielded chain value pool balances are prohibited.</p>
@ -51,7 +51,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15 or later. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 or later. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>

4
zip-0209.rst
View File

@ -29,7 +29,7 @@ The "Orchard chain value pool balance" for a given block chain is the negation o
``valueBalanceOrchard`` fields for transactions in the block chain. (Before NU5 has activated,
the Orchard chain value pool balance is zero.)
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the
Zcash Protocol Specification [#protocol-networks]_.
@ -84,6 +84,6 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15 or later. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 or later. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_

6
zip-0210.html
View File

@ -26,7 +26,7 @@ License: MIT</pre>
</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>The Sapling network upgrade <a id="id5" class="footnote_reference" href="#zip-0205">4</a> introduced new shielded inputs (spends) and outputs. Each spend proves the existence of the note being spent by including the anchor of a Merkle tree that contains the note's commitment, and proving in zero knowledge the existence of a path from the commitment to the anchor (a witness). Valid anchors correspond to the state of the Sapling commitment tree after each block in the chain.</p>
<p>The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format <a id="id6" class="footnote_reference" href="#protocol-txnencodingandconsensus">2</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
<p>The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format <a id="id6" class="footnote_reference" href="#protocol-txnencoding">2</a> includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.</p>
<p>Modifying the transaction format to have a single Sapling anchor field, instead of one field per Sapling spend, removes the ability (within the new transaction format version) to create transactions with this fingerprint. It also reduces the size of the transaction, costing 32 bytes per transaction instead of 32 bytes per spend.</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>
@ -58,11 +58,11 @@ License: MIT</pre>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus</a></td>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>

4
zip-0210.rst
View File

@ -49,7 +49,7 @@ correspond to the state of the Sapling commitment tree after each block in the c
The choice of anchor leaks information about the note being spent, namely that the note
was created no later than the anchor's block height. This is an unavoidable outcome of the
Zcash design, and the least information it is possible to leak about a note being spent.
However, the Sapling v4 transaction format [#protocol-txnencodingandconsensus]_ includes
However, the Sapling v4 transaction format [#protocol-txnencoding]_ includes
a separate anchor for each Sapling spend, and thus it is possible to leak additional
information by using different anchors for different notes. The anchor selection choices
could also be used as a fingerprint to identify transactions created by particular wallet
@ -113,7 +113,7 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencodingandconsensus>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0225] `ZIP 225: Version 5 Transaction Format <zip-0225.rst>`_

2
zip-0211.html
View File

@ -74,7 +74,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>

2
zip-0211.rst
View File

@ -144,7 +144,7 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
.. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Value Pool <zip-0209.rst>`_

32
zip-0212.html
View File

@ -113,8 +113,8 @@ License: MIT</pre>
.</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 specification in this ZIP is intended to be aligned with version 2021.2.6 or later of the Zcash Protocol Specification <a id="id9" class="footnote_reference" href="#protocol">2</a>.</p>
<p>Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
<p>The specification in this ZIP is intended to be aligned with version 2021.2.16 or later of the Zcash Protocol Specification <a id="id9" class="footnote_reference" href="#protocol">2</a>.</p>
<p>Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification <a id="id10" class="footnote_reference" href="#protocol-abstractprfs">3</a>. We will be adapting
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
for the purposes of this ZIP. This function is keyed by a 256-bit key
<span class="math">\(\mathsf{sk}\)</span>
@ -292,7 +292,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.6 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
@ -300,7 +300,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#abstractprfs">Zcash Protocol Specification, Version 2021.2.6. Section 4.1.2: Pseudo Random Functions</a></td>
<td><a href="protocol/protocol.pdf#abstractprfs">Zcash Protocol Specification, Version 2021.2.16. Section 4.1.2: Pseudo Random Functions</a></td>
</tr>
</tbody>
</table>
@ -308,7 +308,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#abstractcommit">Zcash Protocol Specification, Version 2021.2.6. Section 4.1.8: Commitment</a></td>
<td><a href="protocol/protocol.pdf#abstractcommit">Zcash Protocol Specification, Version 2021.2.16. Section 4.1.8: Commitment</a></td>
</tr>
</tbody>
</table>
@ -316,7 +316,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2021.2.6. Section 4.2.2: Sapling Key Components</a></td>
<td><a href="protocol/protocol.pdf#saplingkeycomponents">Zcash Protocol Specification, Version 2021.2.16. Section 4.2.2: Sapling Key Components</a></td>
</tr>
</tbody>
</table>
@ -324,7 +324,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>6</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2021.2.6. Section 4.2.3: Orchard Key Components</a></td>
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2021.2.16. Section 4.2.3: Orchard Key Components</a></td>
</tr>
</tbody>
</table>
@ -332,7 +332,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>7</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2021.2.6. Section 4.7.2: Sending Notes (Sapling)</a></td>
<td><a href="protocol/protocol.pdf#saplingsend">Zcash Protocol Specification, Version 2021.2.16. Section 4.7.2: Sending Notes (Sapling)</a></td>
</tr>
</tbody>
</table>
@ -340,7 +340,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>8</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#orchardsend">Zcash Protocol Specification, Version 2021.2.6. Section 4.7.3: Sending Notes (Orchard)</a></td>
<td><a href="protocol/protocol.pdf#orchardsend">Zcash Protocol Specification, Version 2021.2.16. Section 4.7.3: Sending Notes (Orchard)</a></td>
</tr>
</tbody>
</table>
@ -348,7 +348,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>9</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingandorchardencrypt">Zcash Protocol Specification, Version 2021.2.6. Section 4.19.1: Encryption (Sapling and Orchard)</a></td>
<td><a href="protocol/protocol.pdf#saplingandorchardencrypt">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.1: Encryption (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
@ -356,7 +356,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>10</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#decryptivk">Zcash Protocol Specification, Version 2021.2.6. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard)</a></td>
<td><a href="protocol/protocol.pdf#decryptivk">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
@ -364,7 +364,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>11</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#decryptovk">Zcash Protocol Specification, Version 2021.2.6. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard)</a></td>
<td><a href="protocol/protocol.pdf#decryptovk">Zcash Protocol Specification, Version 2021.2.16. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
@ -372,7 +372,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>12</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2021.2.6. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
<td><a href="protocol/protocol.pdf#concretediversifyhash">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions</a></td>
</tr>
</tbody>
</table>
@ -380,7 +380,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>13</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#concretesaplingkeyagreement">Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.3 Sapling Key Agreement</a></td>
<td><a href="protocol/protocol.pdf#concretesaplingkeyagreement">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.3 Sapling Key Agreement</a></td>
</tr>
</tbody>
</table>
@ -388,7 +388,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>14</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#concreteorchardkeyagreement">Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.5 Orchard Key Agreement</a></td>
<td><a href="protocol/protocol.pdf#concreteorchardkeyagreement">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.5 Orchard Key Agreement</a></td>
</tr>
</tbody>
</table>
@ -396,7 +396,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>15</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#notept">Zcash Protocol Specification, Version 2021.2.6. Section 5.5: Encodings of Note Plaintexts and Memo Fields</a></td>
<td><a href="protocol/protocol.pdf#notept">Zcash Protocol Specification, Version 2021.2.16. Section 5.5: Encodings of Note Plaintexts and Memo Fields</a></td>
</tr>
</tbody>
</table>

32
zip-0212.rst
View File

@ -112,10 +112,10 @@ concerns by using a key derivation to obtain both :math:`\mathsf{esk}` and
Specification
=============
The specification in this ZIP is intended to be aligned with version 2021.2.6
The specification in this ZIP is intended to be aligned with version 2021.2.16
or later of the Zcash Protocol Specification [#protocol]_.
Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash
Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash
Protocol Specification [#protocol-abstractprfs]_. We will be adapting
:math:`\mathsf{PRF^{expand}}` for the purposes of this ZIP. This function is
keyed by a 256-bit key :math:`\mathsf{sk}` and takes an arbitrary length byte
@ -325,20 +325,20 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.6 or later <https://zips.z.cash/protocol/protocol.pdf>`_
.. [#protocol-abstractprfs] `Zcash Protocol Specification, Version 2021.2.6. Section 4.1.2: Pseudo Random Functions <https://zips.z.cash/protocol/protocol.pdf#abstractprfs>`_
.. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2021.2.6. Section 4.1.8: Commitment <https://zips.z.cash/protocol/protocol.pdf#abstractcommit>`_
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2021.2.6. Section 4.2.2: Sapling Key Components <https://zips.z.cash/protocol/protocol.pdf#saplingkeycomponents>`_
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.2.6. Section 4.2.3: Orchard Key Components <https://zips.z.cash/protocol/protocol.pdf#orchardkeycomponents>`_
.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2021.2.6. Section 4.7.2: Sending Notes (Sapling) <https://zips.z.cash/protocol/protocol.pdf#saplingsend>`_
.. [#protocol-orchardsend] `Zcash Protocol Specification, Version 2021.2.6. Section 4.7.3: Sending Notes (Orchard) <https://zips.z.cash/protocol/protocol.pdf#orchardsend>`_
.. [#protocol-saplingandorchardencrypt] `Zcash Protocol Specification, Version 2021.2.6. Section 4.19.1: Encryption (Sapling and Orchard) <https://zips.z.cash/protocol/protocol.pdf#saplingandorchardencrypt>`_
.. [#protocol-decryptivk] `Zcash Protocol Specification, Version 2021.2.6. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard) <https://zips.z.cash/protocol/protocol.pdf#decryptivk>`_
.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.2.6. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard) <https://zips.z.cash/protocol/protocol.pdf#decryptovk>`_
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2021.2.6. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions <https://zips.z.cash/protocol/protocol.pdf#concretediversifyhash>`_
.. [#protocol-concretesaplingkeyagreement] `Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.3 Sapling Key Agreement <https://zips.z.cash/protocol/protocol.pdf#concretesaplingkeyagreement>`_
.. [#protocol-concreteorchardkeyagreement] `Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.5 Orchard Key Agreement <https://zips.z.cash/protocol/protocol.pdf#concreteorchardkeyagreement>`_
.. [#protocol-notept] `Zcash Protocol Specification, Version 2021.2.6. Section 5.5: Encodings of Note Plaintexts and Memo Fields <https://zips.z.cash/protocol/protocol.pdf#notept>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-abstractprfs] `Zcash Protocol Specification, Version 2021.2.16. Section 4.1.2: Pseudo Random Functions <protocol/protocol.pdf#abstractprfs>`_
.. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2021.2.16. Section 4.1.8: Commitment <protocol/protocol.pdf#abstractcommit>`_
.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2021.2.16. Section 4.2.2: Sapling Key Components <protocol/protocol.pdf#saplingkeycomponents>`_
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.2.16. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2021.2.16. Section 4.7.2: Sending Notes (Sapling) <protocol/protocol.pdf#saplingsend>`_
.. [#protocol-orchardsend] `Zcash Protocol Specification, Version 2021.2.16. Section 4.7.3: Sending Notes (Orchard) <protocol/protocol.pdf#orchardsend>`_
.. [#protocol-saplingandorchardencrypt] `Zcash Protocol Specification, Version 2021.2.16. Section 4.19.1: Encryption (Sapling and Orchard) <protocol/protocol.pdf#saplingandorchardencrypt>`_
.. [#protocol-decryptivk] `Zcash Protocol Specification, Version 2021.2.16. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard) <protocol/protocol.pdf#decryptivk>`_
.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.2.16. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard) <protocol/protocol.pdf#decryptovk>`_
.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2021.2.16. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions <protocol/protocol.pdf#concretediversifyhash>`_
.. [#protocol-concretesaplingkeyagreement] `Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.3 Sapling Key Agreement <protocol/protocol.pdf#concretesaplingkeyagreement>`_
.. [#protocol-concreteorchardkeyagreement] `Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.5 Orchard Key Agreement <protocol/protocol.pdf#concreteorchardkeyagreement>`_
.. [#protocol-notept] `Zcash Protocol Specification, Version 2021.2.16. Section 5.5: Encodings of Note Plaintexts and Memo Fields <protocol/protocol.pdf#notept>`_
.. [#zip-0207] `ZIP 207: Split Founders' Reward <zip-0207.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_

1
zip-0213.rst
View File

@ -24,6 +24,7 @@ The term "Sapling" in this document is to be interpreted as described in ZIP 205
The terms "Founders' Reward" and "funding stream" in this document are to be interpreted
as described in ZIP 207 [#zip-0207]_.
Abstract
========

28
zip-0214.html
View File

@ -18,10 +18,10 @@ Discussions-To: &lt;<a href="https://forum.zcashcommunity.com/t/community-sentim
<p>The key words "MUST", "SHALL", "SHOULD", 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 term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (<a id="id2" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id3" class="footnote_reference" href="#zip-0200">8</a> and the Zcash Trademark Donation and License Agreement (<a id="id4" class="footnote_reference" href="#trademark">6</a> or successor agreement).</p>
<p>The term "block subsidy" in this document is to be interpreted as described in section 3.9 of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-subsidyconcepts">4</a>.</p>
<p>The term "halving" in this document are to be interpreted as described in sections 7.7 of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-subsidies">5</a>.</p>
<p>The term "block subsidy" in this document is to be interpreted as described in section 3.10 of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-subsidyconcepts">3</a>.</p>
<p>The term "halving" in this document are to be interpreted as described in sections 7.8 of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-subsidies">5</a>.</p>
<p>The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 <a id="id7" class="footnote_reference" href="#zip-1014">12</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="id8" class="footnote_reference" href="#protocol-networks">3</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="id8" class="footnote_reference" href="#protocol-networks">4</a>.</p>
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -279,23 +279,23 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-subsidyconcepts" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#subsidyconcepts">Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -303,7 +303,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51</
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#subsidies">Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward</a></td>
<td><a href="protocol/protocol.pdf#subsidies">Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward</a></td>
</tr>
</tbody>
</table>

14
zip-0214.rst
View File

@ -25,10 +25,10 @@ described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License
Agreement ([#trademark]_ or successor agreement).
The term "block subsidy" in this document is to be interpreted as described in
section 3.9 of the Zcash Protocol Specification [#protocol-subsidyconcepts]_.
section 3.10 of the Zcash Protocol Specification [#protocol-subsidyconcepts]_.
The term "halving" in this document are to be interpreted as described in
sections 7.7 of the Zcash Protocol Specification [#protocol-subsidies]_.
sections 7.8 of the Zcash Protocol Specification [#protocol-subsidies]_.
The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"),
"Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and
@ -36,7 +36,7 @@ The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"),
[#zip-1014]_.
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
"Canopy" is the code-name for the fifth Zcash network upgrade, also known as
Network Upgrade 4.
@ -337,10 +337,10 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidyconcepts>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidies>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward <protocol/protocol.pdf#subsidyconcepts>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward <protocol/protocol.pdf#subsidies>`_
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf>`_
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_

4
zip-0215.html
View File

@ -108,7 +108,7 @@ License: BSD-2-Clause</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
@ -116,7 +116,7 @@ License: BSD-2-Clause</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#concreteed25519">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.5: Ed25519</a></td>
<td><a href="protocol/protocol.pdf#concreteed25519">Zcash Protocol Specification, Version 2021.2.16. Section 5.4.6: Ed25519</a></td>
</tr>
</tbody>
</table>

4
zip-0215.rst
View File

@ -114,6 +114,6 @@ References
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC8032] `RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA) <https://www.rfc-editor.org/rfc/rfc8032.html>`_
.. [#protocol-2020.1.1] `Zcash Protocol Specification, Version 2020.1.1 <https://github.com/zcash/zips/blob/v2020.1.1/protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-concreteed25519] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.5: Ed25519 <protocol/protocol.pdf#concreteed25519>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-concreteed25519] `Zcash Protocol Specification, Version 2021.2.16. Section 5.4.6: Ed25519 <protocol/protocol.pdf#concreteed25519>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_

24
zip-0216.html
View File

@ -92,7 +92,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
RedDSA signature.</li>
</ul>
</blockquote>
<p>In transactions <a id="id7" class="footnote_reference" href="#protocol-txnencodingandconsensus">10</a>:</p>
<p>In transactions <a id="id7" class="footnote_reference" href="#protocol-txnencoding">10</a>:</p>
<blockquote>
<ul>
<li>the
@ -116,7 +116,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
</blockquote>
<p>(This affects decryption of
<span class="math">\(\mathsf{C^{out}}\)</span>
in all cases, but is consensus-critical only in the case of a shielded coinbase output. <a id="id9" class="footnote_reference" href="#protocol-txnencodingandconsensus">10</a>)</p>
in all cases, but is consensus-critical only in the case of a shielded coinbase output. <a id="id9" class="footnote_reference" href="#protocol-txnencoding">10</a>)</p>
<p>There are some additional fields in the consensus protocol that encode Jubjub points, but where non-canonical encodings MUST already be rejected as a side-effect of existing consensus rules.</p>
<p>In Sapling Spend descriptions:</p>
<blockquote>
@ -218,7 +218,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]</a></td>
</tr>
</tbody>
</table>
@ -226,7 +226,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/nu5.pdf#spenddesc">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.4: Spend Descriptions</a></td>
<td><a href="protocol/protocol.pdf#spenddesc">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions</a></td>
</tr>
</tbody>
</table>
@ -234,7 +234,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/nu5.pdf#outputdesc">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.5: Output Descriptions</a></td>
<td><a href="protocol/protocol.pdf#outputdesc">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions</a></td>
</tr>
</tbody>
</table>
@ -242,7 +242,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/nu5.pdf#decryptovk">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard)</a></td>
<td><a href="protocol/protocol.pdf#decryptovk">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
@ -250,7 +250,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/nu5.pdf#jubjub">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.9.3: Jubjub</a></td>
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub</a></td>
</tr>
</tbody>
</table>
@ -258,7 +258,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/nu5.pdf#pallasandvesta">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta</a></td>
<td><a href="protocol/protocol.pdf#pallasandvesta">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta</a></td>
</tr>
</tbody>
</table>
@ -266,7 +266,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/nu5.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses</a></td>
<td><a href="protocol/protocol.pdf#saplingpaymentaddrencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses</a></td>
</tr>
</tbody>
</table>
@ -274,15 +274,15 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/400">https://g
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/nu5.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys</a></td>
<td><a href="protocol/protocol.pdf#saplingfullviewingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/nu5.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>

22
zip-0216.rst
View File

@ -101,7 +101,7 @@ In Sapling Spend descriptions [#protocol-spenddesc]_:
- the :math:`\underline{R}` component (i.e. the first :math:`32` bytes) of the
:math:`\mathtt{spendAuthSig}` RedDSA signature.
In transactions [#protocol-txnencodingandconsensus]_:
In transactions [#protocol-txnencoding]_:
- the :math:`\underline{R}` component (i.e. the first :math:`32` bytes) of the
:math:`\mathtt{bindingSigSapling}` RedDSA signature.
@ -113,7 +113,7 @@ Sapling transmitted note ciphertext [#protocol-decryptovk]_:
(This affects decryption of :math:`\mathsf{C^{out}}` in all cases, but is
consensus-critical only in the case of a shielded coinbase output.
[#protocol-txnencodingandconsensus]_)
[#protocol-txnencoding]_)
There are some additional fields in the consensus protocol that encode Jubjub points,
but where non-canonical encodings MUST already be rejected as a side-effect of
@ -215,15 +215,15 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal] <protocol/nu5.pdf>`_
.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.4: Spend Descriptions <protocol/nu5.pdf#spenddesc>`_
.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.5: Output Descriptions <protocol/nu5.pdf#outputdesc>`_
.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) <protocol/nu5.pdf#decryptovk>`_
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.9.3: Jubjub <protocol/nu5.pdf#jubjub>`_
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta <protocol/nu5.pdf#pallasandvesta>`_
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses <protocol/nu5.pdf#saplingpaymentaddrencoding>`_
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys <protocol/nu5.pdf#saplingfullviewingkeyencoding>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/nu5.pdf#txnencodingandconsensus>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] <protocol/protocol.pdf>`_
.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions <protocol/protocol.pdf#spenddesc>`_
.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions <protocol/protocol.pdf#outputdesc>`_
.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) <protocol/protocol.pdf#decryptovk>`_
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub <protocol/protocol.pdf#jubjub>`_
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta <protocol/protocol.pdf#pallasandvesta>`_
.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses <protocol/protocol.pdf#saplingpaymentaddrencoding>`_
.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys <protocol/protocol.pdf#saplingfullviewingkeyencoding>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
.. [#zip-0032-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets. Sapling extended full viewing keys <zip-0032.rst#sapling-extended-full-viewing-keys>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0215] `ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules <zip-0215.rst>`_

5
zip-0221.html
View File

@ -657,7 +657,6 @@ License: MIT</pre>
<li><a href="https://github.com/mimblewimble/grin/blob/master/doc/mmr.md">Mimblewimble MMR docs</a></li>
<li><a href="https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py">MMR Python implementation</a></li>
<li><a href="https://docs.rs/merklemountainrange/0.0.1/src/merklemountainrange/lib.rs.html">Tari MMR documentation</a></li>
<li><a href="https://zips.z.cash/protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1 [Overwinter+Sapling+Blossom] or later</a></li>
<li><a href="https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md">opentimestamps-server Merkle Mountain Range documentation</a></li>
</ul>
</section>
@ -682,7 +681,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#workdef">Zcash Protocol Specification, Version 2020.1.24. Section 7.6.5: Definition of Work</a></td>
<td><a href="protocol.pdf#workdef">Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work</a></td>
</tr>
</tbody>
</table>
@ -690,7 +689,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#blockheader">Zcash Protocol Specification, Version 2020.1.24. Section 7.5: Block Header</a></td>
<td><a href="protocol.pdf#blockheader">Zcash Protocol Specification, Version 2021.2.16. Section 7.6: Block Header Encoding and Consensus</a></td>
</tr>
</tbody>
</table>

6
zip-0221.rst
View File

@ -11,6 +11,7 @@
Created: 2019-03-30
License: MIT
Terminology
===========
@ -820,7 +821,6 @@ Additional Reading
- `Mimblewimble MMR docs <https://github.com/mimblewimble/grin/blob/master/doc/mmr.md>`_
- `MMR Python implementation <https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py>`_
- `Tari MMR documentation <https://docs.rs/merklemountainrange/0.0.1/src/merklemountainrange/lib.rs.html>`_
- `Zcash Protocol Specification, Version 2020.1.1 [Overwinter+Sapling+Blossom] or later <https://zips.z.cash/protocol/protocol.pdf>`_
- `opentimestamps-server Merkle Mountain Range documentation <https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md>`_
@ -829,8 +829,8 @@ References
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#FlyClient] `FlyClient protocol <https://eprint.iacr.org/2019/226.pdf>`_
.. [#protocol-workdef] `Zcash Protocol Specification, Version 2020.1.24. Section 7.6.5: Definition of Work <https://zips.z.cash/protocol/protocol.pdf#workdef>`_
.. [#protocol-blockheader] `Zcash Protocol Specification, Version 2020.1.24. Section 7.5: Block Header <https://zips.z.cash/protocol/protocol.pdf#blockheader>`_
.. [#protocol-workdef] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work <protocol.pdf#workdef>`_
.. [#protocol-blockheader] `Zcash Protocol Specification, Version 2021.2.16. Section 7.6: Block Header Encoding and Consensus <protocol.pdf#blockheader>`_
.. [#zcashBlock] `Zcash block primitive <https://github.com/zcash/zcash/blob/master/src/primitives/block.h>`_
.. [#mimblewimble] `MimbleWimble Grin MMR implementation <https://github.com/mimblewimble/grin/blob/aedac483f5a116b91a8baf6acffd70e5f980b8cc/core/src/core/pmmr/pmmr.rs>`_
.. [#bip-0034] `BIP 34: Block v2, Height in Coinbase <https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki>`_

86
zip-0222.html
View File

@ -19,16 +19,16 @@ Created: 2019-07-01
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" 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 term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">2</a>.</p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">6</a>.</p>
<p>The term "prefix-free" in this document is to be interpreted as to mean that no valid encoding of a value may have the same binary representation as any prefix of the binary encoding of another value of the same type.</p>
<p>The term "non-malleable" in this document is to be interpreted as described in ZIP 244 <a id="id3" class="footnote_reference" href="#zip-0244">3</a>.</p>
<p>The value <code>MAX_MONEY</code> is as defined in section <em>5.3 'Constants'</em> of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol">8</a>.</p>
<p>The term "non-malleable" in this document is to be interpreted as described in ZIP 244 <a id="id3" class="footnote_reference" href="#zip-0244">7</a>.</p>
<p>The value <code>MAX_MONEY</code> is as defined in section 5.3 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-constants">3</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a modification to the consensus rules that enables complex forms of transparent output preconditions to be deployed in network upgrades. This in turn enables the creation of "transparent Zcash extensions" that augment the network's functionality in a carefully-defined and auditable fashion.</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>Zcash supports a limited set of preconditions that may be imposed upon how funds, both transparent and shielded, may be spent. Spending limitations on transparent funds are defined by what may be encoded in Bitcoin script, and spending of shielded funds is even more restricted. As such, some use cases (for example, integration of BOLT support <a id="id5" class="footnote_reference" href="#zip-draft-bolt">5</a>) are not yet supportable.</p>
<p>Zcash supports a limited set of preconditions that may be imposed upon how funds, both transparent and shielded, may be spent. Spending limitations on transparent funds are defined by what may be encoded in Bitcoin script, and spending of shielded funds is even more restricted. As such, some use cases (for example, integration of BOLT support <a id="id5" class="footnote_reference" href="#zip-draft-bolt">9</a>) are not yet supportable.</p>
<p>Transparent Zcash Extensions are intended to make it possible to incrementally add new functionality without modifying interpretation of the existing Bitcoin script, which is complex and potentially error-prone. Extensions may also serve as laboratories for evaluating demand for functionality which may eventually be candidates for inclusion in the consensus rules for shielded transactions.</p>
</section>
<section id="definitions"><h2><span class="section-heading">Definitions</span><span class="section-anchor"> <a rel="bookmark" href="#definitions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -249,7 +249,7 @@ License: MIT</pre>
<li>Non-coinbase transactions MUST have at least one of the following: - nonempty transparent inputs - nonempty shielded inputs - nonempty <code>tze_inputs</code></li>
</ul>
<p>The above rule replaces <code>[Sapling onward] At least one of tx_in_count,
nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="footnote_reference" href="#protocol-consensus">9</a>.</p>
nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="footnote_reference" href="#protocol-txnconsensus">4</a>.</p>
<ul>
<li>Transactions MUST have at least one of the following: - nonempty transparent outputs - nonempty shielded outputs - nonempty <code>tze_outputs</code></li>
<li>All <code>amount</code> field values of <code>tze_output</code> records MUST be nonnegative and not greater than <code>MAX_MONEY</code>.</li>
@ -257,8 +257,8 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
</ul>
</section>
<section id="changes-to-signatures-over-transaction-digests"><h3><span class="section-heading">Changes to signatures over transaction digests</span><span class="section-anchor"> <a rel="bookmark" href="#changes-to-signatures-over-transaction-digests"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>This ZIP MUST be deployed in conjunction with or after ZIP 244 <a id="id7" class="footnote_reference" href="#zip-0244">3</a>, which defines new non-malleable transaction identifier and signature digest algorithms.</p>
<p>The newly added parts of the transaction, excluding witness information (i.e. not the <code>witness</code> fields of TZE Input Encodings), will be included in transaction digests for transaction identifiers and signatures. See ZIP 245 <a id="id8" class="footnote_reference" href="#zip-0245">4</a> for the specification of these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well.</p>
<p>This ZIP MUST be deployed in conjunction with or after ZIP 244 <a id="id7" class="footnote_reference" href="#zip-0244">7</a>, which defines new non-malleable transaction identifier and signature digest algorithms.</p>
<p>The newly added parts of the transaction, excluding witness information (i.e. not the <code>witness</code> fields of TZE Input Encodings), will be included in transaction digests for transaction identifiers and signatures. See ZIP 245 <a id="id8" class="footnote_reference" href="#zip-0245">8</a> for the specification of these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well.</p>
</section>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -294,10 +294,42 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-constants" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#constants">Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnconsensus" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#txnconsensus">Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Consensus Rules</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
@ -305,7 +337,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<table id="zip-0244" class="footnote">
<tbody>
<tr>
<th>3</th>
<th>7</th>
<td><a href="zip-0244">ZIP 244: Transaction Non-Malleability Support</a></td>
</tr>
</tbody>
@ -313,48 +345,16 @@ nShieldedSpend, and nJoinSplit MUST be nonzero</code> in <a id="id6" class="foot
<table id="zip-0245" class="footnote">
<tbody>
<tr>
<th>4</th>
<th>8</th>
<td><a href="zip-0245">ZIP 245: Transaction Identifier Digests &amp; Signature Validation for Transparent Zcash Extensions</a></td>
</tr>
</tbody>
</table>
<table id="zip-draft-bolt" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="https://github.com/zcash/zips/pull/216">Draft ZIP: Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol</a></td>
</tr>
</tbody>
</table>
<table id="spec-notation" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/protocol.pdf">Section 2: Notation. Zcash Protocol Specification, Version 2019.0.2 [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0032">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
</tr>
</tbody>
</table>
<table id="protocol-consensus" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/protocol.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus</a></td>
<td><a href="https://github.com/zcash/zips/pull/216">Draft ZIP: Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol</a></td>
</tr>
</tbody>
</table>

19
zip-0222.rst
View File

@ -29,8 +29,9 @@ the binary encoding of another value of the same type.
The term "non-malleable" in this document is to be interpreted as described in ZIP 244
[#zip-0244]_.
The value ``MAX_MONEY`` is as defined in section *5.3 'Constants'* of the Zcash Protocol
Specification [#protocol]_.
The value ``MAX_MONEY`` is as defined in section 5.3 of the Zcash Protocol Specification
[#protocol-constants]_.
Abstract
========
@ -40,6 +41,7 @@ transparent output preconditions to be deployed in network upgrades. This in tur
creation of "transparent Zcash extensions" that augment the network's functionality in a
carefully-defined and auditable fashion.
Motivation
==========
@ -55,6 +57,7 @@ script, which is complex and potentially error-prone. Extensions may also serve
as laboratories for evaluating demand for functionality which may eventually be
candidates for inclusion in the consensus rules for shielded transactions.
Definitions
===========
@ -69,6 +72,7 @@ precondition
witness
Evidence to be evaluated against the challenge encoded by a precondition.
Specification
=============
@ -225,7 +229,7 @@ Once this ZIP becomes active, the following new consensus rules are enforced:
- nonempty ``tze_inputs``
The above rule replaces ``[Sapling onward] At least one of tx_in_count,
nShieldedSpend, and nJoinSplit MUST be nonzero`` in [#protocol_consensus]_.
nShieldedSpend, and nJoinSplit MUST be nonzero`` in [#protocol-txnconsensus]_.
- Transactions MUST have at least one of the following:
- nonempty transparent outputs
@ -252,6 +256,7 @@ transaction identifiers and signatures. See ZIP 245 [#zip-0245]_ for the specif
these new digests. If the changes in this ZIP are deployed, those described in ZIP 245
MUST be deployed as well.
Rationale
=========
@ -317,13 +322,13 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
.. [#protocol-txnconsensus] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Consensus Rules <protocol/protocol.pdf#txnconsensus>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0244] `ZIP 244: Transaction Non-Malleability Support <zip-0244.rst>`_
.. [#zip-0245] `ZIP 245: Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions <zip-0245.rst>`_
.. [#zip-draft-bolt] `Draft ZIP: Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol <https://github.com/zcash/zips/pull/216>`_
.. [#spec-notation] `Section 2: Notation. Zcash Protocol Specification, Version 2019.0.2 [Overwinter+Sapling] <protocol/protocol.pdf>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol_consensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencodingandconsensus>`_
.. [#librustzcash_zip222] `Rust language reference implementation of TZE API <https://github.com/zcash/librustzcash/pull/286>`_
.. [#zcashd_zip222] `zcashd reference implementation of consensus rule changes <https://github.com/zcash/zcash/pull/4480>`_

163
zip-0224.html
View File

@ -21,7 +21,7 @@ License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://github.com/zcash/zips/issues/435</a>&gt;</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 word "MUST" in this document is 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">6</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="id2" class="footnote_reference" href="#protocol-networks">5</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This document proposes the Orchard shielded protocol, which defines a new shielded pool with spending keys and payment addresses that are amenable to future scalability improvements.</p>
@ -29,18 +29,18 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<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>Zcash currently has two active shielded protocols and associated shielded pools:</p>
<ul>
<li>The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes <a id="id3" class="footnote_reference" href="#zerocash-differences">2</a>), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.</li>
<li>The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes <a id="id3" class="footnote_reference" href="#protocol-differences">21</a>), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.</li>
<li>The Sapling shielded protocol, which consisted of numerous improvements to functionality and improved performance by orders of magnitude, and as of Feburary 2021 is the "active" shielded pool.</li>
</ul>
<p>Both of these shielded protocols suffer from two issues:</p>
<ul>
<li>Neither Sprout nor Sapling are compatible with known efficient scalability techniques. Recursive zero-knowledge proofs (where a proof verifies an earlier instance of itself along with new state) that are suitable for deployment in a block chain like Zcash require a cycle of elliptic curves. The Sprout protocol does not use elliptic curves and thus is an inherently inefficient protocol to implement inside a circuit, while the Sapling protocol uses curves for which there is no known way to construct an efficient curve cycle (or path to one).</li>
<li>The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later <a id="id4" class="footnote_reference" href="#zcash-paramgen">3</a>), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, <a id="id5" class="footnote_reference" href="#bctv14-vuln">4</a> which needed to be resolved by changing the proving system and running a new MPC.</li>
<li>The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later <a id="id4" class="footnote_reference" href="#zcash-paramgen">2</a>), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, <a id="id5" class="footnote_reference" href="#bctv14-vuln">3</a> which needed to be resolved by changing the proving system and running a new MPC.</li>
</ul>
<p>We are thus motivated to deploy a new shielded protocol designed around a curve cycle, using a proving system that is both amenable to recursion and does not require an SRS.</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 Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-orchard">5</a>.</p>
<p>The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-orchard">4</a>.</p>
<p>Given that the Orchard protocol largely follows the design of the Sapling protocol, we provide here a list of differences, with references to their normative specifications and associated design rationale.</p>
<section id="curves"><h3><span class="section-heading">Curves</span><span class="section-anchor"> <a rel="bookmark" href="#curves"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The Orchard protocol uses the Pallas / Vesta curve cycle, in place of BLS12-381 and its embedded curve Jubjub:</p>
@ -53,43 +53,38 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
, instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft <a id="id7" class="footnote_reference" href="#ietf-hash-to-curve">33</a> (but the protocol specification takes precedence in the case of any discrepancy).</p>
<p>The presence of the curve cycle is an explicit design choice. This proposal only uses half of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be leveraged by future protocol updates.</p>
<ul>
<li>Curve specifications: <a id="id8" class="footnote_reference" href="#protocol-pallasandvesta">16</a></li>
<li>Curve specifications: <a id="id8" class="footnote_reference" href="#protocol-pallasandvesta">15</a></li>
<li>
<span class="math">\(\mathsf{GroupHash}\)</span>
: <a id="id9" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">17</a></li>
: <a id="id9" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">16</a></li>
<li>Supporting evidence: <a id="id10" class="footnote_reference" href="#pasta-evidence">34</a></li>
</ul>
</section>
<section id="proving-system"><h3><span class="section-heading">Proving system</span><span class="section-anchor"> <a rel="bookmark" href="#proving-system"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), instead of Groth16 and R1CS.</p>
<p>Orchard uses the Halo 2 proving system <a id="id11" class="footnote_reference" href="#halo2-proving-system">23</a> with the PLONKish arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS.</p>
<p>This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates.</p>
<ul>
<li>Halo 2 protocol description: TODO</li>
<li>UltraPLONK Arithmetization: <a id="id11" class="footnote_reference" href="#concepts-upa">22</a></li>
<li>Halo 2 explanation and design rationale: <a id="id12" class="footnote_reference" href="#design-halo2">23</a></li>
</ul>
</section>
<section id="circuit"><h3><span class="section-heading">Circuit</span><span class="section-anchor"> <a rel="bookmark" href="#circuit"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard uses a single circuit for both spends and outputs, similar to Sprout. An "action" contains both a single (possibly dummy) note being spent, and a single (possibly dummy) note being created.</p>
<p>An Orchard transaction contains a "bundle" of actions, and a single Halo 2 proof that covers all of the actions in the bundle.</p>
<ul>
<li>Action description: <a id="id13" class="footnote_reference" href="#protocol-actions">9</a></li>
<li>Circuit statement: <a id="id14" class="footnote_reference" href="#protocol-actionstatement">10</a></li>
<li>Design rationale: <a id="id15" class="footnote_reference" href="#design-actions">25</a></li>
<li>Action description: <a id="id12" class="footnote_reference" href="#protocol-actions">8</a></li>
<li>Circuit statement: <a id="id13" class="footnote_reference" href="#protocol-actionstatement">9</a></li>
<li>Design rationale: <a id="id14" class="footnote_reference" href="#orchard-actions">25</a></li>
</ul>
</section>
<section id="commitments"><h3><span class="section-heading">Commitments</span><span class="section-anchor"> <a rel="bookmark" href="#commitments"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic commitments, Orchard uses the UPA-efficient Sinsemilla in place of Bowe–Hopwood Pedersen hashes.</p>
<p>The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic commitments, Orchard uses the PLONKish-efficient Sinsemilla in place of Bowe–Hopwood Pedersen hashes.</p>
<ul>
<li>Sinsemilla hash function: <a id="id16" class="footnote_reference" href="#protocol-concretesinsemillahash">12</a></li>
<li>Sinsemilla commitments: <a id="id17" class="footnote_reference" href="#protocol-concretesinsemillacommit">15</a></li>
<li>Design rationale: <a id="id18" class="footnote_reference" href="#design-commitments">26</a></li>
<li>Sinsemilla hash function: <a id="id15" class="footnote_reference" href="#protocol-concretesinsemillahash">11</a></li>
<li>Sinsemilla commitments: <a id="id16" class="footnote_reference" href="#protocol-concretesinsemillacommit">14</a></li>
<li>Design rationale: <a id="id17" class="footnote_reference" href="#orchard-commitments">26</a></li>
</ul>
</section>
<section id="commitment-tree"><h3><span class="section-heading">Commitment tree</span><span class="section-anchor"> <a rel="bookmark" href="#commitment-tree"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard uses an identical commitment tree structure to Sapling, except that we instantiate it with Sinsemilla instead of a Bowe–Hopwood Pedersen hash.</p>
<ul>
<li>Design rationale and considered alternatives: <a id="id19" class="footnote_reference" href="#design-tree">27</a></li>
<li>Design rationale and considered alternatives: <a id="id18" class="footnote_reference" href="#orchard-tree">27</a></li>
</ul>
</section>
<section id="keys-and-addresses"><h3><span class="section-heading">Keys and addresses</span><span class="section-anchor"> <a rel="bookmark" href="#keys-and-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -110,14 +105,14 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
, instead of being a component of the spending key.</li>
<li>All diversifiers now result in valid payment addresses.</li>
</ul>
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="id20" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="id21" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a>.</p>
<p>There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in <a id="id19" class="footnote_reference" href="#zip-0316">32</a>. Orchard spending keys are encoded using Bech32m as specified in <a id="id20" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a>.</p>
<p>Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only derivation mechanism (similar to Sprout).</p>
<ul>
<li>Key components diagram: <a id="id22" class="footnote_reference" href="#protocol-addressesandkeys">7</a></li>
<li>Key components specification: <a id="id23" class="footnote_reference" href="#protocol-orchardkeycomponents">11</a></li>
<li>Encodings and HRPs: <a id="id24" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">18</a> <a id="id25" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">19</a> <a id="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">20</a> <a id="id27" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">21</a></li>
<li>HD key derivation specification: <a id="id28" class="footnote_reference" href="#zip-0032">29</a></li>
<li>Design rationale: <a id="id29" class="footnote_reference" href="#design-keys">24</a></li>
<li>Key components diagram: <a id="id21" class="footnote_reference" href="#protocol-addressesandkeys">6</a></li>
<li>Key components specification: <a id="id22" class="footnote_reference" href="#protocol-orchardkeycomponents">10</a></li>
<li>Encodings: <a id="id23" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">17</a> <a id="id24" class="footnote_reference" href="#protocol-orchardinviewingkeyencoding">18</a> <a id="id25" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">19</a> <a id="id26" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">20</a></li>
<li>HD key derivation specification: <a id="id27" class="footnote_reference" href="#zip-0032">29</a></li>
<li>Design rationale: <a id="id28" class="footnote_reference" href="#orchard-keys">24</a></li>
</ul>
</section>
<section id="notes"><h3><span class="section-heading">Notes</span><span class="section-anchor"> <a rel="bookmark" href="#notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -128,9 +123,9 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<span class="math">\(\psi\)</span>
and
<span class="math">\(\mathsf{rcm}\)</span>
are derived from a random seed (as with Sapling after ZIP 212 <a id="id30" class="footnote_reference" href="#zip-0212">30</a>).</p>
are derived from a random seed (as with Sapling after ZIP 212 <a id="id29" class="footnote_reference" href="#zip-0212">30</a>).</p>
<ul>
<li>Orchard notes: <a id="id31" class="footnote_reference" href="#protocol-notes">8</a></li>
<li>Orchard notes: <a id="id30" class="footnote_reference" href="#protocol-notes">7</a></li>
</ul>
</section>
<section id="nullifiers"><h3><span class="section-heading">Nullifiers</span><span class="section-anchor"> <a rel="bookmark" href="#nullifiers"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -144,14 +139,14 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<span class="math">\(\mathcal{G}\)</span>
is a fixed independent base.</p>
<ul>
<li>Poseidon: <a id="id32" class="footnote_reference" href="#protocol-poseidonhash">13</a></li>
<li>Design rationale and considered alternatives: <a id="id33" class="footnote_reference" href="#design-nullifiers">28</a></li>
<li>Poseidon: <a id="id31" class="footnote_reference" href="#protocol-poseidonhash">12</a></li>
<li>Design rationale and considered alternatives: <a id="id32" class="footnote_reference" href="#orchard-nullifiers">28</a></li>
</ul>
</section>
<section id="signatures"><h3><span class="section-heading">Signatures</span><span class="section-anchor"> <a rel="bookmark" href="#signatures"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Orchard uses RedPallas (RedDSA instantiated with the Pallas curve) as its signature scheme in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).</p>
<ul>
<li>RedPallas: <a id="id34" class="footnote_reference" href="#protocol-concretereddsa">14</a></li>
<li>RedPallas: <a id="id33" class="footnote_reference" href="#protocol-concretereddsa">13</a></li>
</ul>
</section>
</section>
@ -171,7 +166,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
field, combined with the consensus checks that each pool's balance cannot be negative, together enforce that any potential counterfeiting bugs in the Orchard protocol or implementation are contained within the Orchard pool, and similarly any potential counterfeiting bugs in existing shielded pools cannot cause inflation of the Orchard pool.</li>
<li>Spending funds residing in the Orchard pool to a non-Orchard address will reveal the value of the transaction. This is a necessary side-effect of the transparent turnstile, but can be mitigated by migrating the majority of shielded activity to the Orchard pool and making these transactions a minority. Wallets should convey within their transaction creation UX that amounts are revealed in these situations.
<ul>
<li>Wallets should take steps to migrate their user bases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="id35" class="footnote_reference" href="#zip-0315">31</a></li>
<li>Wallets should take steps to migrate their user bases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="id34" class="footnote_reference" href="#zip-0315">31</a></li>
</ul>
</li>
</ul>
@ -199,18 +194,10 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</tr>
</tbody>
</table>
<table id="zerocash-differences" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://zips.z.cash/protocol/protocol.pdf#differences">Zcash Protocol Specification, Version 2021.1.16. Section 8: Differences from the Zerocash paper</a></td>
</tr>
</tbody>
</table>
<table id="zcash-paramgen" class="footnote">
<tbody>
<tr>
<th>3</th>
<th>2</th>
<td><a href="https://z.cash/technology/paramgen/">Parameter Generation</a></td>
</tr>
</tbody>
@ -218,7 +205,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="bctv14-vuln" class="footnote">
<tbody>
<tr>
<th>4</th>
<th>3</th>
<td><a href="https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/">Zcash Counterfeiting Vulnerability Successfully Remediated</a></td>
</tr>
</tbody>
@ -226,148 +213,156 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="protocol-orchard" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal]</a></td>
<th>4</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/nu5.pdf#networks">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet</a></td>
<th>5</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-addressesandkeys" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/nu5.pdf#addressesandkeys">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.1: Payment Addresses and Keys</a></td>
<th>6</th>
<td><a href="protocol/protocol.pdf#addressesandkeys">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys</a></td>
</tr>
</tbody>
</table>
<table id="protocol-notes" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/nu5.pdf#notes">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.2: Notes</a></td>
<th>7</th>
<td><a href="protocol/protocol.pdf#notes">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes</a></td>
</tr>
</tbody>
</table>
<table id="protocol-actions" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="protocol/nu5.pdf#actions">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions</a></td>
<th>8</th>
<td><a href="protocol/protocol.pdf#actions">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions</a></td>
</tr>
</tbody>
</table>
<table id="protocol-actionstatement" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/nu5.pdf#actionstatement">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)</a></td>
<th>9</th>
<td><a href="protocol/protocol.pdf#actionstatement">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardkeycomponents" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/nu5.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.2.3: Orchard Key Components</a></td>
<th>10</th>
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.3: Orchard Key Components</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretesinsemillahash" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/nu5.pdf#concretesinsemillahash">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function</a></td>
<th>11</th>
<td><a href="protocol/protocol.pdf#concretesinsemillahash">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function</a></td>
</tr>
</tbody>
</table>
<table id="protocol-poseidonhash" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/nu5.pdf#poseidonhash">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function</a></td>
<th>12</th>
<td><a href="protocol/protocol.pdf#poseidonhash">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretereddsa" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/nu5.pdf#concretereddsa">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas</a></td>
<th>13</th>
<td><a href="protocol/protocol.pdf#concretereddsa">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretesinsemillacommit" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="protocol/nu5.pdf#concretesinsemillacommit">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.7.4: Sinsemilla commitments</a></td>
<th>14</th>
<td><a href="protocol/protocol.pdf#concretesinsemillacommit">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments</a></td>
</tr>
</tbody>
</table>
<table id="protocol-pallasandvesta" class="footnote">
<tbody>
<tr>
<th>16</th>
<td><a href="protocol/nu5.pdf#pallasandvesta">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.8.6: Pallas and Vesta</a></td>
<th>15</th>
<td><a href="protocol/protocol.pdf#pallasandvesta">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretegrouphashpallasandvesta" class="footnote">
<tbody>
<tr>
<th>17</th>
<td><a href="protocol/nu5.pdf#concretegrouphashpallasandvesta">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta</a></td>
<th>16</th>
<td><a href="protocol/protocol.pdf#concretegrouphashpallasandvesta">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardpaymentaddrencoding" class="footnote">
<tbody>
<tr>
<th>18</th>
<td><a href="protocol/nu5.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.4.1: Orchard Payment Address</a></td>
<th>17</th>
<td><a href="protocol/protocol.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardinviewingkeyencoding" class="footnote">
<tbody>
<tr>
<th>19</th>
<td><a href="protocol/nu5.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys</a></td>
<th>18</th>
<td><a href="protocol/protocol.pdf#orchardinviewingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardfullviewingkeyencoding" class="footnote">
<tbody>
<tr>
<th>20</th>
<td><a href="protocol/nu5.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.3: Orchard Full Viewing Keys</a></td>
<th>19</th>
<td><a href="protocol/protocol.pdf#orchardfullviewingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardspendingkeyencoding" class="footnote">
<tbody>
<tr>
<th>21</th>
<td><a href="protocol/nu5.pdf#orchardspendingkeyencoding">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.4: Orchard Spending Keys</a></td>
<th>20</th>
<td><a href="protocol/protocol.pdf#orchardspendingkeyencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys</a></td>
</tr>
</tbody>
</table>
<table id="concepts-upa" class="footnote">
<table id="protocol-differences" class="footnote">
<tbody>
<tr>
<th>21</th>
<td><a href="protocol/protocol.pdf#differences">Zcash Protocol Specification, Version 2021.2.16. Section 8: Differences from the Zerocash paper</a></td>
</tr>
</tbody>
</table>
<table id="halo2-arithmetization" class="footnote">
<tbody>
<tr>
<th>22</th>
<td><a href="https://zcash.github.io/halo2/concepts/arithmetization.html">The halo2 Book: 1.2 UltraPLONK Arithmetization</a></td>
<td><a href="https://zcash.github.io/halo2/concepts/arithmetization.html">The halo2 Book: 1.2 PLONKish Arithmetization</a></td>
</tr>
</tbody>
</table>
<table id="design-halo2" class="footnote">
<table id="halo2-proving-system" class="footnote">
<tbody>
<tr>
<th>23</th>
@ -375,7 +370,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</tr>
</tbody>
</table>
<table id="design-keys" class="footnote">
<table id="orchard-keys" class="footnote">
<tbody>
<tr>
<th>24</th>
@ -383,7 +378,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</tr>
</tbody>
</table>
<table id="design-actions" class="footnote">
<table id="orchard-actions" class="footnote">
<tbody>
<tr>
<th>25</th>
@ -391,7 +386,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</tr>
</tbody>
</table>
<table id="design-commitments" class="footnote">
<table id="orchard-commitments" class="footnote">
<tbody>
<tr>
<th>26</th>
@ -399,7 +394,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</tr>
</tbody>
</table>
<table id="design-tree" class="footnote">
<table id="orchard-tree" class="footnote">
<tbody>
<tr>
<th>27</th>
@ -407,7 +402,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</tr>
</tbody>
</table>
<table id="design-nullifiers" class="footnote">
<table id="orchard-nullifiers" class="footnote">
<tbody>
<tr>
<th>28</th>

82
zip-0224.rst
View File

@ -19,8 +19,8 @@ Terminology
The key word "MUST" in this document is 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 "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of
the Zcash Protocol Specification [#protocol-networks]_.
Abstract
@ -37,7 +37,7 @@ Motivation
Zcash currently has two active shielded protocols and associated shielded pools:
- The Sprout shielded protocol (based on the Zerocash paper with improvements and security
fixes [#zerocash-differences]_), which as of February 2021 is a "closing" shielded pool
fixes [#protocol-differences]_), which as of February 2021 is a "closing" shielded pool
into which no new ZEC can be sent.
- The Sapling shielded protocol, which consisted of numerous improvements to functionality
and improved performance by orders of magnitude, and as of Feburary 2021 is the "active"
@ -107,16 +107,12 @@ leveraged by future protocol updates.
Proving system
--------------
Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), instead
of Groth16 and R1CS.
Orchard uses the Halo 2 proving system [#halo2-proving-system]_ with the PLONKish
arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS.
This proposal does not make use of Halo 2's support for recursive proofs, but this is
expected to be leveraged by future protocol updates.
- Halo 2 protocol description: TODO
- UltraPLONK Arithmetization: [#concepts-upa]_
- Halo 2 explanation and design rationale: [#design-halo2]_
Circuit
-------
@ -129,18 +125,18 @@ covers all of the actions in the bundle.
- Action description: [#protocol-actions]_
- Circuit statement: [#protocol-actionstatement]_
- Design rationale: [#design-actions]_
- Design rationale: [#orchard-actions]_
Commitments
-----------
The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic
commitments, Orchard uses the UPA-efficient Sinsemilla in place of Bowe–Hopwood Pedersen
hashes.
commitments, Orchard uses the PLONKish-efficient Sinsemilla in place of Bowe–Hopwood
Pedersen hashes.
- Sinsemilla hash function: [#protocol-concretesinsemillahash]_
- Sinsemilla commitments: [#protocol-concretesinsemillacommit]_
- Design rationale: [#design-commitments]_
- Design rationale: [#orchard-commitments]_
Commitment tree
---------------
@ -148,7 +144,7 @@ Commitment tree
Orchard uses an identical commitment tree structure to Sapling, except that we instantiate
it with Sinsemilla instead of a Bowe–Hopwood Pedersen hash.
- Design rationale and considered alternatives: [#design-tree]_
- Design rationale and considered alternatives: [#orchard-tree]_
Keys and addresses
------------------
@ -175,10 +171,10 @@ derivation mechanism (similar to Sprout).
- Key components diagram: [#protocol-addressesandkeys]_
- Key components specification: [#protocol-orchardkeycomponents]_
- Encodings and HRPs: [#protocol-orchardpaymentaddrencoding]_ [#protocol-orchardinviewingkeyencoding]_ [#protocol-orchardfullviewingkeyencoding]_
[#protocol-orchardspendingkeyencoding]_
- Encodings: [#protocol-orchardpaymentaddrencoding]_ [#protocol-orchardinviewingkeyencoding]_
[#protocol-orchardfullviewingkeyencoding]_ [#protocol-orchardspendingkeyencoding]_
- HD key derivation specification: [#zip-0032]_
- Design rationale: [#design-keys]_
- Design rationale: [#orchard-keys]_
Notes
-----
@ -201,7 +197,7 @@ where :math:`F` is instantiated with Poseidon, and :math:`\mathcal{G}` is a fixe
independent base.
- Poseidon: [#protocol-poseidonhash]_
- Design rationale and considered alternatives: [#design-nullifiers]_
- Design rationale and considered alternatives: [#orchard-nullifiers]_
Signatures
----------
@ -283,33 +279,33 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#zerocash-differences] `Zcash Protocol Specification, Version 2021.1.16. Section 8: Differences from the Zerocash paper <https://zips.z.cash/protocol/protocol.pdf#differences>`_
.. [#zcash-paramgen] `Parameter Generation <https://z.cash/technology/paramgen/>`_
.. [#bctv14-vuln] `Zcash Counterfeiting Vulnerability Successfully Remediated <https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/>`_
.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal] <protocol/nu5.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet <protocol/nu5.pdf#networks>`_
.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.1: Payment Addresses and Keys <protocol/nu5.pdf#addressesandkeys>`_
.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.2: Notes <protocol/nu5.pdf#notes>`_
.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions <protocol/nu5.pdf#actions>`_
.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) <protocol/nu5.pdf#actionstatement>`_
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.2.3: Orchard Key Components <protocol/nu5.pdf#orchardkeycomponents>`_
.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function <protocol/nu5.pdf#concretesinsemillahash>`_
.. [#protocol-poseidonhash] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function <protocol/nu5.pdf#poseidonhash>`_
.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas <protocol/nu5.pdf#concretereddsa>`_
.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.7.4: Sinsemilla commitments <protocol/nu5.pdf#concretesinsemillacommit>`_
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.8.6: Pallas and Vesta <protocol/nu5.pdf#pallasandvesta>`_
.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta <protocol/nu5.pdf#concretegrouphashpallasandvesta>`_
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.4.1: Orchard Payment Address <protocol/nu5.pdf#orchardpaymentaddrencoding>`_
.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys <protocol/nu5.pdf#orchardinviewingkeyencoding>`_
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.3: Orchard Full Viewing Keys <protocol/nu5.pdf#orchardfullviewingkeyencoding>`_
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.4: Orchard Spending Keys <protocol/nu5.pdf#orchardspendingkeyencoding>`_
.. [#concepts-upa] `The halo2 Book: 1.2 UltraPLONK Arithmetization <https://zcash.github.io/halo2/concepts/arithmetization.html>`_
.. [#design-halo2] `The halo2 Book: 3.1. Proving system <https://zcash.github.io/halo2/design/proving-system.html>`_
.. [#design-keys] `The Orchard Book: 3.1. Keys and addresses <https://zcash.github.io/orchard/design/keys.html>`_
.. [#design-actions] `The Orchard Book: 3.2. Actions <https://zcash.github.io/orchard/design/actions.html>`_
.. [#design-commitments] `The Orchard Book: 3.3. Commitments <https://zcash.github.io/orchard/design/commitments.html>`_
.. [#design-tree] `The Orchard Book: 3.4. Commitment tree <https://zcash.github.io/orchard/design/commitment-tree.html>`_
.. [#design-nullifiers] `The Orchard Book: 3.5. Nullifiers <https://zcash.github.io/orchard/design/nullifiers.html>`_
.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys <protocol/protocol.pdf#addressesandkeys>`_
.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes <protocol/protocol.pdf#notes>`_
.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions <protocol/protocol.pdf#actions>`_
.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) <protocol/protocol.pdf#actionstatement>`_
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function <protocol/protocol.pdf#concretesinsemillahash>`_
.. [#protocol-poseidonhash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function <protocol/protocol.pdf#poseidonhash>`_
.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas <protocol/protocol.pdf#concretereddsa>`_
.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments <protocol/protocol.pdf#concretesinsemillacommit>`_
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta <protocol/protocol.pdf#pallasandvesta>`_
.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta <protocol/protocol.pdf#concretegrouphashpallasandvesta>`_
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses <protocol/protocol.pdf#orchardpaymentaddrencoding>`_
.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys <protocol/protocol.pdf#orchardinviewingkeyencoding>`_
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys <protocol/protocol.pdf#orchardfullviewingkeyencoding>`_
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys <protocol/protocol.pdf#orchardspendingkeyencoding>`_
.. [#protocol-differences] `Zcash Protocol Specification, Version 2021.2.16. Section 8: Differences from the Zerocash paper <protocol/protocol.pdf#differences>`_
.. [#halo2-arithmetization] `The halo2 Book: 1.2 PLONKish Arithmetization <https://zcash.github.io/halo2/concepts/arithmetization.html>`_
.. [#halo2-proving-system] `The halo2 Book: 3.1. Proving system <https://zcash.github.io/halo2/design/proving-system.html>`_
.. [#orchard-keys] `The Orchard Book: 3.1. Keys and addresses <https://zcash.github.io/orchard/design/keys.html>`_
.. [#orchard-actions] `The Orchard Book: 3.2. Actions <https://zcash.github.io/orchard/design/actions.html>`_
.. [#orchard-commitments] `The Orchard Book: 3.3. Commitments <https://zcash.github.io/orchard/design/commitments.html>`_
.. [#orchard-tree] `The Orchard Book: 3.4. Commitment tree <https://zcash.github.io/orchard/design/commitment-tree.html>`_
.. [#orchard-nullifiers] `The Orchard Book: 3.5. Nullifiers <https://zcash.github.io/orchard/design/nullifiers.html>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
.. [#zip-0315] `ZIP 315: Best Practices for Wallet Handling of Multiple Pools <zip-0315.rst>`_

14
zip-0225.html
View File

@ -21,10 +21,10 @@ License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://github.com/zcash/zips/issues/440</a>&gt;</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" 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 character § is used when referring to sections of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
<p>The character § is used when referring to sections of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol">2</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol <a id="id3" class="footnote_reference" href="#protocol-nu5">2</a>. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.</p>
<p>This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol <a id="id3" class="footnote_reference" href="#protocol">2</a>. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.</p>
<p>This ZIP also depends upon and defines modifications to the computation of the values <strong>TxId Digest</strong>, <strong>Signature Digest</strong>, and <strong>Authorizing Data Commitment</strong> defined by ZIP 244 <a id="id4" class="footnote_reference" href="#zip-0244">7</a>.</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>
@ -474,11 +474,11 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</tr>
</tbody>
</table>
<table id="protocol-nu5" class="footnote">
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]</a></td>
</tr>
</tbody>
</table>
@ -486,7 +486,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/nu5.pdf#spenddesc">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.4: Spend Descriptions</a></td>
<td><a href="protocol/protocol.pdf#spenddesc">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions</a></td>
</tr>
</tbody>
</table>
@ -494,7 +494,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/nu5.pdf#outputdesc">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.5: Output Descriptions</a></td>
<td><a href="protocol/protocol.pdf#outputdesc">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions</a></td>
</tr>
</tbody>
</table>
@ -502,7 +502,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/nu5.pdf#actiondesc">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.6: Action Descriptions</a></td>
<td><a href="protocol/protocol.pdf#actiondesc">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.6: Action Descriptions</a></td>
</tr>
</tbody>
</table>

15
zip-0225.rst
View File

@ -21,13 +21,14 @@ The key words "MUST" and "MAY" in this document are to be interpreted as describ
RFC 2119. [#RFC2119]_
The character § is used when referring to sections of the Zcash Protocol Specification
[#protocol-nu5]_.
[#protocol]_.
Abstract
========
This proposal defines an update to the Zcash peer-to-peer transaction format to include
support for data elements required to support the Orchard protocol [#protocol-nu5]_.
support for data elements required to support the Orchard protocol [#protocol]_.
The new transaction format defines well-bounded regions of the serialized form to serve
each of the existing pools of funds, and adds and describes a new region containing
Orchard-specific elements.
@ -261,6 +262,7 @@ Orchard Action Description (``OrchardAction``)
The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding
and Consensus’ of the Zcash Protocol Specification [#protocol-actiondesc]_.
Alternatives
============
@ -307,6 +309,7 @@ The original definitions for the transaction fields that have been removed are:
* The ``joinSplitPubKey`` and ``joinSplitSig`` fields were specified to be
present if and only if :math:`\mathtt{nJoinSplit} > 0`.
Reference implementation
========================
@ -317,10 +320,10 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-nu5] `Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal] <protocol/nu5.pdf>`_
.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.4: Spend Descriptions <protocol/nu5.pdf#spenddesc>`_
.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.5: Output Descriptions <protocol/nu5.pdf#outputdesc>`_
.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.6: Action Descriptions <protocol/nu5.pdf#actiondesc>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] <protocol/protocol.pdf>`_
.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions <protocol/protocol.pdf#spenddesc>`_
.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions <protocol/protocol.pdf#outputdesc>`_
.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.6: Action Descriptions <protocol/protocol.pdf#actiondesc>`_
.. [#zip-0222] `ZIP 222: Transparent Zcash Extensions <zip-0222.rst>`_
.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`_
.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_

58
zip-0239.html
View File

@ -18,10 +18,10 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/515">https://g
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://github.com/zcash/zips/pull/516</a>&gt;</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", and "SHOULD" 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 term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">2</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="id3" class="footnote_reference" href="#protocol-networks">6</a>.</p>
<p>The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in <a id="id4" class="footnote_reference" href="#zip-0244">4</a> for v5 and later transactions.</p>
<p>The term "authorizing data commitment" (denoted <code>auth_digest</code>), defined only for v5 and later transactions, is to be interpreted as described in <a id="id5" class="footnote_reference" href="#zip-0244">4</a>.</p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</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="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
<p>The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in <a id="id4" class="footnote_reference" href="#zip-0244">6</a> for v5 and later transactions.</p>
<p>The term "authorizing data commitment" (denoted <code>auth_digest</code>), defined only for v5 and later transactions, is to be interpreted as described in <a id="id5" class="footnote_reference" href="#zip-0244">6</a>.</p>
<p>The term "witnessed transaction identifier" ("wtxid"), defined only for v5 and later transactions, is a 64-byte value given by concatenating the txid and the authorizing data commitment of the transaction.</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -29,22 +29,22 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
</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>Historically, as in Bitcoin, the <code>inv</code> and <code>getdata</code> messages sent on the Zcash peer-to-peer network to announce or request transactions have referred to those transactions by txid.</p>
<p>Prior to the introduction of v5 transactions <a id="id6" class="footnote_reference" href="#zip-0225">3</a> in the NU5 network upgrade <a id="id7" class="footnote_reference" href="#zip-0252">5</a>, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.</p>
<p>For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data <a id="id8" class="footnote_reference" href="#zip-0244">4</a>. Witness data is committed to by a separate "authorizing data commitment". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.</p>
<p>Prior to the introduction of v5 transactions <a id="id6" class="footnote_reference" href="#zip-0225">5</a> in the NU5 network upgrade <a id="id7" class="footnote_reference" href="#zip-0252">7</a>, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.</p>
<p>For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data <a id="id8" class="footnote_reference" href="#zip-0244">6</a>. Witness data is committed to by a separate "authorizing data commitment". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.</p>
<p>Not committing to the witness data in v5 transaction announcements would create inefficiencies: because a v5 transaction's witness can be malleated without altering the txid, a node in receipt of a v5 transaction that the node does not accept would generally still have to download that same transaction when announced by other peers. This is because the alternative — of not downloading a v5 transaction with a given txid after rejecting a previous transaction with that txid — would allow a third party to interfere with transaction relay by malleating a transaction's witness and announcing the resulting invalid transaction to nodes, preventing relay of the valid version of the transaction as well.</p>
<p>This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade <a id="id9" class="footnote_reference" href="#bip-0141">8</a>, until the adoption of BIP 339 <a id="id10" class="footnote_reference" href="#bip-0339">9</a>. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is also called the wtxid, but it encodes the pair (txid, auth_digest).</p>
<p>This ZIP is modelled after BIP 339: it adds a <code>MSG_WTX</code> inv type to the peer-to-peer protocol, analogous to BIP 339's <code>MSG_WTX</code> inv type, that announces transactions by their wtxid. Note that the encoding and length of a Zcash wtxid is different to that of a Bitcoin wtxid.</p>
<p>This ZIP does not introduce any equivalent of BIP 339's <code>wtxidrelay</code> message, since that is not needed for compatibility given that Zcash full nodes are required to support <code>MSG_WTX</code> based on the negotiated peer protocol version (see <a href="#deployment">Deployment</a>).</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>A new inv type <code>MSG_WTX</code> (0x00000005) is added, for use in both <code>inv</code> messages and <code>getdata</code> requests, indicating that the hash being referenced is the wtxid (i.e. the 64-byte value <code>txid</code> || <code>auth_digest</code>). This inv type MUST be used when announcing v5 transactions. The <code>txid</code> and <code>auth_digest</code> are as defined in <a id="id11" class="footnote_reference" href="#zip-0244">4</a>.</p>
<p>In the case of <code>getdata</code> requests, the format of a v5 transaction obtained by a <code>MSG_WTX</code> inv type is as given in the Zcash protocol specification. <a id="id12" class="footnote_reference" href="#protocol-txnencodingandconsensus">7</a></p>
<p>A new inv type <code>MSG_WTX</code> (0x00000005) is added, for use in both <code>inv</code> messages and <code>getdata</code> requests, indicating that the hash being referenced is the wtxid (i.e. the 64-byte value <code>txid</code> || <code>auth_digest</code>). This inv type MUST be used when announcing v5 transactions. The <code>txid</code> and <code>auth_digest</code> are as defined in <a id="id11" class="footnote_reference" href="#zip-0244">6</a>.</p>
<p>In the case of <code>getdata</code> requests, the format of a v5 transaction obtained by a <code>MSG_WTX</code> inv type is as given in the Zcash protocol specification. <a id="id12" class="footnote_reference" href="#protocol-txnencoding">3</a></p>
<p>An <code>inv</code> or <code>getdata</code> message MUST NOT use the <code>MSG_WTX</code> inv type for v4 or earlier transactions, or on peer connections that have not negotiated at least the peer protocol version specified in <a href="#deployment">Deployment</a>.</p>
<p>Note that <code>MSG_WTX</code> might also be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified for now.</p>
<p><code>MSG_TX</code> and <code>MSG_WTX</code> entries may be mixed in arbitrary order in an <code>inv</code> message or a <code>getdata</code> message. Since these entry types are of different lengths (36 bytes or 68 bytes respectively including the 4-byte type field), this implies that the size of the message is not determined by its initial <code>count</code> field, and has to be determined by parsing the whole message.</p>
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5. In <a id="id13" class="footnote_reference" href="#zip-0252">5</a>, the minimum protocol version that signals support for NU5 on Testnet is defined to be 170014. Therefore, the peer protocol version that enables support for this specification is also defined to be 170014 (on both Testnet and Mainnet).</p>
<p>As specified in <a id="id14" class="footnote_reference" href="#zip-0200">2</a>, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the <code>MSG_WTX</code> inv type until it has received the block preceding the NU5 network upgrade.</p>
<p>As specified in <a id="id14" class="footnote_reference" href="#zip-0200">4</a>, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the <code>MSG_WTX</code> inv type until it has received the block preceding the NU5 network upgrade.</p>
<p>Nevertheless, it is possible for a node to receive an <code>inv</code> or <code>getdata</code> message with a <code>MSG_WTX</code> inv type, on a peer connection that has negotiated protocol version 170014 or later, before NU5 has activated. The node MUST handle this case in the same way that it would after NU5 activation when it has no v5 transactions to relay. Receiving a <code>MSG_WTX</code> inv type on a peer connection that has negotiated a protocol version before 170014, on the other hand, SHOULD be treated as a protocol error.</p>
<p>As the <code>MSG_WTX</code> inv type is only enabled between peers that both support it, older clients remain fully compatible and interoperable before NU5 activates, or on a chain in which it does not activate.</p>
</section>
@ -65,10 +65,26 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
@ -76,7 +92,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
<table id="zip-0225" class="footnote">
<tbody>
<tr>
<th>3</th>
<th>5</th>
<td><a href="zip-0225">ZIP 225: Version 5 Transaction Format</a></td>
</tr>
</tbody>
@ -84,32 +100,16 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/516">https://githu
<table id="zip-0244" class="footnote">
<tbody>
<tr>
<th>4</th>
<th>6</th>
<td><a href="zip-0244">ZIP 244: Transaction Identifier Non-Malleability</a></td>
</tr>
</tbody>
</table>
<table id="zip-0252" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="protocol/nu5.pdf#networks">Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 3.12 Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="protocol/nu5.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
<td><a href="zip-0252">ZIP 252: Deployment of the NU5 Network Upgrade</a></td>
</tr>
</tbody>
</table>

8
zip-0239.rst
View File

@ -22,7 +22,7 @@ The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
The term "txid" means a transaction identifier, computed as a SHA-256d hash of
the transaction data for v4 and earlier transactions, or as specified in [#zip-0244]_
@ -98,7 +98,7 @@ when announcing v5 transactions. The ``txid`` and ``auth_digest`` are as defined
In the case of ``getdata`` requests, the format of a v5 transaction obtained by a
``MSG_WTX`` inv type is as given in the Zcash protocol specification.
[#protocol-txnencodingandconsensus]_
[#protocol-txnencoding]_
An ``inv`` or ``getdata`` message MUST NOT use the ``MSG_WTX`` inv type for v4
or earlier transactions, or on peer connections that have not negotiated at least
@ -166,12 +166,12 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0225] `ZIP 225: Version 5 Transaction Format <zip-0225.rst>`_
.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`_
.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade <zip-0252.rst>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 3.12 Mainnet and Testnet <protocol/nu5.pdf#networks>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/nu5.pdf#txnencodingandconsensus>`_
.. [#bip-0141] `BIP 141: Segregated Witness (Consensus layer) <https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki>`_
.. [#bip-0339] `BIP 339: WTXID-based transaction relay <https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki>`_
.. [#p2p-inv] `Bitcoin Developer Reference: P2P Network — Inv <https://developer.bitcoin.org/reference/p2p_networking.html#inv>`_

2
zip-0243.html
View File

@ -455,7 +455,7 @@ vJoinSplit: 00</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>

2
zip-0243.rst
View File

@ -527,7 +527,7 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#BLAKE2-personalization] `"BLAKE2: simpler, smaller, fast as MD5", Section 2.8 <https://blake2.net/blake2.pdf>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_

50
zip-0244.html
View File

@ -18,8 +18,8 @@ License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/411">https://github.com/zcash/zips/issues/411</a>&gt;</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" and "MUST NOT" 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 "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">2</a></p>
<p>The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencodingandconsensus">8</a>.</p>
<p>The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">3</a></p>
<p>The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-txnencoding">2</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines a new transaction digest algorithm for the NU5 network upgrade onward, in order to introduce non-malleable transaction identifiers that commit to all transaction data except for attestations to transaction validity.</p>
@ -83,7 +83,7 @@ T.4: orchard_digest (32-byte hash output)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZcashTxHash_" || CONSENSUS_BRANCH_ID</pre>
<p><code>ZcashTxHash_</code> has 1 underscore character.</p>
<p>As in ZIP 143 <a id="id5" class="footnote_reference" href="#zip-0143">5</a>, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.</p>
<p>As in ZIP 143 <a id="id5" class="footnote_reference" href="#zip-0143">6</a>, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.</p>
<p>This signature hash personalization prefix has been changed to reflect the new role of this hash (relative to <code>ZcashSigHash</code> as specified in ZIP 143) as a transaction identifier rather than a commitment that is exclusively used for signature purposes. The previous computation of the transaction identifier was a SHA256d hash of the serialized transaction contents, and was not personalized.</p>
<section id="t-1-header-digest"><h6><span class="section-heading">T.1: header_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-1-header-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>A BLAKE2b-256 hash of the following values</p>
@ -127,7 +127,7 @@ T.2c: outputs_digest (32-byte hash)</pre>
</section>
</section>
<section id="t-3-sapling-digest"><h6><span class="section-heading">T.3: sapling_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3-sapling-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the <code>CompactBlock</code> representation of Sapling data specified by the ZIP 307 Light Client Protocol <a id="id6" class="footnote_reference" href="#zip-0307">7</a>.</p>
<p>In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the <code>CompactBlock</code> representation of Sapling data specified by the ZIP 307 Light Client Protocol <a id="id6" class="footnote_reference" href="#zip-0307">8</a>.</p>
<p>This digest is a BLAKE2b-256 hash of the following values</p>
<pre>T.3a: sapling_spends_digest (32-byte hash)
T.3b: sapling_outputs_digest (32-byte hash)
@ -169,7 +169,7 @@ T.3b.iii: sapling_outputs_noncompact_digest (32-byte hash)</pre>
<p>In the case that the transaction has Sapling spends but no Sapling outputs, <code>sapling_outputs_digest</code> is</p>
<pre>BLAKE2b-256("ZTxIdSOutputHash", [])</pre>
<section id="t-3b-i-sapling-outputs-compact-digest"><h8><span class="section-heading">T.3b.i: sapling_outputs_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-i-sapling-outputs-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 <a id="id7" class="footnote_reference" href="#zip-0307">7</a> <code>CompactBlock</code> format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<p>A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 <a id="id7" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<pre>T.3b.i.1: cmu (field encoding bytes)
T.3b.i.2: ephemeral_key (field encoding bytes)
T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
@ -183,7 +183,7 @@ T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)</pre>
<pre>"ZTxIdSOutM__Hash" (2 underscore characters)</pre>
</section>
<section id="t-3b-iii-sapling-outputs-noncompact-digest"><h8><span class="section-heading">T.3b.iii: sapling_outputs_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-3b-iii-sapling-outputs-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h8>
<p>A BLAKE2b-256 hash of the remaining subset of Sapling output information <strong>not</strong> included in the ZIP 307 <a id="id8" class="footnote_reference" href="#zip-0307">7</a> <code>CompactBlock</code> format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<p>A BLAKE2b-256 hash of the remaining subset of Sapling output information <strong>not</strong> included in the ZIP 307 <a id="id8" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:</p>
<pre>T.3b.iii.1: cv (field encoding bytes)
T.3b.iii.2: enc_ciphertext[564..] (post-memo Poly1305 AEAD tag of field encoding)
T.3b.iii.3: out_ciphertext (field encoding bytes)</pre>
@ -203,7 +203,7 @@ T.4f: anchorOrchard (32 bytes)</pre>
<pre>BLAKE2b-256("ZTxIdOrchardHash", [])</pre>
</section>
<section id="t-4a-orchard-actions-compact-digest"><h9><span class="section-heading">T.4a: orchard_actions_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4a-orchard-actions-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h9>
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="id9" class="footnote_reference" href="#zip-0307">7</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="id9" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4a.i : nullifier (field encoding bytes)
T.4a.ii : cmx (field encoding bytes)
T.4a.iii: ephemeralKey (field encoding bytes)
@ -218,7 +218,7 @@ T.4a.iv : encCiphertext[..52] (First 52 bytes of field encoding)</pre>
<pre>"ZTxIdOrcActMHash"</pre>
</section>
<section id="t-4c-orchard-actions-noncompact-digest"><h9><span class="section-heading">T.4c: orchard_actions_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4c-orchard-actions-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h9>
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="id10" class="footnote_reference" href="#zip-0307">7</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="id10" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4c.i : cv (field encoding bytes)
T.4c.ii : rk (field encoding bytes)
T.4c.iii: encCiphertext[564..] (post-memo suffix of field encoding)
@ -232,7 +232,7 @@ T.4c.iv : outCiphertext (field encoding bytes)</pre>
</section>
</section>
<section id="signature-digest"><h4><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 <a id="id11" class="footnote_reference" href="#zip-0143">5</a> and ZIP 243 <a id="id12" class="footnote_reference" href="#zip-0243">6</a>. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.</p>
<p>A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 <a id="id11" class="footnote_reference" href="#zip-0143">6</a> and ZIP 243 <a id="id12" class="footnote_reference" href="#zip-0243">7</a>. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.</p>
<p>The overall structure of the hash is as follows; each name referenced here will be described in detail below:</p>
<pre>signature_digest
├── header_digest
@ -254,7 +254,7 @@ S.4: orchard_digest (32-byte hash output)</pre>
</section>
<section id="s-2-transparent-sig-digest"><h6><span class="section-heading">S.2: transparent_sig_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-2-transparent-sig-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, the value of <code>transparent_sig_digest</code> is identical to the value specified in section <a href="#t-2-transparent-digest">T.2</a>.</p>
<p>If we are producing a hash for signature over a transparent input, the value of <code>transparent_sig_digest</code> depends upon the value of a <code>hash_type</code> flag as in ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">5</a>.</p>
<p>If we are producing a hash for signature over a transparent input, the value of <code>transparent_sig_digest</code> depends upon the value of a <code>hash_type</code> flag as in ZIP 143 <a id="id14" class="footnote_reference" href="#zip-0143">6</a>.</p>
<p>The construction of each component below depends upon the values of the <code>hash_type</code> flag bits. Each component will be described separately</p>
<p>This digest is a BLAKE2b-256 hash of the following values</p>
<pre>S.2a: prevouts_sig_digest (32-byte hash)
@ -365,7 +365,7 @@ A.3c: bindingSigOrchard (field encoding bytes)</pre>
is well-defined because
<span class="math">\(\mathsf{tx\_count} &gt; 0\)</span>
, due to the coinbase transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256 hashes personalized by the string <code>"ZcashAuthDatHash"</code>.</p>
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="id15" class="footnote_reference" href="#zip-0221">3</a>, is changed.</p>
<p>Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the <code>hashLightClientRoot</code> field, described in ZIP 221 <a id="id15" class="footnote_reference" href="#zip-0221">4</a>, is changed.</p>
<p><code>hashLightClientRoot</code> is renamed to <code>hashBlockCommitments</code>. The value of this hash is the BLAKE2b-256 hash personalized by the string <code>"ZcashBlockCommit"</code> of the following elements:</p>
<pre>hashLightClientRoot (as described in ZIP 221)
hashAuthDataRoot (as described below)
@ -390,10 +390,18 @@ terminator [0u8;32]</pre>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
@ -401,7 +409,7 @@ terminator [0u8;32]</pre>
<table id="zip-0221" class="footnote">
<tbody>
<tr>
<th>3</th>
<th>4</th>
<td><a href="zip-0221">ZIP 221: FlyClient - Consensus Layer Changes</a></td>
</tr>
</tbody>
@ -409,7 +417,7 @@ terminator [0u8;32]</pre>
<table id="zip-0076" class="footnote">
<tbody>
<tr>
<th>4</th>
<th>5</th>
<td><a href="zip-0076">ZIP 76: Transaction Signature Validation before Overwinter</a></td>
</tr>
</tbody>
@ -417,7 +425,7 @@ terminator [0u8;32]</pre>
<table id="zip-0143" class="footnote">
<tbody>
<tr>
<th>5</th>
<th>6</th>
<td><a href="zip-0143">ZIP 143: Transaction Signature Validation for Overwinter</a></td>
</tr>
</tbody>
@ -425,24 +433,16 @@ terminator [0u8;32]</pre>
<table id="zip-0243" class="footnote">
<tbody>
<tr>
<th>6</th>
<th>7</th>
<td><a href="zip-0243">ZIP 243: Transaction Signature Validation for Sapling</a></td>
</tr>
</tbody>
</table>
<table id="zip-0307" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0307">ZIP 307: Light Client Protocol for Payment Detection</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="protocol/nu5.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
<td><a href="zip-0307">ZIP 307: Light Client Protocol for Payment Detection</a></td>
</tr>
</tbody>
</table>

6
zip-0244.rst
View File

@ -10,6 +10,7 @@
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/411>
===========
Terminology
===========
@ -21,7 +22,7 @@ described in ZIP 200. [#zip-0200]_
The term "field encoding" refers to the binary serialized form of a Zcash transaction
field, as specified in section 7.1 of the Zcash protocol specification
[#protocol-txnencodingandconsensus]_.
[#protocol-txnencoding]_.
========
Abstract
@ -86,7 +87,6 @@ Requirements
is used to produce a signature hash in the case that the transaction contains
no transparent inputs.
================
Non-requirements
================
@ -746,10 +746,10 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0221] `ZIP 221: FlyClient - Consensus Layer Changes <zip-0221.rst>`_
.. [#zip-0076] `ZIP 76: Transaction Signature Validation before Overwinter <zip-0076.rst>`_
.. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter <zip-0143.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling <zip-0243.rst>`_
.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/nu5.pdf#txnencodingandconsensus>`_

5
zip-0245.rst
View File

@ -9,6 +9,7 @@
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/384>
Terminology
===========
@ -17,6 +18,7 @@ The key words "MUST" and "MUST NOT" in this document are to be interpreted as de
The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as
described in ZIP 200. [#zip-0200]_
Abstract
========
@ -24,6 +26,7 @@ This proposal defines changes to ZIP 244 [#zip-0244]_ transaction id and signatu
algorithms to accommodate the inclusion of transparent Zcash extensions (TZEs)
as defined in ZIP 222 [#zip-0222]_.
Specification
=============
@ -176,11 +179,13 @@ The personalization field of this hash is set to::
"ZTxAuthTZE__Hash" (2 underscore characters)
Reference implementation
========================
- https://github.com/zcash/librustzcash/pull/319/files
References
==========

2
zip-0250.html
View File

@ -86,7 +86,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>

2
zip-0250.rst
View File

@ -128,7 +128,7 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_

12
zip-0251.html
View File

@ -16,7 +16,7 @@ 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", 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 term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">5</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="id3" class="footnote_reference" href="#protocol-networks">3</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="id3" class="footnote_reference" href="#protocol-networks">3</a>.</p>
<p>"Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<section id="backward-compatibility"><h2><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></h2>
<p>Prior to the network upgrade activating on each network, Canopy and pre-Canopy nodes are compatible and can connect to each other. However, Canopy nodes will have a preference for connecting to other Canopy nodes, so pre-Canopy nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-Canopy nodes can still accept the numerically larger protocol version used by Canopy as being valid, Canopy nodes will always disconnect peers using lower protocol versions.</p>
<p>Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in <a id="id15" class="footnote_reference" href="#protocol-txnencodingandconsensus">4</a>; and use the same transaction digest algorithm as defined in <a id="id16" class="footnote_reference" href="#zip-0243">12</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id17" class="footnote_reference" href="#zip-0243">12</a></p>
<p>Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in <a id="id15" class="footnote_reference" href="#protocol-txnencoding">4</a>; and use the same transaction digest algorithm as defined in <a id="id16" class="footnote_reference" href="#zip-0243">12</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id17" class="footnote_reference" href="#zip-0243">12</a></p>
</section>
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a rel="bookmark" href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Support for Canopy on testnet will be implemented in <code>zcashd</code> version 3.1.0, which will advertise protocol version 170012. Support for Canopy on mainnet will be implemented in <code>zcashd</code> version 4.0.0, which will advertise protocol version 170013.</p>
@ -83,7 +83,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/canopy.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
@ -91,15 +91,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/canopy.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/canopy.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus</a></td>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>

10
zip-0251.rst
View File

@ -19,7 +19,7 @@ The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
"Canopy" is the code-name for the fifth Zcash network upgrade, also known as
Network Upgrade 4.
@ -110,7 +110,7 @@ will always disconnect peers using lower protocol versions.
Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not
define a new transaction version. Canopy transactions are therefore in the same
v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085
as defined in [#protocol-txnencodingandconsensus]_; and use the same transaction digest
as defined in [#protocol-txnencoding]_; and use the same transaction digest
algorithm as defined in [#zip-0243]_. This does not imply that transactions are
valid across the Canopy activation, since signatures MUST use the appropriate
consensus branch ID. [#zip-0243]_
@ -128,9 +128,9 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/canopy.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/canopy.pdf#networks>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus <protocol/canopy.pdf#txnencodingandconsensus>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
.. [#zip-0207] `ZIP 207: Funding Streams <zip-0207.rst>`_

10
zip-0252.html
View File

@ -19,7 +19,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/446">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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST" and "SHOULD" 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 term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">7</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="id3" class="footnote_reference" href="#protocol-networks">3</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="id3" class="footnote_reference" href="#protocol-networks">3</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines the deployment of the NU5 network upgrade.</p>
@ -120,7 +120,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2021.1.24 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
@ -128,15 +128,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/nu5.pdf#networks">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencodingandconsensus" class="footnote">
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/nu5.pdf#txnencodingandconsensus">Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus</a></td>
</tr>
</tbody>
</table>

8
zip-0252.rst
View File

@ -22,7 +22,7 @@ The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
Abstract
@ -201,9 +201,9 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.1.24 or later <protocol/nu5.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet <protocol/nu5.pdf#networks>`_
.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/nu5.pdf#txnencodingandconsensus>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0155] `ZIP 155: addrv2 message <zip-0155.rst>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_

8
zip-1014.html
View File

@ -27,13 +27,13 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", 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 term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="id2" class="footnote_reference" href="#zip-0200">6</a> and the Zcash Trademark Donation and License Agreement (<a id="id3" class="footnote_reference" href="#trademark">4</a> or successor agreement).</p>
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id4" class="footnote_reference" href="#protocol">2</a></p>
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. <a id="id4" class="footnote_reference" href="#protocol">2</a></p>
<p>"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric Coin Company, LLC.</p>
<p>"Bootstrap Project", also called "BP", refers to the 501(c)(3) nonprofit corporation of that name.</p>
<p>"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit corporation of that name.</p>
<p>"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). <a id="id5" class="footnote_reference" href="#section501c3">12</a></p>
<p>"Community Advisory Panel" refers to the panel of community members assembled by the Zcash Foundation and described at <a id="id6" class="footnote_reference" href="#zf-community">11</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="id7" class="footnote_reference" href="#protocol-networks">3</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="id7" class="footnote_reference" href="#protocol-networks">3</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal describes a structure for the Zcash Development Fund, to be enacted in Network Upgrade 4 and last for 4 years. This Dev Fund would consist of 20% of the block subsidies, split into 3 slices:</p>
@ -154,7 +154,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.15 or later</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2021.2.16 or later</a></td>
</tr>
</tbody>
</table>
@ -162,7 +162,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/308">https://githu
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>

9
zip-1014.rst
View File

@ -31,7 +31,7 @@ described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License
Agreement ([#trademark]_ or successor agreement).
The terms "block subsidy" and "halving" in this document are to be interpreted
as described in sections 3.9 and 7.7 of the Zcash Protocol Specification.
as described in sections 3.10 and 7.8 of the Zcash Protocol Specification.
[#protocol]_
"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric
@ -50,7 +50,7 @@ Code (Title 26 of the U.S. Code). [#section501c3]_
by the Zcash Foundation and described at [#zf-community]_.
The terms "Testnet" and "Mainnet" are to be interpreted as described in
section 3.11 of the Zcash Protocol Specification [#protocol-networks]_.
section 3.12 of the Zcash Protocol Specification [#protocol-networks]_.
Abstract
@ -94,6 +94,7 @@ contribute a slice of the block subsidies otherwise allocated to
miners as a donation to support charitable, educational, and
scientific activities within the meaning of Section 501(c)(3).
Requirements
============
@ -399,8 +400,8 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later <protocol/protocol.pdf>`_
.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf>`_
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_