mirror of https://github.com/zcash/zips.git
Add ZIPs 214 and 251.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
811fb7e0ce
commit
6526ebb088
|
|
@ -62,9 +62,11 @@ Index of ZIPs
|
|||
<tr> <td>209</td> <td class="left"><a href="zip-0209.rst">Prohibit Negative Shielded Value Pool</a></td> <td>Final</td>
|
||||
<tr> <td>210</td> <td class="left"><a href="zip-0210.rst">Sapling Anchor Deduplication within Transactions</a></td> <td>Draft</td>
|
||||
<tr> <td>213</td> <td class="left"><a href="zip-0213.rst">Shielded Coinbase</a></td> <td>Implemented (zcashd)</td>
|
||||
<tr> <td>214</td> <td class="left"><a href="zip-0214.rst">Consensus rules for a Zcash Development Fund</a></td> <td>Draft</td>
|
||||
<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>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>
|
||||
|
|
|
|||
|
|
@ -41,9 +41,11 @@
|
|||
<tr> <td>209</td> <td class="left"><a href="zip-0209">Prohibit Negative Shielded Value Pool</a></td> <td>Final</td>
|
||||
<tr> <td>210</td> <td class="left"><a href="zip-0210">Sapling Anchor Deduplication within Transactions</a></td> <td>Draft</td>
|
||||
<tr> <td>213</td> <td class="left"><a href="zip-0213">Shielded Coinbase</a></td> <td>Implemented (zcashd)</td>
|
||||
<tr> <td>214</td> <td class="left"><a href="zip-0214">Consensus rules for a Zcash Development Fund</a></td> <td>Draft</td>
|
||||
<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>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>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,198 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 214: Consensus rules for a Zcash Development Fund</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: 214
|
||||
Title: Consensus rules for a Zcash Development Fund
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Draft
|
||||
Category: Consensus
|
||||
Created: 2020-02-28
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560></pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a 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">5</a> and the Zcash Trademark Donation and License Agreement (<a id="id3" class="footnote_reference" href="#trademark">3</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 "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="id5" class="footnote_reference" href="#zip-1014">9</a>.</p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>${NU4}</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="id6" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in <a id="id7" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</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 ZIP describes consensus rule changes interpreting the proposed structure of the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last for 4 years.</p>
|
||||
</section>
|
||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>Motivation for the Zcash Development Fund itself is considered in ZIP 1014 <a id="id8" class="footnote_reference" href="#zip-1014">9</a>, which gives a high-level description of the intended structure of the fund.</p>
|
||||
<p>An important motivation for describing the consensus rules in a separate ZIP is to avoid making unintended changes to ZIP 1014, which has already been agreed between ECC, ZF, and the Zcash community. This facilitates critically assessing whether the consensus rule changes accurately reflect the intent of ZIP 1014.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary requirement of this ZIP is to make changes to consensus rules necessary and sufficient to implement the intent of ZIP 1014.</p>
|
||||
<p>The Zcash Development Fund distributes funding in ZEC obtained from block subsidies on Mainnet. This ZIP should also specify corresponding rules, addresses, and activation height for Testnet, in order to allow testing and auditing of the design and implementation within sufficient lead time before activation on Mainnet.</p>
|
||||
</section>
|
||||
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a href="#non-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what is implementable by Zcash consensus rules.</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>
|
||||
<p>The Blossom network upgrade changed the height of the first halving to block height 1046400 <a id="id9" 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="id10" class="footnote_reference" href="#zip-0207">6</a> SHALL be activated in ${NU4}.</p>
|
||||
<p>The following funding streams are defined for Mainnet:</p>
|
||||
<blockquote>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Stream</th>
|
||||
<th>Numerator</th>
|
||||
<th>Denominator</th>
|
||||
<th>Start height</th>
|
||||
<th>End height</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>FS_ECC</code></td>
|
||||
<td>7</td>
|
||||
<td>100</td>
|
||||
<td>1046400</td>
|
||||
<td>2726400</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>FS_ZF</code></td>
|
||||
<td>5</td>
|
||||
<td>100</td>
|
||||
<td>1046400</td>
|
||||
<td>2726400</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>FS_MG</code></td>
|
||||
<td>8</td>
|
||||
<td>100</td>
|
||||
<td>1046400</td>
|
||||
<td>2726400</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<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 corresponding initial amount on Mainnet. This reduces to the same amount 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 independent recipient addresses to be used for each stream in each funding period:</p>
|
||||
<ul>
|
||||
<li>ECC SHALL generate the addresses for the <code>FS_ECC</code> funding stream, which on Mainnet corresponds to the <strong>ECC slice</strong>;</li>
|
||||
<li>ZF SHALL generate the addresses for the <code>FS_ZF</code> and <code>FS_MG</code> funding streams, which on Mainnet correspond to the <strong>ZF slice</strong> and <strong>MG slice</strong> respectively.</li>
|
||||
</ul>
|
||||
<p>Funds sent to each Mainnet funding stream SHALL be governed by all requirements on the corresponding slice specified in ZIP 1014 <a id="id11" 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="id12" 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>
|
||||
</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>
|
||||
<blockquote>
|
||||
<dl>
|
||||
<dt>FS_ECC_Addresses[0..47] = [</dt>
|
||||
<dd>"TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO" ]</dd>
|
||||
<dt>FS_ZF_Addresses[0..47] = [</dt>
|
||||
<dd>"TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO" ]</dd>
|
||||
<dt>FS_MG_Addresses[0..47] = [</dt>
|
||||
<dd>"TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO", "TODO" ]</dd>
|
||||
</dl>
|
||||
</blockquote>
|
||||
</section>
|
||||
<section id="testnet-recipient-addresses"><h3><span class="section-heading">Testnet Recipient Addresses</span><span class="section-anchor"> <a href="#testnet-recipient-addresses"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>TODO</p>
|
||||
</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="id13" 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">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>1</th>
|
||||
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification [Overwinter+Sapling+Blossom]</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="trademark" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>3</th>
|
||||
<td><a href="https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf">Zcash Trademark Donation and License Agreement</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="osd" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="https://opensource.org/osd">The Open Source Definition</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0200" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0207" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="zip-0207">ZIP 207: Funding Streams</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0208" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0251" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>8</th>
|
||||
<td><a href="zip-0251">ZIP 251: Deployment of the ${NU4} Network Upgrade</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-1014" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>9</th>
|
||||
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,327 @@
|
|||
::
|
||||
|
||||
ZIP: 214
|
||||
Title: Consensus rules for a Zcash Development Fund
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Draft
|
||||
Category: Consensus
|
||||
Created: 2020-02-28
|
||||
License: MIT
|
||||
Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY"
|
||||
in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as
|
||||
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.
|
||||
[#protocol]_
|
||||
|
||||
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 [#zip-1014]_.
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
${NU4}
|
||||
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
|
||||
Testnet
|
||||
The Zcash test network, as defined in [#protocol]_.
|
||||
Mainnet
|
||||
The Zcash production network, as defined in [#protocol]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This ZIP describes consensus rule changes interpreting the proposed structure of
|
||||
the Zcash Development Fund, which is to be enacted in Network Upgrade 4 and last
|
||||
for 4 years.
|
||||
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
Motivation for the Zcash Development Fund itself is considered in ZIP 1014
|
||||
[#zip-1014]_, which gives a high-level description of the intended structure of
|
||||
the fund.
|
||||
|
||||
An important motivation for describing the consensus rules in a separate ZIP is
|
||||
to avoid making unintended changes to ZIP 1014, which has already been agreed
|
||||
between ECC, ZF, and the Zcash community. This facilitates critically assessing
|
||||
whether the consensus rule changes accurately reflect the intent of ZIP 1014.
|
||||
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
The primary requirement of this ZIP is to make changes to consensus rules necessary
|
||||
and sufficient to implement the intent of ZIP 1014.
|
||||
|
||||
The Zcash Development Fund distributes funding in ZEC obtained from block subsidies
|
||||
on Mainnet. This ZIP should also specify corresponding rules, addresses, and
|
||||
activation height for Testnet, in order to allow testing and auditing of the design
|
||||
and implementation within sufficient lead time before activation on Mainnet.
|
||||
|
||||
|
||||
Non-requirements
|
||||
================
|
||||
|
||||
This ZIP is not required to enforce provisions of ZIP 1014 that fall outside what
|
||||
is implementable by Zcash consensus rules.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
The Blossom network upgrade changed the height of the first halving to block height
|
||||
1046400 [#zip-0208]_, as a consequence of reducing the block target spacing from
|
||||
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.
|
||||
|
||||
ZIP 207 [#zip-0207]_ SHALL be activated in ${NU4}.
|
||||
|
||||
The following funding streams are defined for Mainnet:
|
||||
|
||||
========== =========== ============= ============== ============
|
||||
Stream Numerator Denominator Start height End height
|
||||
========== =========== ============= ============== ============
|
||||
``FS_ECC`` 7 100 1046400 2726400
|
||||
``FS_ZF`` 5 100 1046400 2726400
|
||||
``FS_MG`` 8 100 1046400 2726400
|
||||
========== =========== ============= ============== ============
|
||||
|
||||
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.
|
||||
|
||||
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 corresponding initial amount on Mainnet. This
|
||||
reduces to the same amount as on Mainnet, from Testnet block heights 1046400
|
||||
(inclusive) to 2726400 (exclusive).
|
||||
|
||||
|
||||
Dev Fund Recipient Addresses
|
||||
----------------------------
|
||||
|
||||
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 independent recipient addresses to be used for each
|
||||
stream in each funding period:
|
||||
|
||||
* ECC SHALL generate the addresses for the ``FS_ECC`` funding stream, which on
|
||||
Mainnet corresponds to the **ECC slice**;
|
||||
* ZF SHALL generate the addresses for the ``FS_ZF`` and ``FS_MG`` funding streams,
|
||||
which on Mainnet correspond to the **ZF slice** and **MG slice** respectively.
|
||||
|
||||
Funds sent to each Mainnet funding stream SHALL be governed by all requirements on
|
||||
the corresponding slice specified in ZIP 1014 [#zip-1014]_.
|
||||
|
||||
No requirements are imposed on the use of funds sent to Testnet funding streams.
|
||||
|
||||
|
||||
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
|
||||
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
|
||||
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 **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
|
||||
grantees, a separate ZIP would be published specifying those modifications.
|
||||
|
||||
|
||||
Mainnet Recipient Addresses
|
||||
---------------------------
|
||||
|
||||
FS_ECC_Addresses[0..47] = [
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO" ]
|
||||
|
||||
FS_ZF_Addresses[0..47] = [
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO" ]
|
||||
|
||||
FS_MG_Addresses[0..47] = [
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO",
|
||||
"TODO" ]
|
||||
|
||||
Testnet Recipient Addresses
|
||||
---------------------------
|
||||
|
||||
TODO
|
||||
|
||||
|
||||
Deployment
|
||||
==========
|
||||
|
||||
This proposal is intended to be deployed with ${NU4}. [#zip-0251]_
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
|
||||
.. [#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>`_
|
||||
.. [#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-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>ZIP 251: Deployment of the 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
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Draft
|
||||
Category: Consensus
|
||||
Created: 2020-02-28
|
||||
License: MIT</pre>
|
||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a 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">3</a></p>
|
||||
<p>The terms below are to be interpreted as follows:</p>
|
||||
<dl>
|
||||
<dt>${NU4}</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>
|
||||
<dt>Mainnet</dt>
|
||||
<dd>The Zcash production network, as defined in <a id="id4" class="footnote_reference" href="#protocol">2</a>.</dd>
|
||||
</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>
|
||||
</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>
|
||||
<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>
|
||||
<li>ZIP 207: Funding Streams <a id="id7" class="footnote_reference" href="#zip-0207">5</a></li>
|
||||
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="id8" class="footnote_reference" href="#zip-0214">6</a></li>
|
||||
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="id9" class="footnote_reference" href="#zip-1014">7</a></li>
|
||||
<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>
|
||||
<dl>
|
||||
<dt>BRANCH_ID</dt>
|
||||
<dd><code>0xTODO</code></dd>
|
||||
<dt>ACTIVATION_HEIGHT (${NU4})</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 three 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>
|
||||
<pre>/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</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>
|
||||
<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>
|
||||
</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 applicable. Unlike Overwinter and Sapling, and like Blossom, ${NU4} does not define a new transaction version. ${NU4} transactions are therefore in the same v4 format as Sapling transactions, and 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. This does not imply that transactions are valid across the ${NU4} activation, since signatures MUST use the appropriate consensus branch ID.</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 TODO, which will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented in <code>zcashd</code> version 3.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">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>1</th>
|
||||
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="protocol" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>2</th>
|
||||
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom]</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 Activation Mechanism</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0201" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>4</th>
|
||||
<td><a href="zip-0201">ZIP 201: Network Peer Management for Overwinter</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0207" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>5</th>
|
||||
<td><a href="zip-0208">ZIP 208: Shorter Block Target Spacing</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-0214" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>6</th>
|
||||
<td><a href="zip-0214">ZIP 214: Consensus rules for a Zcash Development Fund</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="zip-1014" class="footnote">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>7</th>
|
||||
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,134 @@
|
|||
::
|
||||
|
||||
ZIP: 251
|
||||
Title: Deployment of the ${NU4} Network Upgrade
|
||||
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||
Status: Draft
|
||||
Category: Consensus
|
||||
Created: 2020-02-28
|
||||
License: MIT
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
|
||||
interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as described in
|
||||
ZIP 200. [#zip-0200]_
|
||||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
${NU4}
|
||||
Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
|
||||
Testnet
|
||||
The Zcash test network, as defined in [#protocol]_.
|
||||
Mainnet
|
||||
The Zcash production network, as defined in [#protocol]_.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This proposal defines the deployment of the ${NU4} network upgrade.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
${NU4} deployment
|
||||
-----------------
|
||||
|
||||
The primary sources of information about ${NU4} consensus protocol changes are:
|
||||
|
||||
- The Zcash Protocol Specification [#protocol]_
|
||||
- ZIP 200: Network Upgrade Mechanism [#zip-0200]_
|
||||
- ZIP 207: Funding Streams [#zip-0207]_
|
||||
- ZIP 214: Consensus rules for a Zcash Development Fund [#zip-0214]_
|
||||
- ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants [#zip-1014]_
|
||||
- TODO: other ZIPs
|
||||
|
||||
The network handshake and peer management mechanisms defined in ZIP 201 [#zip-0201]_
|
||||
also apply to this upgrade.
|
||||
|
||||
|
||||
The following network upgrade constants [#zip-0200]_ are defined for the ${NU4}
|
||||
upgrade:
|
||||
|
||||
BRANCH_ID
|
||||
``0xTODO``
|
||||
|
||||
|
||||
ACTIVATION_HEIGHT (${NU4})
|
||||
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
|
||||
protocol version TODO or later. The minimum peer protocol version that
|
||||
${NU4}-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
|
||||
advertising a protocol version less than TODO.
|
||||
|
||||
For each network (testnet and mainnet), approximately three 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::
|
||||
|
||||
/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
|
||||
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
|
||||
|
||||
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:
|
||||
|
||||
- reject new connections from pre-${NU4} nodes on that network;
|
||||
- disconnect any existing connections to pre-${NU4} 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
|
||||
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
|
||||
will always disconnect peers using lower protocol versions.
|
||||
|
||||
TODO: delete if applicable.
|
||||
Unlike Overwinter and Sapling, and like Blossom, ${NU4} does not define a new
|
||||
transaction version. ${NU4} transactions are therefore in the same v4 format as
|
||||
Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as
|
||||
defined in [#protocol]_ section 7.1. This does not imply that transactions are
|
||||
valid across the ${NU4} activation, since signatures MUST use the appropriate
|
||||
consensus branch ID.
|
||||
|
||||
|
||||
Support in zcashd
|
||||
=================
|
||||
|
||||
Support for ${NU4} on testnet will be implemented in ``zcashd`` version TODO, which
|
||||
will advertise protocol version TODO. Support for ${NU4} on mainnet will be implemented
|
||||
in ``zcashd`` version 3.0.0, which will advertise protocol version TODO.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <zip-0201.rst>`_
|
||||
.. [#zip-0207] `ZIP 208: Shorter Block Target Spacing <zip-0208.rst>`_
|
||||
.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund <zip-0214.rst>`_
|
||||
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_
|
||||
Loading…
Reference in New Issue