MSG_TX

在比特币的公布协议中，区分一笔付款和一个区块的只有一个数字，即1。它与交易的32字节标识符一同传送，合计36字节，且不会使发送方承担任何义务：只有对等节点以 getdata 回应时，才会传输交易数据。自 Bitcoin Core 0.21.0起，大多数对等节点改用另一个完全不同的代码来公布。

运作方式

MSG_TX 通过 txid 来指代一笔交易，txid 是在不含见证数据的情况下计算出的标识符。

某个节点将您的付款接受进其内存池后，会告知其对等节点该哈希存在。任何没有该交易的对等节点都会请求它，随后才会以 tx 消息发送其内容。如果对等节点请求的内容节点已不再持有，则会收到 notfound，这种情况很常见：内存池在压力下会淘汰交易，而节点没有义务向任何人提供它已丢弃的交易的副本。

提供交易的方式是有意保守的。Bitcoin Core 在某笔交易于内存池中停留几分钟之前，不会把它交给从未向其公布过该交易的对等节点。若没有这一延迟，陌生人可以连接上来，用 getdata 测试您的节点是否知道某些特定付款，这将使每个节点都成为查询自身内存池的接口，也会大大降低查明一笔付款最初出现在何处的难度。

类型1还带有旧的序列化规则。针对它而提供的交易不含见证数据，这是2017年之前存在的格式，对于隔离见证的花费，该格式会省略签名。因此支持隔离见证的对等节点会请求含见证数据的版本；自 BIP339 于2021年1月随 Bitcoin Core 0.21.0发布以来，它们通常改用类型5来公布，以见证哈希指代交易，这样被损坏的见证数据就不会再让交易看起来像是一笔未知的交易。

在哪里会遇到它

MSG_TX 是 "the transaction has been broadcast"（交易已广播）这一说法背后的机制，也是该交易其实并未广播出去的那些情形背后的机制。

仅连接单个节点的钱包会交出一笔已签名的交易，该节点公布其哈希，在某个对等节点请求它之前不会发生任何其他事情。如果始终没有对等节点请求，这笔付款就只停留在一台机器上，没有矿工会看到它。Bitcoin Core 会跟踪自己钱包中尚无对等节点请求的交易，并反复重新公布，直到有对等节点请求为止。因此，位于有防火墙的家庭网络中且没有出站连接的节点，可能会报告付款已发送，而实际上什么都没有离开这栋建筑。

交易所的批量提币也会出现在这里。交易所公布一个哈希，一次请求就送达一笔同时向数十位客户付款的交易，这就是您提币的 txid 中含有属于陌生人的输出的原因。

MSG_TX vs tx P2P 消息

MSG_TX 指代一笔交易，而 tx 消息包含一笔交易。把二者混为一谈会让协议日志难以阅读，因为 inv 和 getdata 行只有类型代码和哈希，而实际的字节只出现在 tx 行中。在调试传播问题时，这一区别最为重要。看到您的哈希出现在 inv 中，证明您的节点告知了某个对等节点。看到随后出现 tx 消息，证明确有对等节点真正需要它。