diff --git a/zip-0250.html b/zip-0250.html index 39a554a9..cf03c28c 100644 --- a/zip-0250.html +++ b/zip-0250.html @@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;

Backward compatibility

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.

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.

-

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 2 section 7.1. This does not imply that transactions are valid across the Heartwood activation, since signatures MUST use the appropriate consensus branch ID.

+

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 2 section 7.1, and the same transaction digest algorithm as defined in 7. This does not imply that transactions are valid across the Heartwood activation, since signatures MUST use the appropriate consensus branch ID. 7

Support in zcashd

Support for Heartwood on testnet will be implemented in zcashd version 2.1.3, which will advertise protocol version 170010. Support for Heartwood on mainnet will be implemented in zcashd version 2.2.0, which will advertise protocol version 170011.

@@ -83,7 +83,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; 2 - Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] + Zcash Protocol Specification, Version 2020.1.1 or later @@ -119,6 +119,14 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; + + + + + + + +
7ZIP 243: Transaction Signature Verification for Sapling
diff --git a/zip-0250.rst b/zip-0250.rst index fe0fc24f..88ef0918 100644 --- a/zip-0250.rst +++ b/zip-0250.rst @@ -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 `_ -.. [#protocol] `Zcash Protocol Specification, Version 2019.0.4 or later [Overwinter+Sapling+Blossom] `_ +.. [#protocol] `Zcash Protocol Specification, Version 2020.1.1 or later `_ .. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0213] `ZIP 213: Shielded Coinbase `_ .. [#zip-0221] `ZIP 221: FlyClient - Consensus-Layer Changes `_ +.. [#zip-0243] `ZIP 243: Transaction Signature Verification for Sapling `_