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

ZIP 250: Add wording about transaction digest algorithm and reference ZIP 243. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-03-10 22:26:20 +00:00
parent 6a03fed583
commit 9641e2fc0b
2 changed files with 17 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
zip-0250.html
View File

@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<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, Heartwood and pre-Heartwood nodes are compatible and can connect to each other. However, Heartwood nodes will have a preference for connecting to other Heartwood nodes, so pre-Heartwood nodes will gradually be disconnected in the run up to activation.</p>
<p>Once the network upgrades, even though pre-Heartwood nodes can still accept the numerically larger protocol version used by Heartwood as being valid, Heartwood nodes will always disconnect peers using lower protocol versions.</p>
<p>Unlike Overwinter and Sapling, and like Blossom, Heartwood does not define a new transaction version. Heartwood 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="id12" class="footnote_reference" href="#protocol">2</a> section 7.1. This does not imply that transactions are valid across the Heartwood activation, since signatures MUST use the appropriate consensus branch ID.</p>
<p>Unlike Overwinter and Sapling, and like Blossom, Heartwood does not define a new transaction version. Heartwood 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="id12" class="footnote_reference" href="#protocol">2</a> section 7.1, and the same transaction digest algorithm as defined in <a id="id13" class="footnote_reference" href="#zip-0243">7</a>. This does not imply that transactions are valid across the Heartwood activation, since signatures MUST use the appropriate consensus branch ID. <a id="id14" 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 Heartwood on testnet will be implemented in <code>zcashd</code> version 2.1.3, which will advertise protocol version 170010. Support for Heartwood on mainnet will be implemented in <code>zcashd</code> version 2.2.0, which will advertise protocol version 170011.</p>
@ -83,7 +83,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom]</a></td>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1 or later</a></td>
</tr>
</tbody>
</table>
@ -119,6 +119,14 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;</pr
</tr>
</tbody>
</table>
<table id="zip-0243" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0243">ZIP 243: Transaction Signature Verification for Sapling</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>

12
zip-0250.rst
View File

@ -105,10 +105,11 @@ will always disconnect peers using lower protocol versions.
Unlike Overwinter and Sapling, and like Blossom, Heartwood does not define a new
transaction version. Heartwood 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 Heartwood activation, since signatures MUST use the appropriate
consensus branch ID.
Sapling transactions, use the same version group ID, i.e. 0x892F2085 as
defined in [#protocol]_ section 7.1, and the same transaction digest algorithm as
defined in [#zip-0243]_. This does not imply that transactions are valid across the
Heartwood activation, since signatures MUST use the appropriate consensus branch ID.
[#zip-0243]_
Support in zcashd
@ -124,8 +125,9 @@ References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
.. [#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-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_
.. [#zip-0221] `ZIP 221: FlyClient - Consensus-Layer Changes <zip-0221.rst>`_
.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling <zip-0243.rst>`_