Home › Browse › BIP 339

BIP 339: WTXID-based transaction relay

In plain English: Nodes share new transactions by announcing short identifiers, and this change lets them use the "wtxid", an identifier that also covers a transaction's SegWit signature data. The older identifier ignored that data, which could cause nodes to wrongly reject or repeatedly re-download valid transactions, so the switch makes relay more efficient and robust.

Status
Deployed
Type
Specification
Layer
Peer Services
Authors
Suhas Daftuar
Assigned
Last changed
Topics
Transactions
Source
bip-0339.mediawiki on GitHub · Markdown

Abstract

This BIP describes two changes to the p2p protocol to support transaction relay based on the BIP 141 wtxid of a transaction, rather than its txid.

Motivation

Historically, the inv messages sent on the Bitcoin peer-to-peer network to announce transactions refer to transactions by their txid, which is a hash of the transaction that does not include the witness (see BIP 141). This has been the case even since Segregated Witness (BIP 141/143/144) has been adopted by the network.

Not committing to the witness in transaction announcements creates inefficiencies: because a transaction's witness can be malleated without altering the txid, a node in receipt of a witness transaction that the node does not accept will generally still download that same transaction when announced by other peers. This is because the alternative -- of not downloading a given txid after rejecting a 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.

We can eliminate this concern by using the wtxid in place of the txid when announcing and fetching transactions.

Specification

  1. A new wtxidrelay message is added, which is defined as an empty message where pchCommand == "wtxidrelay".
  1. The protocol version of nodes implementing this BIP must be set to 70016 or higher.
  1. The wtxidrelay message MUST be sent in response to a version message from a peer whose protocol version is >= 70016 and prior to sending a verack. A wtxidrelay message received after a verack message MUST be ignored or treated as invalid.
  1. 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 a transaction's wtxid. In the case of getdata requests, MSG_WTX implies that the transaction being requested should be serialized with witness as well, as described in BIP 144.
  1. After a node has received a wtxidrelay message from a peer, the node MUST use the MSG_WTX inv type when announcing transactions to that peer.
  1. After a node has received a wtxidrelay message from a peer, the node SHOULD use a MSG_WTX getdata message to request any announced transactions. A node MAY still request transactions from that peer using MSG_TX getdata messages, such as for transactions not recently announced by that peer (like the parents of recently announced transactions).

Backward compatibility

As wtxid-based transaction relay is only enabled between peers that both support it, older clients remain fully compatible and interoperable after this change.

Implementation

https://github.com/bitcoin/bitcoin/pull/18044

This BIP is licensed under the 2-clause BSD license.

Related proposals

  • BIP 11: M-of-N Standard Transactions: Deployed. Made "M-of-N" transactions, which require any M signatures out of N possible keys, a standard type that nodes relay. This enabled shared-control arrangements such as escrow or wallets needing two of…
  • BIP 12: OP_EVAL: Closed. Proposed a new script command, OP_EVAL, that would let the receiver of coins define the conditions for spending them instead of the sender. It was abandoned over security concerns and replaced by…
  • BIP 16: Pay to Script Hash: Deployed. Introduced Pay to Script Hash (P2SH), letting a sender pay to a short fingerprint of spending rules that the recipient reveals only when spending. This shifted the cost and complexity of setups like…
  • BIP 31: Pong message: Deployed. Adds a "pong" reply that a node sends back when it receives a "ping" containing a random number. This lets software reliably tell whether a connection to another node is still alive.
  • BIP 47: Reusable Payment Codes for Hierarchical Deterministic Wallets: Deployed. Introduces reusable payment codes that someone can publish once, for example on a website, without the privacy loss of reusing an address. Senders use the code to derive fresh addresses for each…
  • BIP 53: Disallow 64-byte transactions: Draft. Proposes making transactions that are exactly 64 bytes long (excluding signature data) invalid. Such transactions can be confused with internal pieces of a block's Merkle tree, the structure…