From 16f48e70d24237e8db0443fefe3d22af904db9eb Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sat, 29 May 2021 17:50:53 +0100 Subject: [PATCH 1/6] Add ZIP 239. Signed-off-by: Daira Hopwood --- README.rst | 2 + README.template | 1 + index.html | 2 + zip-0239.html | 148 +++++++++++++++++++++++++++++++++++++++++++ zip-0239.rst | 162 ++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 315 insertions(+) create mode 100644 zip-0239.html create mode 100644 zip-0239.rst diff --git a/README.rst b/README.rst index 6de30106..96108da1 100644 --- a/README.rst +++ b/README.rst @@ -50,6 +50,7 @@ is planned to activate on Mainnet at the beginning of October 2021: - `ZIP 221: FlyClient - Consensus-Layer Changes `__ (updated) - `ZIP 224: Orchard Shielded Protocol `__ - `ZIP 225: Version 5 Transaction Format `__ +- `ZIP 239: Relay of Version 5 Transactions `__ - `ZIP 244: Transaction Identifier Non-Malleability `__ - `ZIP 252: Deployment of the NU5 Network Upgrade `__ - `ZIP 316: Unified Addresses and Unified Viewing Keys `__ @@ -101,6 +102,7 @@ Index of ZIPs 222 Transparent Zcash Extensions Draft 224 Orchard Shielded Protocol Proposed 225 Version 5 Transaction Format Proposed + 239 Relay of Version 5 Transactions Proposed 243 Transaction Signature Validation for Sapling Final 244 Transaction Identifier Non-Malleability Proposed 245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft diff --git a/README.template b/README.template index 7bf02ff3..c6e0cfa0 100644 --- a/README.template +++ b/README.template @@ -50,6 +50,7 @@ is planned to activate on Mainnet at the beginning of October 2021: - `ZIP 221: FlyClient - Consensus-Layer Changes `__ (updated) - `ZIP 224: Orchard Shielded Protocol `__ - `ZIP 225: Version 5 Transaction Format `__ +- `ZIP 239: Relay of Version 5 Transactions `__ - `ZIP 244: Transaction Identifier Non-Malleability `__ - `ZIP 252: Deployment of the NU5 Network Upgrade `__ - `ZIP 316: Unified Addresses and Unified Viewing Keys `__ diff --git a/index.html b/index.html index bed71657..3974051b 100644 --- a/index.html +++ b/index.html @@ -32,6 +32,7 @@
  • ZIP 221: FlyClient - Consensus-Layer Changes (updated)
  • ZIP 224: Orchard Shielded Protocol
  • ZIP 225: Version 5 Transaction Format
    • +
  • ZIP 239: Relay of Version 5 Transactions
  • ZIP 244: Transaction Identifier Non-Malleability
  • ZIP 252: Deployment of the NU5 Network Upgrade
  • ZIP 316: Unified Addresses and Unified Viewing Keys
    • @@ -74,6 +75,7 @@ 222 Transparent Zcash Extensions Draft 224 Orchard Shielded Protocol Proposed 225 Version 5 Transaction Format Proposed + 239 Relay of Version 5 Transactions Proposed 243 Transaction Signature Validation for Sapling Final 244 Transaction Identifier Non-Malleability Proposed 245 Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions Draft diff --git a/zip-0239.html b/zip-0239.html new file mode 100644 index 00000000..fc37b473 --- /dev/null +++ b/zip-0239.html @@ -0,0 +1,148 @@ + + + + ZIP 239: Relay of Version 5 Transactions + + + +
    + 
    ZIP: 239
+Title: Relay of Version 5 Transactions
+Owners: Daira Hopwood <daira@electriccoin.co>
+        Jack Grigg <jack@electriccoin.co>
+Status: Proposed
+Category: Network
+Created: 2021-05-29
+License: MIT
+Discussions-To: <https://github.com/zcash/zips/issues/515>
+Pull-Request: <https://github.com/zcash/zips/pull/516>
    +

    Terminology

    +

    The key words "MUST", "MUST NOT", and "SHOULD" 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. 2

    +

    The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification 6.

    +

    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 4 for v5 and later transactions.

    +
    +

    Abstract

    +

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

    +
    +

    Motivation

    +

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

    +

    Prior to the introduction of v5 transactions 3 in the NU5 network upgrade 5, 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 4. Witness data is committed to by a separate "authorizing digest".

    +

    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 the pair (txid, auth_digest).

    +

    This ZIP is modelled after BIP 339: it adds a MSG_TXV5 message type to the peer-to-peer protocol, analogous to BIP 339's MSG_WTX message type, that announces transactions by their (txid, auth_digest) pair. It 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_TXV5 based on the negotiated peer protocol version (see Deployment).

    +
    +

    Specification

    +

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

    +

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

    +

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

    +

    Note that the name MSG_TXV5 does not imply that this inv type cannot be used for future transaction versions after v5. New inv types might be added for future transaction versions, but only as needed.

    +

    MSG_TX and MSG_TXV5 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.

    +

    Open issue:

    +
      +
    • Should we redefine inv and getdata to segregate MSG_TX and MSG_TXV5, making these messages simpler / more efficient to parse? This could be done by adding new inv5 and getdata5 messages. See 10 and 11 for how inv and getdata respectively are currently defined in Bitcoin.
      • +
    +

    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).

    +

    As specified in 2, 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_TXV5 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_TXV5 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_TXV5 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_TXV5 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.

    +
    +
    +

    Acknowledgements

    +

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

    +
    +

    References

    + + + + + + + +
    1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
    + + + + + + + +
    2ZIP 200: Network Upgrade Activation Mechanism
    + + + + + + + +
    3ZIP 225: Version 5 Transaction Format
    + + + + + + + +
    4ZIP 244: Transaction Identifier Non-Malleability
    + + + + + + + +
    5ZIP 252: Deployment of the NU5 Network Upgrade
    + + + + + + + +
    6Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 3.12 Mainnet and Testnet
    + + + + + + + +
    7Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus
    + + + + + + + +
    8BIP 141: Segregated Witness (Consensus layer)
    + + + + + + + +
    9BIP 339: WTXID-based transaction relay
    + + + + + + + +
    10Bitcoin Developer Reference: P2P Network — Inv
    + + + + + + + +
    11Bitcoin Developer Reference: P2P Network — GetData
    +
    +
    + + \ No newline at end of file diff --git a/zip-0239.rst b/zip-0239.rst new file mode 100644 index 00000000..43f4f67b --- /dev/null +++ b/zip-0239.rst @@ -0,0 +1,162 @@ +:: + + ZIP: 239 + Title: Relay of Version 5 Transactions + Owners: Daira Hopwood + Jack Grigg + Status: Proposed + Category: Network + Created: 2021-05-29 + License: MIT + Discussions-To: + Pull-Request: + + +Terminology +=========== + +The key words "MUST", "MUST NOT", and "SHOULD" in this document are to be interpreted +as described in RFC 2119. [#RFC2119]_ + +The term "network upgrade" in this document is to be interpreted as described in +ZIP 200. [#zip-0200]_ + +The terms "Testnet" and "Mainnet" are to be interpreted as described in +section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. + +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 [#zip-0244]_ +for v5 and later transactions. + + +Abstract +======== + +This ZIP describes changes to the Zcash peer-to-peer protocol to support transaction +relay based on a transaction's authorizing digest as well as its txid. + + +Motivation +========== + +Historically, as in Bitcoin, the ``inv`` messages sent on the Zcash peer-to-peer +network to announce transactions have referred to those transactions by their txid. + +Prior to the introduction of v5 transactions [#zip-0225]_ in the NU5 network upgrade +[#zip-0252]_, 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 [#zip-0244]_. +Witness data is committed to by a separate "authorizing digest". + +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 [#bip-0141]_, until the adoption of BIP 339 [#bip-0339]_. 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 the pair (txid, auth_digest). + +This ZIP is modelled after BIP 339: it adds a ``MSG_TXV5`` message type to the +peer-to-peer protocol, analogous to BIP 339's ``MSG_WTX`` message type, that announces +transactions by their (txid, auth_digest) pair. It 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_TXV5`` based on the negotiated +peer protocol version (see `Deployment`_). + + +Specification +============= + +A new inv type ``MSG_TXV5`` (0x00000005) is added, for use in both ``inv`` messages +and ``getdata`` requests, indicating that the hash being referenced is the 64-byte +value ``txid`` || ``auth_digest``. This inv type MUST be used when announcing v5 +transactions, and only for such transactions. The ``txid`` and ``auth_digest`` are +as defined in [#zip-0244]_. + +In the case of ``getdata`` requests, the format of a v5 transaction obtained by a +``MSG_TXV5`` inv type is as given in the Zcash protocol specification. +[#protocol-txnencodingandconsensus]_ + +An ``inv`` or ``getdata`` message MUST NOT use the ``MSG_TXV5`` inv type for v4 +transactions, or on peer connections that have not negotiated at least the peer +protocol version specified in `Deployment`_. + +Note that the name ``MSG_TXV5`` does not imply that this inv type cannot be used +for future transaction versions after v5. New inv types might be added for future +transaction versions, but only as needed. + +``MSG_TX`` and ``MSG_TXV5`` 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. + +**Open issue:** + +* Should we redefine ``inv`` and ``getdata`` to segregate ``MSG_TX`` + and ``MSG_TXV5``, making these messages simpler / more efficient to parse? + This could be done by adding new ``inv5`` and ``getdata5`` messages. + See [#p2p-inv]_ and [#p2p-getdata]_ for how ``inv`` and ``getdata`` + respectively are currently defined in Bitcoin. + + +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). + +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 +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_TXV5`` 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_TXV5`` 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_TXV5`` 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_TXV5`` 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. + + +Acknowledgements +================ + +This ZIP is partly based on BIP 339, written by Suhas Daftuar. [#bip-0339]_ + + +References +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ +.. [#zip-0225] `ZIP 225: Version 5 Transaction Format `_ +.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ +.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 3.12 Mainnet and Testnet `_ +.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ +.. [#bip-0141] `BIP 141: Segregated Witness (Consensus layer) `_ +.. [#bip-0339] `BIP 339: WTXID-based transaction relay `_ +.. [#p2p-inv] `Bitcoin Developer Reference: P2P Network — Inv `_ +.. [#p2p-getdata] `Bitcoin Developer Reference: P2P Network — GetData `_ From a756260c051d40138d147ca75663e6d4a193778b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sat, 29 May 2021 17:55:45 +0100 Subject: [PATCH 2/6] ZIP 239: mention `getdata` in Motivation. Signed-off-by: Daira Hopwood --- zip-0239.html | 2 +- zip-0239.rst | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/zip-0239.html b/zip-0239.html index fc37b473..9168bffc 100644 --- a/zip-0239.html +++ b/zip-0239.html @@ -26,7 +26,7 @@ Pull-Request: <https://githu

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

    Motivation

    -

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

    +

    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 3 in the NU5 network upgrade 5, 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 4. Witness data is committed to by a separate "authorizing digest".

    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.

    diff --git a/zip-0239.rst b/zip-0239.rst index 43f4f67b..79642406 100644 --- a/zip-0239.rst +++ b/zip-0239.rst @@ -39,8 +39,9 @@ relay based on a transaction's authorizing digest as well as its txid. Motivation ========== -Historically, as in Bitcoin, the ``inv`` messages sent on the Zcash peer-to-peer -network to announce transactions have referred to those transactions by their txid. +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 [#zip-0225]_ in the NU5 network upgrade [#zip-0252]_, a txid was always defined as the SHA-256d hash of the transaction data, From 50e4914b01bae9bb31bf58ee9079a9b510a8b097 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sat, 29 May 2021 18:01:01 +0100 Subject: [PATCH 3/6] ZIP 239: message type -> inv type. Signed-off-by: Daira Hopwood --- zip-0239.html | 2 +- zip-0239.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/zip-0239.html b/zip-0239.html index 9168bffc..c0d7f1ab 100644 --- a/zip-0239.html +++ b/zip-0239.html @@ -31,7 +31,7 @@ Pull-Request: <https://githu

    For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data 4. Witness data is committed to by a separate "authorizing digest".

    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 the pair (txid, auth_digest).

    -

    This ZIP is modelled after BIP 339: it adds a MSG_TXV5 message type to the peer-to-peer protocol, analogous to BIP 339's MSG_WTX message type, that announces transactions by their (txid, auth_digest) pair. It 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_TXV5 based on the negotiated peer protocol version (see Deployment).

    +

    This ZIP is modelled after BIP 339: it adds a MSG_TXV5 inv type to the peer-to-peer protocol, analogous to BIP 339's MSG_WTX inv type, that announces transactions by their (txid, auth_digest) pair. It 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_TXV5 based on the negotiated peer protocol version (see Deployment).

    Specification

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

    diff --git a/zip-0239.rst b/zip-0239.rst index 79642406..832cd4a0 100644 --- a/zip-0239.rst +++ b/zip-0239.rst @@ -67,8 +67,8 @@ BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting a witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is the pair (txid, auth_digest). -This ZIP is modelled after BIP 339: it adds a ``MSG_TXV5`` message type to the -peer-to-peer protocol, analogous to BIP 339's ``MSG_WTX`` message type, that announces +This ZIP is modelled after BIP 339: it adds a ``MSG_TXV5`` inv type to the +peer-to-peer protocol, analogous to BIP 339's ``MSG_WTX`` inv type, that announces transactions by their (txid, auth_digest) pair. It 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_TXV5`` based on the negotiated From 864e1eaa8d675217b242aac81575d5ce3ab972a4 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sat, 29 May 2021 18:25:13 +0100 Subject: [PATCH 4/6] ZIP 252: add references to ZIP 239. Signed-off-by: Daira Hopwood --- zip-0252.html | 34 ++++++++++++++++++++++------------ zip-0252.rst | 8 +++++++- 2 files changed, 29 insertions(+), 13 deletions(-) diff --git a/zip-0252.html b/zip-0252.html index 5e48acf7..ccf96737 100644 --- a/zip-0252.html +++ b/zip-0252.html @@ -26,7 +26,7 @@ Pull-Request: <https://githu

    Specification

    NU5 deployment

    -

    The primary sources of information about NU5 consensus protocol changes are:

    +

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

    • The Zcash Protocol Specification 2
    • ZIP 200: Network Upgrade Mechanism 5
      • @@ -34,12 +34,13 @@ Pull-Request: <https://githu
    • ZIP 221: FlyClient - Consensus-Layer Changes 8 (amended)
    • ZIP 224: Orchard Shielded Protocol 9
    • ZIP 225: Version 5 Transaction Format 10
      • -
    • ZIP 244: Transaction Identifier Non-Malleability 11
      • -
    • The Orchard Book 13
      • -
    • The halo2 Book 14
      • +
    • ZIP 239: Relay of Version 5 Transactions 11
      • +
    • ZIP 244: Transaction Identifier Non-Malleability 12
      • +
    • The Orchard Book 14
      • +
    • The halo2 Book 15
    -

    The network handshake and peer management mechanisms defined in ZIP 201 6 also apply to this upgrade. Unified addresses and viewing keys are described in ZIP 316 12.

    -

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

    +

    The network handshake and peer management mechanisms defined in ZIP 201 6 also apply to this upgrade. Unified addresses and viewing keys are described in ZIP 316 13.

    +

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

    CONSENSUS_BRANCH_ID
    0xF919A198
    @@ -61,12 +62,13 @@ Pull-Request: <https://githu
  • reject new connections from pre-NU5 nodes on that network;
  • disconnect any existing connections to pre-NU5 nodes on that network.
    • +

    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. 11

    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 10. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.

    +

    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 10. Unlike previous transaction version updates, the existing v4 transaction format remains valid after NU5 activation. Both transaction formats MUST be accepted by NU5 nodes.

    Support in zcashd

    TODO: Update as needed

    @@ -81,7 +83,7 @@ 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 6.

    +

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

    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.

    @@ -181,10 +183,18 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; - +
    + + + +
    11ZIP 239: Relay of Version 5 Transactions
    + + + + @@ -192,7 +202,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;
    12 ZIP 244: Transaction Identifier Non-Malleability
    - + @@ -200,7 +210,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;
    1213 ZIP 316: Unified Addresses and Unified Viewing Keys
    - + @@ -208,7 +218,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;
    1314 The Orchard Book
    - + diff --git a/zip-0252.rst b/zip-0252.rst index 156539a1..636ad9ff 100644 --- a/zip-0252.rst +++ b/zip-0252.rst @@ -37,7 +37,8 @@ Specification NU5 deployment -------------- -The primary sources of information about NU5 consensus protocol changes are: +The primary sources of information about NU5 consensus and peer-to-peer protocol +changes are: - The Zcash Protocol Specification [#protocol]_ - ZIP 200: Network Upgrade Mechanism [#zip-0200]_ @@ -45,6 +46,7 @@ The primary sources of information about NU5 consensus protocol changes are: - ZIP 221: FlyClient - Consensus-Layer Changes [#zip-0221]_ (amended) - ZIP 224: Orchard Shielded Protocol [#zip-0224]_ - ZIP 225: Version 5 Transaction Format [#zip-0225]_ +- ZIP 239: Relay of Version 5 Transactions [#zip-0239]_ - ZIP 244: Transaction Identifier Non-Malleability [#zip-0244]_ - The Orchard Book [#orchard-book]_ - The halo2 Book [#halo2-book]_ @@ -85,6 +87,9 @@ Once NU5 activates on testnet or mainnet, NU5 nodes SHOULD take steps to: - reject new connections from pre-NU5 nodes on that network; - disconnect any existing connections to pre-NU5 nodes on that network. +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. [#zip-0239]_ + Backward compatibility ====================== @@ -187,6 +192,7 @@ References .. [#zip-0221] `ZIP 221: FlyClient - Consensus-Layer Changes `_ .. [#zip-0224] `ZIP 224: Orchard Shielded Protocol `_ .. [#zip-0225] `ZIP 225: Version 5 Transaction Format `_ +.. [#zip-0239] `ZIP 239: Relay of Version 5 Transactions `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ .. [#zip-0316] `ZIP 316: Unified Addresses and Unified Viewing Keys `_ .. [#orchard-book] `The Orchard Book `_ From 1b5786ea38a36fe760cb1f1c99e678f01c85b1c1 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 30 May 2021 10:51:16 +0100 Subject: [PATCH 5/6] Leave it unspecified whether MSG_TXV5 is used for v6 and later transactions. The previous wording could have been misinterpreted to require not using MSG_TXV5 for these, and was partly redundant. Also mention in Motivation that the format of serialized v5 transactions is not consensus-critical. Signed-off-by: Daira Hopwood --- zip-0239.html | 8 ++++---- zip-0239.rst | 16 +++++++++------- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/zip-0239.html b/zip-0239.html index c0d7f1ab..455fda9d 100644 --- a/zip-0239.html +++ b/zip-0239.html @@ -28,16 +28,16 @@ Pull-Request: <https://githu

    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 3 in the NU5 network upgrade 5, 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 4. Witness data is committed to by a separate "authorizing digest".

    +

    For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data 4. Witness data is committed to by a separate "authorizing digest". 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 the pair (txid, auth_digest).

    This ZIP is modelled after BIP 339: it adds a MSG_TXV5 inv type to the peer-to-peer protocol, analogous to BIP 339's MSG_WTX inv type, that announces transactions by their (txid, auth_digest) pair. It 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_TXV5 based on the negotiated peer protocol version (see Deployment).

    Specification

    -

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

    +

    A new inv type MSG_TXV5 (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is 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 4.

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

    -

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

    -

    Note that the name MSG_TXV5 does not imply that this inv type cannot be used for future transaction versions after v5. New inv types might be added for future transaction versions, but only as needed.

    +

    An inv or getdata message MUST NOT use the MSG_TXV5 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 the name MSG_TXV5 does not imply that this inv type will not be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified. New inv types might be added for future transaction versions, but only as needed.

    MSG_TX and MSG_TXV5 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.

    Open issue:

      diff --git a/zip-0239.rst b/zip-0239.rst index 832cd4a0..4db9ca3c 100644 --- a/zip-0239.rst +++ b/zip-0239.rst @@ -49,7 +49,9 @@ 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 [#zip-0244]_. -Witness data is committed to by a separate "authorizing digest". +Witness data is committed to by a separate "authorizing digest". 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 @@ -81,19 +83,19 @@ Specification A new inv type ``MSG_TXV5`` (0x00000005) is added, for use in both ``inv`` messages and ``getdata`` requests, indicating that the hash being referenced is the 64-byte value ``txid`` || ``auth_digest``. This inv type MUST be used when announcing v5 -transactions, and only for such transactions. The ``txid`` and ``auth_digest`` are -as defined in [#zip-0244]_. +transactions. The ``txid`` and ``auth_digest`` are as defined in [#zip-0244]_. In the case of ``getdata`` requests, the format of a v5 transaction obtained by a ``MSG_TXV5`` inv type is as given in the Zcash protocol specification. [#protocol-txnencodingandconsensus]_ An ``inv`` or ``getdata`` message MUST NOT use the ``MSG_TXV5`` inv type for v4 -transactions, or on peer connections that have not negotiated at least the peer -protocol version specified in `Deployment`_. +or earlier transactions, or on peer connections that have not negotiated at least +the peer protocol version specified in `Deployment`_. -Note that the name ``MSG_TXV5`` does not imply that this inv type cannot be used -for future transaction versions after v5. New inv types might be added for future +Note that the name ``MSG_TXV5`` does not imply that this inv type will not be used +for future transaction versions after v5. Since such versions are not currently +consensus-valid, this is left unspecified. New inv types might be added for future transaction versions, but only as needed. ``MSG_TX`` and ``MSG_TXV5`` entries may be mixed in arbitrary order in an ``inv`` From f15f263023bff7020d32a3a6fee1d98ff5b599d5 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 1 Jun 2021 17:01:02 +0100 Subject: [PATCH 6/6] Add definitions; terminology changes; and rename `MSG_TXV5` to `MSG_WTX`. Signed-off-by: Daira Hopwood --- zip-0239.html | 35 ++++++++++++++------------- zip-0239.rst | 66 +++++++++++++++++++++++++++++---------------------- 2 files changed, 57 insertions(+), 44 deletions(-) diff --git a/zip-0239.html b/zip-0239.html index 455fda9d..6d4aa7a3 100644 --- a/zip-0239.html +++ b/zip-0239.html @@ -21,37 +21,40 @@ Pull-Request: <https://githu

      The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 2

      The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification 6.

      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 4 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 4.

      +

      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 digest as well as its txid.

    +

    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 3 in the NU5 network upgrade 5, 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 4. Witness data is committed to by a separate "authorizing digest". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.

    +

    Prior to the introduction of v5 transactions 3 in the NU5 network upgrade 5, 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 4. 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 the pair (txid, auth_digest).

    -

    This ZIP is modelled after BIP 339: it adds a MSG_TXV5 inv type to the peer-to-peer protocol, analogous to BIP 339's MSG_WTX inv type, that announces transactions by their (txid, auth_digest) pair. It 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_TXV5 based on the negotiated peer protocol version (see Deployment).

    +

    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_TXV5 (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is 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 4.

    -

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

    -

    An inv or getdata message MUST NOT use the MSG_TXV5 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 the name MSG_TXV5 does not imply that this inv type will not be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified. New inv types might be added for future transaction versions, but only as needed.

    -

    MSG_TX and MSG_TXV5 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.

    +

    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 4.

    +

    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. 7

    +

    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.

    Open issue:

      -
    • Should we redefine inv and getdata to segregate MSG_TX and MSG_TXV5, making these messages simpler / more efficient to parse? This could be done by adding new inv5 and getdata5 messages. See 10 and 11 for how inv and getdata respectively are currently defined in Bitcoin.
      • +
    • Should we redefine inv and getdata to segregate MSG_TX and MSG_WTX, making these messages simpler / more efficient to parse? This could be done by adding new invw and getdataw messages. See 10 and 11 for how inv and getdata respectively are currently defined in Bitcoin.

    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).

    -

    As specified in 2, 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_TXV5 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_TXV5 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_TXV5 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_TXV5 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.

    +

    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).

    +

    As specified in 2, 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.

    Acknowledgements

    -

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

    +

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

    References

    1415 The halo2 Book
    diff --git a/zip-0239.rst b/zip-0239.rst index 4db9ca3c..deddcae4 100644 --- a/zip-0239.rst +++ b/zip-0239.rst @@ -28,12 +28,19 @@ 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 [#zip-0244]_ 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 [#zip-0244]_. + +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 digest as well as its txid. +relay based on a transaction's authorizing data commitment as well as its txid. Motivation @@ -49,8 +56,8 @@ 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 [#zip-0244]_. -Witness data is committed to by a separate "authorizing digest". Unlike previous -transaction versions, the format of serialized v5 transaction data is not +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 @@ -66,39 +73,42 @@ version of the transaction as well. This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade [#bip-0141]_, until the adoption of BIP 339 [#bip-0339]_. 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 the pair (txid, auth_digest). +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_TXV5`` inv type to the -peer-to-peer protocol, analogous to BIP 339's ``MSG_WTX`` inv type, that announces -transactions by their (txid, auth_digest) pair. It 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_TXV5`` based on the negotiated -peer protocol version (see `Deployment`_). +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_TXV5`` (0x00000005) is added, for use in both ``inv`` messages -and ``getdata`` requests, indicating that the hash being referenced is 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 [#zip-0244]_. +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 +[#zip-0244]_. In the case of ``getdata`` requests, the format of a v5 transaction obtained by a -``MSG_TXV5`` inv type is as given in the Zcash protocol specification. +``MSG_WTX`` inv type is as given in the Zcash protocol specification. [#protocol-txnencodingandconsensus]_ -An ``inv`` or ``getdata`` message MUST NOT use the ``MSG_TXV5`` inv type for v4 +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 the name ``MSG_TXV5`` does not imply that this inv type will not be used -for future transaction versions after v5. Since such versions are not currently -consensus-valid, this is left unspecified. New inv types might be added for future -transaction versions, but only as needed. +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_TXV5`` entries may be mixed in arbitrary order in an ``inv`` +``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 @@ -107,8 +117,8 @@ has to be determined by parsing the whole message. **Open issue:** * Should we redefine ``inv`` and ``getdata`` to segregate ``MSG_TX`` - and ``MSG_TXV5``, making these messages simpler / more efficient to parse? - This could be done by adding new ``inv5`` and ``getdata5`` messages. + and ``MSG_WTX``, making these messages simpler / more efficient to parse? + This could be done by adding new ``invw`` and ``getdataw`` messages. See [#p2p-inv]_ and [#p2p-getdata]_ for how ``inv`` and ``getdata`` respectively are currently defined in Bitcoin. @@ -127,18 +137,18 @@ mempool when reaching the block before that upgrade's activation block. Before t 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_TXV5`` inv type until it has received the block preceding the NU5 +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_TXV5`` inv type, on a peer connection that has negotiated protocol +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_TXV5`` inv type on a peer connection that has negotiated +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_TXV5`` inv type is only enabled between peers that both support 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.