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

Update ZIPs 207, 214, 251, and 1014 to use Canopy name for NU4. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-05-26 23:05:21 +01:00
parent 66a41077ca
commit 62a1d5c103
10 changed files with 87 additions and 86 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.rst
View File

@ -37,7 +37,7 @@ License
Unless otherwise stated in this repository’s individual files, the
contents of this repository are released under the terms of the MIT
license. See `COPYING <COPYING.rst>`__ for more information or see
license. See `COPYING <COPYING>`__ for more information or see
https://opensource.org/licenses/MIT .
Index of ZIPs
@ -66,7 +66,7 @@ Index of ZIPs
<tr> <td>221</td> <td class="left"><a href="zip-0221.rst">FlyClient - Consensus-Layer Changes</a></td> <td>Proposed</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
<tr> <td>250</td> <td class="left"><a href="zip-0250.rst">Deployment of the Heartwood Network Upgrade</a></td> <td>Draft</td>
<tr> <td>251</td> <td class="left"><a href="zip-0251.rst">Deployment of the ${NU4} Network Upgrade</a></td> <td>Draft</td>
<tr> <td>251</td> <td class="left"><a href="zip-0251.rst">Deployment of the Canopy Network Upgrade</a></td> <td>Draft</td>
<tr> <td>308</td> <td class="left"><a href="zip-0308.rst">Sprout to Sapling Migration</a></td> <td>Final</td>
<tr> <td>310</td> <td class="left"><a href="zip-0310.rst">Security Properties of Sapling Viewing Keys</a></td> <td>Draft</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing mempool denial-of-service</a></td> <td>Final</td>

2
index.html
View File

@ -45,7 +45,7 @@
<tr> <td>221</td> <td class="left"><a href="zip-0221">FlyClient - Consensus-Layer Changes</a></td> <td>Proposed</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
<tr> <td>250</td> <td class="left"><a href="zip-0250">Deployment of the Heartwood Network Upgrade</a></td> <td>Draft</td>
<tr> <td>251</td> <td class="left"><a href="zip-0251">Deployment of the ${NU4} Network Upgrade</a></td> <td>Draft</td>
<tr> <td>251</td> <td class="left"><a href="zip-0251">Deployment of the Canopy Network Upgrade</a></td> <td>Draft</td>
<tr> <td>308</td> <td class="left"><a href="zip-0308">Sprout to Sapling Migration</a></td> <td>Final</td>
<tr> <td>310</td> <td class="left"><a href="zip-0310">Security Properties of Sapling Viewing Keys</a></td> <td>Draft</td>
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing mempool denial-of-service</a></td> <td>Final</td>

16
zip-0207.html
View File

@ -21,7 +21,7 @@ License: MIT</pre>
<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">8</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>${NU4}</dt>
<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">2</a></dd>
@ -193,18 +193,18 @@ License: MIT</pre>
</tbody>
</table>
</blockquote>
<p>On Mainnet, ${NU4} is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to ${NU4} activation.</p>
<p>On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.</p>
</section>
<section id="consensus-rules"><h3><span class="section-heading">Consensus rules</span><span class="section-anchor"> <a href="#consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Prior to activation of the ${NU4} network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id16" class="footnote_reference" href="#protocol-foundersreward">6</a></p>
<p>Once the ${NU4} network upgrade activates:</p>
<p>Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id16" class="footnote_reference" href="#protocol-foundersreward">6</a></p>
<p>Once the Canopy network upgrade activates:</p>
<ul>
<li>The existing consensus rule for payment of the Founders' Reward <a id="id17" class="footnote_reference" href="#protocol-foundersreward">6</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
<li>The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.</li>
<li>The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form <code>OP_HASH160 RedeemScriptHash(height) OP_EQUAL</code> as the <code>scriptPubKey</code>.</li>
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id18" class="footnote_reference" href="#zip-0213">10</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.</li>
</ul>
<p>For the funding stream definitions to be activated at ${NU4}, see ZIP 214. <a id="id19" class="footnote_reference" href="#zip-0214">11</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id20" class="footnote_reference" href="#zip-0000">7</a></p>
<p>For the funding stream definitions to be activated at Canopy, see ZIP 214. <a id="id19" class="footnote_reference" href="#zip-0214">11</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id20" class="footnote_reference" href="#zip-0000">7</a></p>
</section>
<section id="example-implementation"><h3><span class="section-heading">Example implementation</span><span class="section-anchor"> <a href="#example-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<pre data-language="cpp"><span class="k">struct</span> <span class="n">FundingPeriod</span> <span class="p">{</span>
@ -321,7 +321,7 @@ License: MIT</pre>
<span class="p">{</span>
<span class="p">...</span>
<span class="k">if</span> <span class="p">(</span><span class="n">NetworkUpgradeActive</span><span class="p">(</span><span class="n">nHeight</span><span class="p">,</span> <span class="n">consensusParams</span><span class="p">,</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_NU4</span><span class="p">))</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">NetworkUpgradeActive</span><span class="p">(</span><span class="n">nHeight</span><span class="p">,</span> <span class="n">consensusParams</span><span class="p">,</span> <span class="n">Consensus</span><span class="o">::</span><span class="n">UPGRADE_CANOPY</span><span class="p">))</span> <span class="p">{</span>
<span class="c1">// Coinbase transaction must include outputs corresponding to the consensus</span>
<span class="c1">// funding streams active at the current block height.</span>
<span class="k">auto</span> <span class="n">requiredStreams</span> <span class="o">=</span> <span class="n">GetActiveFundingStreams</span><span class="p">(</span><span class="n">nHeight</span><span class="p">,</span> <span class="n">consensusParams</span><span class="p">);</span>
@ -369,7 +369,7 @@ License: MIT</pre>
</section>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal is intended to be deployed with ${NU4}. <a id="id21" class="footnote_reference" href="#zip-0251">12</a></p>
<p>This proposal is intended to be deployed with Canopy. <a id="id21" class="footnote_reference" href="#zip-0251">12</a></p>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
@ -470,7 +470,7 @@ License: MIT</pre>
<tbody>
<tr>
<th>12</th>
<td><a href="zip-0251">ZIP 251: Deployment of the ${NU4} Network Upgrade</a></td>
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
</tr>
</tbody>
</table>

18
zip-0207.rst
View File

@ -25,7 +25,7 @@ interpreted as described in ZIP 200. [#zip-0200]_
The terms below are to be interpreted as follows:
${NU4}
Canopy
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
Testnet
The Zcash test network, as defined in the Zcash Protocol Specification. [#protocol]_
@ -168,18 +168,18 @@ periods:
``PostBlossomHalvingInterval + 1`` C2
================================== ======== ======== ========
On Mainnet, ${NU4} is planned to activate exactly at the point when the Founders'
On Mainnet, Canopy is planned to activate exactly at the point when the Founders'
Reward expires, at block height 1046400. On Testnet, there will be a shortened
Founders' Reward address period prior to ${NU4} activation.
Founders' Reward address period prior to Canopy activation.
Consensus rules
---------------
Prior to activation of the ${NU4} network upgrade, the existing consensus rule
Prior to activation of the Canopy network upgrade, the existing consensus rule
for payment of the original Founders' Reward is enforced. [#protocol-foundersreward]_
Once the ${NU4} network upgrade activates:
Once the Canopy network upgrade activates:
- The existing consensus rule for payment of the Founders' Reward [#protocol-foundersreward]_
is no longer active.
@ -199,7 +199,7 @@ Once the ${NU4} network upgrade activates:
limited to, outputs for funding streams) MUST have valid note commitments
when recovered using a 32-byte array of zeroes as the outgoing viewing key.
For the funding stream definitions to be activated at ${NU4}, see ZIP 214. [#zip-0214]_
For the funding stream definitions to be activated at Canopy, see ZIP 214. [#zip-0214]_
Funding stream definitions can be added, changed, or deleted in ZIPs associated
with subsequent network upgrades, subject to the ZIP process. [#zip-0000]_
@ -323,7 +323,7 @@ Example implementation
{
...
if (NetworkUpgradeActive(nHeight, consensusParams, Consensus::UPGRADE_NU4)) {
if (NetworkUpgradeActive(nHeight, consensusParams, Consensus::UPGRADE_CANOPY)) {
// Coinbase transaction must include outputs corresponding to the consensus
// funding streams active at the current block height.
auto requiredStreams = GetActiveFundingStreams(nHeight, consensusParams);
@ -373,7 +373,7 @@ Example implementation
Deployment
==========
This proposal is intended to be deployed with ${NU4}. [#zip-0251]_
This proposal is intended to be deployed with Canopy. [#zip-0251]_
Backward compatibility
@ -406,5 +406,5 @@ References
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund <zip-0214.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the ${NU4} Network Upgrade <zip-0251.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_

18
zip-0214.html
View File

@ -22,7 +22,7 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<p>The terms "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "ECC slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 <a id="id6" class="footnote_reference" href="#zip-1014">9</a>.</p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>${NU4}</dt>
<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 <a id="id7" class="footnote_reference" href="#protocol">2</a>.</dd>
@ -49,8 +49,8 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Blossom network upgrade changed the height of the first halving to block height 1046400 <a id="id10" class="footnote_reference" href="#zip-0208">7</a>, as a consequence of reducing the block target spacing from 150 seconds to 75 seconds.</p>
<p>Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of ${NU4} on Mainnet therefore SHALL be 1046400.</p>
<p>ZIP 207 <a id="id11" class="footnote_reference" href="#zip-0207">6</a> SHALL be activated in ${NU4}.</p>
<p>Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving, the activation height of Canopy on Mainnet therefore SHALL be 1046400.</p>
<p>ZIP 207 <a id="id11" class="footnote_reference" href="#zip-0207">6</a> SHALL be activated in Canopy.</p>
<p>The following funding streams are defined for Mainnet:</p>
<blockquote>
<table>
@ -89,8 +89,8 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
</table>
</blockquote>
<p>As specified in <a id="id12" class="footnote_reference" href="#zip-0207">6</a>, a funding stream is active for a span of blocks that includes the block at its start height, but excludes the block at its end height.</p>
<p>The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of ${NU4} on Testnet, i.e. xxxxxxx.</p>
<p>Note: on Testnet, the activation height of ${NU4} will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).</p>
<p>The funding streams are defined for Testnet are identical except that the start height of each stream is the activation height of Canopy on Testnet, i.e. xxxxxxx.</p>
<p>Note: on Testnet, the activation height of Canopy will be before the first halving. Therefore, the consequence of the above rules for Testnet is that the amount sent to each Zcash Development Fund recipient address will initially (before Testnet block height 1046400) be double the number of currency units as the corresponding initial amount on Mainnet. This reduces to the same number of currency units as on Mainnet, from Testnet block heights 1046400 (inclusive) to 2726400 (exclusive).</p>
<section id="dev-fund-recipient-addresses"><h3><span class="section-heading">Dev Fund Recipient Addresses</span><span class="section-anchor"> <a href="#dev-fund-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For each of Testnet and Mainnet, before deploying this ZIP in a node implementation with the activation height set for that network, each of the parties (ECC and ZF) SHALL generate sequences of recipient addresses to be used for each stream in each funding period:</p>
<ul>
@ -101,9 +101,9 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<p>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="id13" class="footnote_reference" href="#zip-1014">9</a>.</p>
<p>No requirements are imposed on the use of funds sent to Testnet funding streams.</p>
<section id="direct-grant-option"><h4><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before ${NU4} activation, some portion of the <strong>MG slice</strong> may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. <a id="id14" class="footnote_reference" href="#zip-1014">9</a></p>
<p>ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC and ZF before Canopy activation, some portion of the <strong>MG slice</strong> may be directly assigned to the grantee(s), rather than accepted and disbursed by ZF. <a id="id14" class="footnote_reference" href="#zip-1014">9</a></p>
<p>The funding stream mechanism allows for this option by adding a funding stream corresponding to each direct grantee, with addresses generated by ZF. In this case the total amount of funding streams assigned to direct grantees MUST be subtracted from the funding stream for the remaining <strong>MG slice</strong> (or, if all Major Grants are direct, replace the funding stream for the <strong>MG slice</strong>).</p>
<p>For each network upgrade after ${NU4} requiring modifications to the set of direct grantees, a separate ZIP would be published specifying those modifications.</p>
<p>For each network upgrade after Canopy requiring modifications to the set of direct grantees, a separate ZIP would be published specifying those modifications.</p>
</section>
</section>
<section id="mainnet-recipient-addresses"><h3><span class="section-heading">Mainnet Recipient Addresses</span><span class="section-anchor"> <a href="#mainnet-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -129,7 +129,7 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<p>It was judged to be unnecessary to have a mechanism to update funding stream definitions (in case of security breach or changes to direct grant recipients) other than at network upgrades.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal is intended to be deployed with ${NU4}. <a id="id16" class="footnote_reference" href="#zip-0251">8</a></p>
<p>This proposal is intended to be deployed with Canopy. <a id="id16" class="footnote_reference" href="#zip-0251">8</a></p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
@ -192,7 +192,7 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<tbody>
<tr>
<th>8</th>
<td><a href="zip-0251">ZIP 251: Deployment of the ${NU4} Network Upgrade</a></td>
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
</tr>
</tbody>
</table>

18
zip-0214.rst
View File

@ -34,7 +34,7 @@ be interpreted as described in ZIP 1014 [#zip-1014]_.
The terms below are to be interpreted as follows:
${NU4}
Canopy
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
Testnet
The Zcash test network, as defined in [#protocol]_.
@ -97,9 +97,9 @@ The Blossom network upgrade changed the height of the first halving to block hei
150 seconds to 75 seconds.
Since ZIP 1014 specifies that the Zcash Development Fund starts at the first halving,
the activation height of ${NU4} on Mainnet therefore SHALL be 1046400.
the activation height of Canopy on Mainnet therefore SHALL be 1046400.
ZIP 207 [#zip-0207]_ SHALL be activated in ${NU4}.
ZIP 207 [#zip-0207]_ SHALL be activated in Canopy.
The following funding streams are defined for Mainnet:
@ -116,10 +116,10 @@ that includes the block at its start height, but excludes the block at its end
height.
The funding streams are defined for Testnet are identical except that the
start height of each stream is the activation height of ${NU4} on Testnet, i.e.
start height of each stream is the activation height of Canopy on Testnet, i.e.
xxxxxxx.
Note: on Testnet, the activation height of ${NU4} will be before the first halving.
Note: on Testnet, the activation height of Canopy will be before the first halving.
Therefore, the consequence of the above rules for Testnet is that the amount sent
to each Zcash Development Fund recipient address will initially (before Testnet
block height 1046400) be double the number of currency units as the corresponding
@ -154,7 +154,7 @@ Direct-grant option
'''''''''''''''''''
ZIP 1014 specifies a "direct-grant option" by which, if agreed upon by both ECC
and ZF before ${NU4} activation, some portion of the **MG slice** may be directly
and ZF before Canopy activation, some portion of the **MG slice** may be directly
assigned to the grantee(s), rather than accepted and disbursed by ZF. [#zip-1014]_
The funding stream mechanism allows for this option by adding a funding stream
@ -163,7 +163,7 @@ the total amount of funding streams assigned to direct grantees MUST be subtract
from the funding stream for the remaining **MG slice** (or, if all Major Grants are
direct, replace the funding stream for the **MG slice**).
For each network upgrade after ${NU4} requiring modifications to the set of direct
For each network upgrade after Canopy requiring modifications to the set of direct
grantees, a separate ZIP would be published specifying those modifications.
@ -352,7 +352,7 @@ other than at network upgrades.
Deployment
==========
This proposal is intended to be deployed with ${NU4}. [#zip-0251]_
This proposal is intended to be deployed with Canopy. [#zip-0251]_
References
@ -365,5 +365,5 @@ References
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
.. [#zip-0207] `ZIP 207: Funding Streams <zip-0207.rst>`_
.. [#zip-0208] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the ${NU4} Network Upgrade <zip-0251.rst>`_
.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade <zip-0251.rst>`_
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_

36
zip-0251.html
View File

@ -1,13 +1,13 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 251: Deployment of the Network Upgrade</title>
<title>ZIP 251: Deployment of the Canopy Network Upgrade</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 251
Title: Deployment of the ${NU4} Network Upgrade
Title: Deployment of the Canopy Network Upgrade
Owners: Daira Hopwood &lt;daira@electriccoin.co&gt;
Status: Draft
Category: Consensus
@ -18,7 +18,7 @@ License: MIT</pre>
<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">3</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>${NU4}</dt>
<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 <a id="id3" class="footnote_reference" href="#protocol">2</a>.</dd>
@ -27,11 +27,11 @@ License: MIT</pre>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a 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 ${NU4} network upgrade.</p>
<p>This proposal defines the deployment of the Canopy network upgrade.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="nu4-deployment"><h3><span class="section-heading">${NU4} deployment</span><span class="section-anchor"> <a href="#nu4-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The primary sources of information about ${NU4} consensus protocol changes are:</p>
<section id="canopy-deployment"><h3><span class="section-heading">Canopy deployment</span><span class="section-anchor"> <a href="#canopy-deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The primary sources of information about Canopy consensus protocol changes are:</p>
<ul>
<li>The Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol">2</a></li>
<li>ZIP 200: Network Upgrade Mechanism <a id="id6" class="footnote_reference" href="#zip-0200">3</a></li>
@ -41,39 +41,39 @@ License: MIT</pre>
<li>TODO: other ZIPs</li>
</ul>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id10" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id11" class="footnote_reference" href="#zip-0200">3</a> are defined for the ${NU4} upgrade:</p>
<p>The following network upgrade constants <a id="id11" class="footnote_reference" href="#zip-0200">3</a> are defined for the Canopy upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0xTODO</code></dd>
<dt>ACTIVATION_HEIGHT (${NU4})</dt>
<dt>ACTIVATION_HEIGHT (Canopy)</dt>
<dd>
<p>Testnet: TODO</p>
<p>Mainnet: 1046400</p>
</dd>
</dl>
<p>Nodes compatible with ${NU4} activation on testnet MUST advertise protocol version TODO or later. Nodes compatible with ${NU4} activation on mainnet MUST advertise protocol version TODO or later. The minimum peer protocol version that ${NU4}-compatible nodes will connect to is 170002.</p>
<p>Pre-${NU4} testnet nodes are defined as nodes on testnet advertising a protocol version less than TODO. Pre-${NU4} mainnet nodes are defined as nodes on mainnet advertising a protocol version less than TODO.</p>
<p>For each network (testnet and mainnet), approximately 1.5 days (defined in terms of block height) before the corresponding ${NU4} activation height, nodes compatible with ${NU4} activation on that network will change the behaviour of their peer connection logic in order to prefer pre-${NU4} peers on that network for eviction from the set of peer connections:</p>
<p>Nodes compatible with Canopy activation on testnet MUST advertise protocol version TODO or later. Nodes compatible with Canopy activation on mainnet MUST advertise protocol version TODO or later. The minimum peer protocol version that Canopy-compatible nodes will connect to is 170002.</p>
<p>Pre-Canopy testnet nodes are defined as nodes on testnet advertising a protocol version less than TODO. Pre-Canopy mainnet nodes are defined as nodes on mainnet advertising a protocol version less than TODO.</p>
<p>For each network (testnet and mainnet), approximately 1.5 days (defined in terms of block height) before the corresponding Canopy activation height, nodes compatible with Canopy activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Canopy peers on that network for eviction from the set of peer connections:</p>
<pre>/**
* The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks).
* This was three days for upgrades up to and including Blossom, and is 1.5 days from Heartwood onward.
*/
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<p>The implementation is similar to that for Overwinter which was described in <a id="id12" class="footnote_reference" href="#zip-0201">4</a>.</p>
<p>Once ${NU4} activates on testnet or mainnet, ${NU4} nodes SHOULD take steps to:</p>
<p>Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-${NU4} nodes on that network;</li>
<li>disconnect any existing connections to pre-${NU4} nodes on that network.</li>
<li>reject new connections from pre-Canopy nodes on that network;</li>
<li>disconnect any existing connections to pre-Canopy nodes on that network.</li>
</ul>
</section>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a 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, ${NU4} and pre-${NU4} nodes are compatible and can connect to each other. However, ${NU4} nodes will have a preference for connecting to other ${NU4} nodes, so pre-${NU4} nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-${NU4} nodes can still accept the numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes will always disconnect peers using lower protocol versions.</p>
<p>TODO: delete if inapplicable. Unlike Overwinter and Sapling, and like Blossom and Heartwood, ${NU4} does not define a new transaction version. ${NU4} 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="id13" class="footnote_reference" href="#protocol">2</a> section 7.1; and use the same transaction digest algorithm as defined in <a id="id14" class="footnote_reference" href="#zip-0243">7</a>. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID. <a id="id15" class="footnote_reference" href="#zip-0243">7</a></p>
<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>TODO: delete if inapplicable. 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="id13" class="footnote_reference" href="#protocol">2</a> section 7.1; and use the same transaction digest algorithm as defined in <a id="id14" class="footnote_reference" href="#zip-0243">7</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id15" class="footnote_reference" href="#zip-0243">7</a></p>
</section>
<section id="support-in-zcashd"><h2><span class="section-heading">Support in zcashd</span><span class="section-anchor"> <a href="#support-in-zcashd"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Support for ${NU4} on testnet will be implemented in <code>zcashd</code> version 3.1.0, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in <code>zcashd</code> version 4.0.0, which will advertise protocol version TODO.</p>
<p>Support for Canopy on testnet will be implemented in <code>zcashd</code> version 3.1.0, which will advertise protocol version TODO. Support for Canopy on mainnet will be implemented in <code>zcashd</code> version 4.0.0, which will advertise protocol version TODO.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">

56
zip-0251.rst
View File

@ -1,7 +1,7 @@
::
ZIP: 251
Title: Deployment of the ${NU4} Network Upgrade
Title: Deployment of the Canopy Network Upgrade
Owners: Daira Hopwood <daira@electriccoin.co>
Status: Draft
Category: Consensus
@ -20,7 +20,7 @@ ZIP 200. [#zip-0200]_
The terms below are to be interpreted as follows:
${NU4}
Canopy
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
Testnet
The Zcash test network, as defined in [#protocol]_.
@ -31,16 +31,16 @@ Mainnet
Abstract
========
This proposal defines the deployment of the ${NU4} network upgrade.
This proposal defines the deployment of the Canopy network upgrade.
Specification
=============
${NU4} deployment
Canopy deployment
-----------------
The primary sources of information about ${NU4} consensus protocol changes are:
The primary sources of information about Canopy consensus protocol changes are:
- The Zcash Protocol Specification [#protocol]_
- ZIP 200: Network Upgrade Mechanism [#zip-0200]_
@ -53,32 +53,32 @@ The network handshake and peer management mechanisms defined in ZIP 201 [#zip-02
also apply to this upgrade.
The following network upgrade constants [#zip-0200]_ are defined for the ${NU4}
The following network upgrade constants [#zip-0200]_ are defined for the Canopy
upgrade:
CONSENSUS_BRANCH_ID
``0xTODO``
ACTIVATION_HEIGHT (${NU4})
ACTIVATION_HEIGHT (Canopy)
Testnet: TODO
Mainnet: 1046400
Nodes compatible with ${NU4} activation on testnet MUST advertise protocol version
TODO or later. Nodes compatible with ${NU4} activation on mainnet MUST advertise
Nodes compatible with Canopy activation on testnet MUST advertise protocol version
TODO or later. Nodes compatible with Canopy activation on mainnet MUST advertise
protocol version TODO or later. The minimum peer protocol version that
${NU4}-compatible nodes will connect to is 170002.
Canopy-compatible nodes will connect to is 170002.
Pre-${NU4} testnet nodes are defined as nodes on testnet advertising a protocol
version less than TODO. Pre-${NU4} mainnet nodes are defined as nodes on mainnet
Pre-Canopy testnet nodes are defined as nodes on testnet advertising a protocol
version less than TODO. Pre-Canopy mainnet nodes are defined as nodes on mainnet
advertising a protocol version less than TODO.
For each network (testnet and mainnet), approximately 1.5 days (defined in terms of
block height) before the corresponding ${NU4} activation height, nodes compatible
with ${NU4} activation on that network will change the behaviour of their peer
connection logic in order to prefer pre-${NU4} peers on that network for eviction
block height) before the corresponding Canopy activation height, nodes compatible
with Canopy activation on that network will change the behaviour of their peer
connection logic in order to prefer pre-Canopy peers on that network for eviction
from the set of peer connections::
/**
@ -90,39 +90,39 @@ from the set of peer connections::
The implementation is similar to that for Overwinter which was described in
[#zip-0201]_.
Once ${NU4} activates on testnet or mainnet, ${NU4} nodes SHOULD take steps to:
Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to:
- reject new connections from pre-${NU4} nodes on that network;
- disconnect any existing connections to pre-${NU4} nodes on that network.
- reject new connections from pre-Canopy nodes on that network;
- disconnect any existing connections to pre-Canopy nodes on that network.
Backward compatibility
======================
Prior to the network upgrade activating on each network, ${NU4} and pre-${NU4}
nodes are compatible and can connect to each other. However, ${NU4} nodes will
have a preference for connecting to other ${NU4} nodes, so pre-${NU4} nodes will
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.
Once the network upgrades, even though pre-${NU4} nodes can still accept the
numerically larger protocol version used by ${NU4} as being valid, ${NU4} nodes
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.
TODO: delete if inapplicable.
Unlike Overwinter and Sapling, and like Blossom and Heartwood, ${NU4} does not
define a new transaction version. ${NU4} transactions are therefore in the same
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]_ section 7.1; and use the same transaction digest
algorithm as defined in [#zip-0243]_. This does not imply that transactions are
valid across the ${NU4} activation, since signatures MUST use the appropriate
valid across the Canopy activation, since signatures MUST use the appropriate
consensus branch ID. [#zip-0243]_
Support in zcashd
=================
Support for ${NU4} on testnet will be implemented in ``zcashd`` version 3.1.0, which
will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented
Support for Canopy on testnet will be implemented in ``zcashd`` version 3.1.0, which
will advertise protocol version TODO. Support for Canopy on mainnet will be implemented
in ``zcashd`` version 4.0.0, which will advertise protocol version TODO.

2
zip-1014.html
View File

@ -96,7 +96,7 @@ Discussions-To: &lt;https://forum.zcashcommunity.com/t/community-sentiment-polli
<p>ZF SHALL recognize the MG slice of the Dev Fund as a Restricted Fund donation under the above constraints (suitably formalized), and keep separate accounting of its balance and usage under its <a href="#transparency-and-accountability">Transparency and Accountability</a> obligations defined below.</p>
<p>ZF SHALL strive to define target metrics and key performance indicators, and the Major Grant Review Committee SHOULD utilize these in its funding decisions.</p>
<section id="direct-grant-option"><h5><span class="section-heading">Direct-grant option</span><span class="section-anchor"> <a href="#direct-grant-option"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>It may be deemed better, operationally or legally, if the Major Grant funds are not accepted and disbursed by ZF, but rather directly assigned to the grantees. Thus, the following mechanism MAY be used in perpetuity for some or all grantees, if agreed upon by both ECC and ZF before NU4 activation:</p>
<p>It may be deemed better, operationally or legally, if the Major Grant funds are not accepted and disbursed by ZF, but rather directly assigned to the grantees. Thus, the following mechanism MAY be used in perpetuity for some or all grantees, if agreed upon by both ECC and ZF before Network Upgrade 4 (Canopy) activation:</p>
<p>Prior to each network upgrade, the Foundation SHALL publish a list of grantees' addresses and the total number of Dev Fund ZEC per block they should receive. ECC and ZF SHALL implement this list in any implementations of the Zcash consensus rules they maintain. This decision will then be, effectively, ratified by the miners as the network upgrade activates.</p>
</section>
</section>

3
zip-1014.rst
View File

@ -248,7 +248,8 @@ Direct-grant option
It may be deemed better, operationally or legally, if the Major Grant funds
are not accepted and disbursed by ZF, but rather directly assigned to the
grantees. Thus, the following mechanism MAY be used in perpetuity for some
or all grantees, if agreed upon by both ECC and ZF before NU4 activation:
or all grantees, if agreed upon by both ECC and ZF before Network Upgrade 4
(Canopy) activation:
Prior to each network upgrade, the Foundation SHALL publish a list of
grantees' addresses and the total number of Dev Fund ZEC per block they