Terminology

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "RECOMMENDED" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

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.

The term "authorizing data commitment" (denoted auth_digest), defined only for v5 and later transactions, is to be interpreted as described in 6.

The term "witnessed transaction identifier" ("wtxid"), defined only for v5 and later transactions, is a 64-byte value given by concatenating the txid and the authorizing data commitment of the transaction.

Abstract

This ZIP describes changes to the Zcash peer-to-peer protocol to support transaction relay based on a transaction's authorizing data commitment as well as its txid.

Motivation

Historically, as in Bitcoin, the inv and getdata messages sent on the Zcash peer-to-peer network to announce or request transactions have referred to those transactions by txid.

Prior to the introduction of v5 transactions 5 in the NU5 network upgrade 7, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.

For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data 6. Witness data is committed to by a separate "authorizing data commitment". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.

Not committing to the witness data in v5 transaction announcements would create inefficiencies: because a v5 transaction's witness can be malleated without altering the txid, a node in receipt of a v5 transaction that the node does not accept would generally still have to download that same transaction when announced by other peers. This is because the alternative — of not downloading a v5 transaction with a given txid after rejecting a previous transaction with that txid — would allow a third party to interfere with transaction relay by malleating a transaction's witness and announcing the resulting invalid transaction to nodes, preventing relay of the valid version of the transaction as well.

This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade 8, until the adoption of BIP 339 9. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is also called the wtxid, but it encodes the pair (txid, auth_digest).

This ZIP is modelled after BIP 339: it adds a MSG_WTX inv type to the peer-to-peer protocol, analogous to BIP 339's MSG_WTX inv type, that announces transactions by their wtxid. Note that the encoding and length of a Zcash wtxid is different to that of a Bitcoin wtxid.

This ZIP does not introduce any equivalent of BIP 339's wtxidrelay message, since that is not needed for compatibility given that Zcash full nodes are required to support MSG_WTX based on the negotiated peer protocol version (see Deployment).

Specification

A new inv type MSG_WTX (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is the wtxid (i.e. the 64-byte value txid || auth_digest). This inv type MUST be used when announcing v5 transactions. The txid and auth_digest are as defined in 6.

In the case of getdata requests, the format of a v5 transaction obtained by a MSG_WTX inv type is as given in the Zcash protocol specification. 3

An inv or getdata message MUST NOT use the MSG_WTX inv type for v4 or earlier transactions, or on peer connections that have not negotiated at least the peer protocol version specified in Deployment.

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.

Rationale

A previous draft of this ZIP left as an open question whether to redefine inv and getdata to segregate MSG_TX and MSG_WTX. This could potentially have made these messages simpler or more efficient to parse, by avoiding variable-length entries in the message data. (See 10 and 11 for how inv and getdata respectively are currently defined in Bitcoin.)

This option was rejected because the current specification is simple enough.

Acknowledgements

This ZIP is partly based on BIP 339, written by Suhas Daftuar. 9

References