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

Update activation heights, branch IDs, and references for Heartwood and Blossom. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-06-02 18:34:35 +01:00
parent 84f962e857
commit 3d8b0363c7
4 changed files with 60 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
zip-0250.html
View File

@ -42,11 +42,11 @@ License: MIT</pre>
<p>The following network upgrade constants <a id="id10" class="footnote_reference" href="#zip-0200">3</a> are defined for the Heartwood upgrade:</p>
<dl>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0xf5b9230b</code></dd>
<dd><code>0xF5B9230B</code></dd>
<dt>ACTIVATION_HEIGHT (Heartwood)</dt>
<dd>
<p>Testnet: 903800</p>
<p>Mainnet: TODO</p>
<p>Mainnet: 903000</p>
</dd>
</dl>
<p>Nodes compatible with Heartwood activation on testnet MUST advertise protocol version 170010 or later. Nodes compatible with Heartwood activation on mainnet MUST advertise protocol version 170011 or later. The minimum peer protocol version that Heartwood-compatible nodes will connect to is 170002.</p>

4
zip-0250.rst
View File

@ -55,13 +55,13 @@ The following network upgrade constants [#zip-0200]_ are defined for the Heartwo
upgrade:
CONSENSUS_BRANCH_ID
``0xf5b9230b``
``0xF5B9230B``
ACTIVATION_HEIGHT (Heartwood)
Testnet: 903800
Mainnet: TODO
Mainnet: 903000
Nodes compatible with Heartwood activation on testnet MUST advertise protocol version

56
zip-0251.html
View File

@ -36,30 +36,32 @@ License: MIT</pre>
<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">8</a></li>
<li>TODO: other ZIPs</li>
<li>ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <a id="id8" class="footnote_reference" href="#zip-0211">6</a></li>
<li>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <a id="id9" class="footnote_reference" href="#zip-0212">7</a></li>
<li>ZIP 214: Consensus rules for a Zcash Development Fund <a id="id10" class="footnote_reference" href="#zip-0214">8</a></li>
<li>ZIP 215: Modifying Ed25519 validation rules to allow batch verification <a id="id11" class="footnote_reference" href="#zip-0215">9</a></li>
<li>ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <a id="id12" class="footnote_reference" href="#zip-1014">11</a>.</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 Canopy upgrade:</p>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id13" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id14" 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>
<dd><code>0xE9FF75A6</code></dd>
<dt>ACTIVATION_HEIGHT (Canopy)</dt>
<dd>
<p>Testnet: TODO</p>
<p>Mainnet: 1046400</p>
</dd>
</dl>
<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>Nodes compatible with Canopy activation on testnet MUST advertise protocol version 170012 or later. Nodes compatible with Canopy activation on mainnet MUST advertise protocol version 170013 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 170012. Pre-Canopy mainnet nodes are defined as nodes on mainnet advertising a protocol version less than 170013.</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>The implementation is similar to that for Overwinter which was described in <a id="id15" class="footnote_reference" href="#zip-0201">4</a>.</p>
<p>Once Canopy activates on testnet or mainnet, Canopy nodes SHOULD take steps to:</p>
<ul>
<li>reject new connections from pre-Canopy nodes on that network;</li>
@ -70,17 +72,17 @@ 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 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>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>
<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="id16" class="footnote_reference" href="#protocol">2</a> section 7.1; and use the same transaction digest algorithm as defined in <a id="id17" class="footnote_reference" href="#zip-0243">10</a>. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. <a id="id18" class="footnote_reference" href="#zip-0243">10</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 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>
<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>
</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>
<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>
@ -116,18 +118,42 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
</tr>
</tbody>
</table>
<table id="zip-0214" class="footnote">
<table id="zip-0211" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0211">ZIP 211: Disabling Addition of New Value to the Sprout Value Pool</a></td>
</tr>
</tbody>
</table>
<table id="zip-0212" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0212">ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td>
</tr>
</tbody>
</table>
<table id="zip-0214" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="zip-0214">ZIP 214: Consensus rules for a Zcash Development Fund</a></td>
</tr>
</tbody>
</table>
<table id="zip-0215" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="https://github.com/zcash/zips/pull/355">Draft ZIP 215: Modifying Ed25519 validation rules to allow batch verification</a></td>
</tr>
</tbody>
</table>
<table id="zip-0243" class="footnote">
<tbody>
<tr>
<th>7</th>
<th>10</th>
<td><a href="zip-0243">ZIP 243: Transaction Signature Verification for Sapling</a></td>
</tr>
</tbody>
@ -135,7 +161,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;</pre>
<table id="zip-1014" class="footnote">
<tbody>
<tr>
<th>8</th>
<th>11</th>
<td><a href="zip-1014">ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants</a></td>
</tr>
</tbody>

26
zip-0251.rst
View File

@ -45,9 +45,11 @@ The primary sources of information about Canopy consensus protocol changes are:
- The Zcash Protocol Specification [#protocol]_
- ZIP 200: Network Upgrade Mechanism [#zip-0200]_
- ZIP 207: Funding Streams [#zip-0207]_
- ZIP 211: Disabling Addition of New Value to the Sprout Value Pool [#zip-0211]_
- ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext [#zip-0212]_
- 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
- ZIP 215: Modifying Ed25519 validation rules to allow batch verification [#zip-0215]_
- ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants [#zip-1014]_.
The network handshake and peer management mechanisms defined in ZIP 201 [#zip-0201]_
also apply to this upgrade.
@ -57,7 +59,7 @@ The following network upgrade constants [#zip-0200]_ are defined for the Canopy
upgrade:
CONSENSUS_BRANCH_ID
``0xTODO``
``0xE9FF75A6``
ACTIVATION_HEIGHT (Canopy)
@ -67,13 +69,13 @@ ACTIVATION_HEIGHT (Canopy)
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
170012 or later. Nodes compatible with Canopy activation on mainnet MUST advertise
protocol version 170013 or later. The minimum peer protocol version that
Canopy-compatible nodes will connect to is 170002.
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.
version less than 170012. Pre-Canopy mainnet nodes are defined as nodes on mainnet
advertising a protocol version less than 170013.
For each network (testnet and mainnet), approximately 1.5 days (defined in terms of
block height) before the corresponding Canopy activation height, nodes compatible
@ -108,7 +110,6 @@ 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, 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
@ -122,18 +123,21 @@ Support in zcashd
=================
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.
will advertise protocol version 170012. Support for Canopy on mainnet will be implemented
in ``zcashd`` version 4.0.0, which will advertise protocol version 170013.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#RFC2119] `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.1 or later <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-0211] `ZIP 211: Disabling Addition of New Value to the Sprout Value Pool <zip-0211.rst>`_
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
.. [#zip-0214] `ZIP 214: Consensus rules for a Zcash Development Fund <zip-0214.rst>`_
.. [#zip-0215] `Draft ZIP 215: Modifying Ed25519 validation rules to allow batch verification <https://github.com/zcash/zips/pull/355>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling <zip-0243.rst>`_
.. [#zip-1014] `ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants <zip-1014.rst>`_