Glossary / Developer reference
MSG_WITNESS_TX
- Definition
- A witness transaction request, sent as getdata, tells a peer to return the named transaction with its signature data still attached rather than stripped out.
Specified in BIP-144.
Ask for a transaction by its txid with MSG_WITNESS_TX and you get back the version with signatures attached. Bitcoin Core 0.21.0, released on January 14, 2021, added wtxid relay and mostly replaced this request with MSG_WTX, which asks by witness hash instead. For anyone sending coins, the payoff is that a tweaked signature no longer makes a payment vanish from relay.
How it works
Every segwit transaction has two identities, and MSG_WITNESS_TX exists because a peer has to be told which one it is being asked to satisfy.
The txid is the double SHA-256 of the transaction without its witness: version, inputs, outputs, locktime. The wtxid is the same hash taken over the full serialization, marker byte and flag byte and witness stacks included. For a transaction with no witness at all the two are equal. For the coinbase transaction BIP141 defines the wtxid as 32 bytes of zero, a special case that exists so the witness merkle root has something well-defined to hang from.
The request code is 0x40000001: transaction type 1 with the witness flag 0x40000000 added on top. Send a bare type 1 getdata and the peer answers with the stripped bytes, which are enough to see where the money went and useless for checking whether the spend was authorised.
This split is what killed the old malleability problem. Before segwit, a third party could re-encode a signature, change the txid, and leave the sender watching for a transaction that no longer existed under that name. Moving signatures outside the txid closed that door, and closing it is what made pre-signed Lightning channel transactions safe to rely on.
BIP339 then took the logic one step further. Peers that send a wtxidrelay message before verack announce transactions by wtxid using inventory type 5, and Bitcoin Core has done this since 0.21.0. The gain is in the rejection cache: a node that refused one malformed witness no longer refuses an honest copy of the same transaction, because the two have different wtxids. MSG_WITNESS_TX survives for peers that never negotiated wtxid relay, which in practice means software older than that release.
Where you see it
The clearest place to meet txid and wtxid side by side is the output of Bitcoin Core's own transaction RPCs.
Call getrawtransaction with verbose output on any segwit spend and you get a txid field and a hash field. They differ. The hash is the wtxid, and the difference is the only visible trace of the witness data in an otherwise ordinary JSON object. Block explorers index by txid, so that is the number to paste into a search box when checking whether your withdrawal has landed.
On the wire, getpeerinfo counts messages by type, and the transaction requests in that breakdown will be a mix on any well-connected node: MSG_WTX to modern peers, MSG_WITNESS_TX to the stragglers.
None of this is something a buyer configures. It matters indirectly. When an exchange tells you a withdrawal has been broadcast and your wallet cannot find it, the useful question is whether the txid you were given ever reached the mempool, not which serialization the peers exchanged.
MSG_WITNESS_TX vs MSG_TX
MSG_TX names the same transaction and returns it with every signature stripped out. That form is what pre-segwit nodes understood, and it still circulates to peers that never advertised NODE_WITNESS. The distinction is not cosmetic: a node handed the stripped version can confirm the transaction structure but cannot validate it, so it cannot safely place it in a mempool or relay it onward as verified. Bitcoin Core will not send a segwit transaction to a peer that only speaks the older form.