Glossary / Developer reference
MSG_TX
- Definition
- MSG_TX marks an inventory entry as a transaction, type code 1, and it is how your unconfirmed payment gets announced to peers before any of them have seen its contents.
One number separates a payment from a block in bitcoin's announcement protocol, and that number is 1. It travels with the 32 byte identifier of the transaction, 36 bytes in total, and it commits the sender to nothing: the bytes move only when a peer answers with getdata. Since Bitcoin Core 0.21.0, most peers announce with a different code entirely.
How it works
MSG_TX names a transaction by its txid, the identifier computed with witness data excluded.
A node that has accepted your payment into its mempool tells its peers that the hash exists. Any peer lacking it asks, and only then are the contents sent, in a tx message. A peer that asks for something the node no longer holds gets notfound, which happens routinely: mempools evict under pressure, and a node owes nobody a copy of a transaction it has already dropped.
Serving is deliberately grudging. Bitcoin Core will not hand a transaction to a peer it never announced it to until that transaction has been sitting in the mempool for a couple of minutes. Without the delay, a stranger could connect and use getdata to test whether your node knows about particular payments, which would turn every node into a query interface for its own mempool and make it far easier to work out where a payment first appeared.
Type 1 also carries the old serialization rule with it. A transaction served in answer to it is written without witness data, the format that existed before 2017, which for a segwit spend omits the signatures. Segwit aware peers therefore request the witness variant, and since BIP339 shipped in Bitcoin Core 0.21.0 in January 2021 they normally announce with type 5 instead, naming transactions by witness hash so that a mangled witness no longer looks like an unknown transaction.
Where you see it
MSG_TX is the machinery behind the phrase "the transaction has been broadcast", and behind the occasions when it turns out not to have been.
A wallet connected to a single node hands over a signed transaction, that node announces the hash, and nothing else happens until some peer requests it. If none ever does, the payment is sitting on one machine and no miner will see it. Bitcoin Core tracks its own wallet transactions that no peer has yet asked for and re-announces them until one does. A node with no outbound connections, on a firewalled home network, can therefore report a payment as sent while nothing at all has left the building.
Exchange withdrawal batching turns up here too. The exchange announces one hash, a single request delivers a transaction paying dozens of customers at once, and that is why the txid on your withdrawal contains outputs belonging to strangers.
MSG_TX vs the tx P2P message
MSG_TX names a transaction, and the tx message contains one. Confusing them makes protocol logs unreadable, because inv and getdata lines are nothing but type codes and hashes while the actual bytes appear only on tx lines. The distinction matters most when you are debugging propagation. Seeing your hash go out in an inv proves your node told somebody. Seeing a tx message follow it proves somebody actually wanted it.