diff --git a/zip-0239.html b/zip-0239.html index 042dbfdc..64fea7ec 100644 --- a/zip-0239.html +++ b/zip-0239.html @@ -43,7 +43,8 @@ Pull-Request: <https://githu

Note that MSG_WTX might also be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified for now.

MSG_TX and MSG_WTX entries may be mixed in arbitrary order in an inv message or a getdata message. Since these entry types are of different lengths (36 bytes or 68 bytes respectively including the 4-byte type field), this implies that the size of the message is not determined by its initial count field, and has to be determined by parsing the whole message.

Deployment

-

This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5. In 5, the minimum protocol version that signals support for NU5 on Testnet is defined to be 170014. Therefore, the peer protocol version that enables support for this specification is also defined to be 170014 (on both Testnet and Mainnet).

+

This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5.

+

The peer protocol version that enables support for this specification is defined to be 170014 (on both Testnet and Mainnet). This is in advance of the minimum protocol version that signals support for NU5 on Testnet, which is 170015. 7

As specified in 4, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the MSG_WTX inv type until it has received the block preceding the NU5 network upgrade.

Nevertheless, it is possible for a node to receive an inv or getdata message with a MSG_WTX inv type, on a peer connection that has negotiated protocol version 170014 or later, before NU5 has activated. The node MUST handle this case in the same way that it would after NU5 activation when it has no v5 transactions to relay. Receiving a MSG_WTX inv type on a peer connection that has negotiated a protocol version before 170014, on the other hand, SHOULD be treated as a protocol error.

As the MSG_WTX inv type is only enabled between peers that both support it, older clients remain fully compatible and interoperable before NU5 activates, or on a chain in which it does not activate.

diff --git a/zip-0239.rst b/zip-0239.rst index af909243..a3c234d2 100644 --- a/zip-0239.rst +++ b/zip-0239.rst @@ -118,10 +118,11 @@ Deployment ---------- This ZIP is assumed to be deployed in advance of the network upgrade that introduces -v5 transactions, i.e. NU5. In [#zip-0252]_, the minimum protocol version that signals -support for NU5 on Testnet is defined to be 170014. Therefore, the peer protocol -version that enables support for this specification is also defined to be 170014 -(on both Testnet and Mainnet). +v5 transactions, i.e. NU5. + +The peer protocol version that enables support for this specification is defined to +be 170014 (on both Testnet and Mainnet). This is in advance of the minimum protocol +version that signals support for NU5 on Testnet, which is 170015. [#zip-0252]_ As specified in [#zip-0200]_, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this diff --git a/zip-0252.html b/zip-0252.html index 846fcef5..89bfb9c2 100644 --- a/zip-0252.html +++ b/zip-0252.html @@ -28,58 +28,71 @@ Pull-Request: <https://githu

NU5 deployment

The primary sources of information about NU5 consensus and peer-to-peer protocol changes are:

+

The network handshake and peer management mechanisms defined in ZIP 201 8 also apply to this upgrade.

+

Unified addresses and viewing keys are described in ZIP 316 19.

+

The following ZIPs have been updated in varying degrees to take into account Orchard:

+ -

The network handshake and peer management mechanisms defined in ZIP 201 8 also apply to this upgrade. Unified addresses and viewing keys are described in ZIP 316 15. ZIP 32 5 has been amended to include hierarchical key derivation for Orchard.

Support for the addrv2 peer protocol message, defined in ZIP 155 [#zip-0155], is being added concurrently with this upgrade, signalled by the same Mainnet peer protocol version.

-

The following network upgrade constants 7 are defined for the NU5 upgrade:

+

The following network upgrade constants 7 are defined for the NU5 upgrade:

CONSENSUS_BRANCH_ID
-
0xF919A198
+
0x37519621 (this will change if a second Testnet activation occurs)
ACTIVATION_HEIGHT (NU5)
-

Testnet: TODO

+

Testnet: 1599200

+

Testnet (second activation): TODO

Mainnet: TODO

MIN_NETWORK_PROTOCOL_VERSION (NU5)
-

Testnet: 170014

-

Mainnet: 170015

+

Testnet: 170015

+

Testnet (second activation): 170016

+

Mainnet: 170017

-

For each network (Testnet and Mainnet), nodes compatible with NU5 activation on that network MUST advertise a network protocol version that is greater than or equal to that network's MIN_NETWORK_PROTOCOL_VERSION (NU5).

+

A second activation of NU5 on Testnet might or might not occur; if it does, then a reorganisation will occur to wipe out the original Testnet chain from height 1599200. In this case the CONSENSUS_BRANCH_ID will also change for the new Testnet epoch, and for Mainnet NU5 activation.

+

For each network (Testnet and Mainnet), nodes compatible with NU5 activation on that network MUST advertise a network protocol version that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU5) for that activation.

For each network, pre-NU5 nodes are defined as nodes advertising a protocol version less than that network's MIN_NETWORK_PROTOCOL_VERSION (NU5).

Once NU5 activates on Testnet or Mainnet, NU5 nodes SHOULD take steps to:

-

The change to the peer-to-peer protocol described in ZIP 239 takes effect from peer protocol version 170014 onward, on both Testnet and Mainnet. 13

-

The change to the peer-to-peer protocol described in ZIP 155 takes effect from peer protocol version 170015 onward, on both Testnet and Mainnet. 6

+

The change to the peer-to-peer protocol described in ZIP 239 takes effect from peer protocol version 170014 onward, on both Testnet and Mainnet. 17

+

The change to the peer-to-peer protocol described in ZIP 155 is currently proposed to take effect from peer protocol version 170017 onward, on both Testnet and Mainnet 6. This might be changed to version 170016 depending on scheduling constraints.

Note: these peer-to-peer protocol changes are enabled whenever the relevant version (or higher) is negotiated on a given connection, which can happen in advance of the Testnet or Mainnet NU5 activation.

Backward compatibility

Prior to the network upgrade activating on each network, NU5 and pre-NU5 nodes are compatible and can connect to each other.

Once the network upgrades, even though pre-NU5 nodes can still accept the numerically larger protocol version used by NU5 as being valid, NU5 nodes will always disconnect peers using lower protocol versions.

-

Unlike Blossom, Heartwood, and Canopy, and like Overwinter and Sapling, NU5 defines a new transaction version. Therefore, NU5 transactions MAY be in the new v5 format specified by 12. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.

-

Backward compatibility of the new MSG_WTX inv type introduced for inv and getdata messages is discussed in 13.

-

Backward compatibility of the new addrv2 message (not technically part of NU5) is discussed in 6.

+

Unlike Blossom, Heartwood, and Canopy, and like Overwinter and Sapling, NU5 defines a new transaction version. Therefore, NU5 transactions MAY be in the new v5 format specified by 16. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.

+

Backward compatibility of the new MSG_WTX inv type introduced for inv and getdata messages is discussed in 17.

+

Backward compatibility of the new addrv2 message (not technically part of NU5) is discussed in 6.

Support in zcashd

-

TODO: Update as needed

-

Support for NU5 on Testnet will be implemented in zcashd version 4.5.0, which will advertise protocol version 170014. Support for NU5 on Mainnet will be implemented in zcashd version 5.0.0, which will advertise protocol version 170015.

+

Support for NU5 on Testnet is implemented in zcashd version 4.5.1, which advertises protocol version 170015. (A previous revision of the NU5 consensus rules was implemented in zcashd version 4.5.0, but this revision contained critical bugs in the Orchard Action circuit. Before it could activate, zcashd version 4.5.1 was released, with the later NU5 Testnet activation height and consensus branch ID defined in this document.)

+

Support for NU5 on Mainnet will be implemented in zcashd version 5.0.0, which will advertise protocol version 170017.

Backward compatibility in zcashd

-

The minimum peer protocol version that NU5-compatible zcashd nodes will connect to is 170002.

+

The minimum peer protocol version that NU5-compatible zcashd nodes will connect to is 170002.

NU5 deployment for zcashd

For each network, approximately 1.5 days (defined in terms of block height) before the corresponding NU5 activation height, nodes compatible with NU5 activation on that network will change the behaviour of their peer connection logic in order to prefer pre-NU5 peers on that network for eviction from the set of peer connections:

@@ -88,13 +101,12 @@ Pull-Request: <https://githu * 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; -

The implementation is similar to that for Overwinter which was described in 8.

+

The implementation is similar to that for Overwinter which was described in 8.

However, NU5 nodes will have a preference for connecting to other NU5 nodes, so pre-NU5 nodes will gradually be disconnected in the run up to activation.

Support in Zebra

-

TODO: Update as needed

-

Support for NU5 on Testnet will be implemented in Zebra version 1.0.0, which will advertise protocol version 170014. Support for NU5 on Mainnet will be implemented in Zebra version 2.0.0, which will advertise protocol version 170015.

+

Partial support for NU5 on Testnet will be implemented in Zebra version 1.0.0-alpha.18, which will advertise protocol version 170015. This version will validate a strict subset of NU5 consensus rules on Testnet.

Backward compatibility in Zebra

The minimum peer protocol version that NU5-compatible Zebra nodes will connect to is 170002. However, Zebra will immediately disconnect from nodes with a protocol version less than: