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;
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 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.
7 | +ZIP 243: Transaction Signature Verification for Sapling | +
---|