Terminology 
- The key words "MUST", "MUST NOT", and "SHOULD" in this document are to be interpreted as described in RFC 2119. 1
+The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document are to be interpreted as described in RFC 2119. 1
The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 4
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 2.
The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in 6 for v5 and later transactions.
@@ -46,16 +46,26 @@ Pull-Request: <https://githuThis 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.
Nevertheless, it is possible for a node to receive an inv or getdata message containing an inventory entry of type MSG_WTX, 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.
Note that the behaviour of a node receiving an inv or getdata message with one or more inventory entries of an unrecognized type was previously unspecified. The behaviour of zcashd in such a case was to assume that the length of each inventory entry is 36 bytes (including the type field), regardless of the type. This would result in misparsing the inv or getdata message if the length of the corresponding inventory entry were not 36 bytes.
The RECOMMENDED behaviour is to parse the inv or getdata message completely, and reject the message if it contains any inventory entries of an unrecognized type. For a getdata message, the set of recognized inventory types, and corresponding entry lengths including the type field, is:
-
+
MSG_TX(36 bytes);
+ MSG_BLOCK(36 bytes);
+ MSG_FILTERED_BLOCK(36 bytes);
+ - [provided version 170014 or later has been negotiated]
MSG_WTX(68 bytes).
+
For an inv message, the set of recognized inventory types is the same, but the MSG_FILTERED_BLOCK type has no useful purpose. Senders of inv messages SHOULD NOT include MSG_FILTERED_BLOCK entries. In order to allow using the same parser for the two message types, a node receiving a MSG_FILTERED_BLOCK entry in an inv message SHOULD ignore it.
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.
Further information on how zcashd handles data propagation in the peer-to-peer network is given in 12.