收到交易通告后不立刻去要：比特币延迟提货的几把秒表

节点收到一条 inv（存货通告）说”我这有笔新交易”，并不会马上回一条 getdata 去提货。什么时候开口问、问谁、等多久再问，源码里由一组以秒计的常量精细调度。这些数字决定了交易在网上传播的”手感”，也解释了为什么同一笔交易在不同节点上被要到的时机不同。本文全部以 Bitcoin Core v31.0 源码为准，相关常量集中在 src/node/txdownloadman.h。

为什么要延迟，而不是收到就问

如果所有节点收到通告就第一时间去要，全网会围绕”最先收到通告的那个对端”齐刷刷地发起请求，形成可被利用的时间指纹——别人能通过谁先要、向谁要，猜出交易大概从哪台机器发出。适度错开请求时机，既打散了这种关联，也让节点有机会先等等”更好的对端”（更可信、更可能已经有的连接），减少重复提货和落在不可靠邻居上的浪费。

几把秒表各管一段

源码里几个常量分工明确。第一把是给非优先对端的额外等待：NONPREF_PEER_TX_DELAY，取值 2 秒。所谓”非优先”通常指来路连接（inbound）等我们不那么信任其会稳定供货的对端；对它们，节点会多压两秒，先把机会让给优先对端。第二把是 wtxid 中继的对比延迟：TXID_RELAY_DELAY，也是 2 秒——如果对手还在用旧的 txid 而非 wtxid 通告，节点会适当延后按 txid 提货，优先从支持 wtxid 的连接获取，避免拿到可被伪造的双胞胎。第三把是重载惩罚：OVERLOADED_PEER_TX_DELAY，仍是 2 秒。当一个对端已经堆了大量未满足的请求（超过 MAX_PEER_TX_REQUEST_IN_FLIGHT，即一百个在途请求的软阈值），就被视作”忙不过来”，对它的通告再压两秒再问。这三把表可以叠加，一条通告如果是非优先、又是旧式 txid、对端还很忙，就会被推后较多才去提货。

六秒之外的兜底与额度

除了”何时问”，还有”问过之后多久没回就找别人”。GETDATA_TX_INTERVAL 取值为 60 秒：一笔交易被向某对端请求之后，如果超过这个间隔仍未拿到，节点会考虑再向别的对端要一次，而不是死等一个可能已经卡住的连接。另一侧是内存额度：MAX_PEER_TX_ANNOUNCEMENTS 取值 5000，限制每个对端能挂在请求追踪器里的”待要交易”数量，防止有人用海量通告把你内存撑爆。这两个数字一个管重试节奏、一个管 DoS 防线，共同保证请求追踪器这个数据结构本身是有界的。

这些延迟发生在哪一层

值得澄清的是，这些秒表管的是”交易下载管理器”（TxDownloadManager）这一层的提货调度，不是共识、不是区块下载。它们只影响你的节点去谁那里、什么时候取那笔交易字节，不影响这笔交易是否有效或最终能否进块。排障时若发现节点收下通告却迟迟不入内存池，可以先看是不是所有可提货的对端都还在延迟窗口内，或者请求都被打给了一个”过载”邻居。

常见误区

一是把两秒延迟当成”确认两秒才生效”：它只是提货时机的错开，跟交易上链速度无关。二是以为这些值可以随便调小：它们相互叠加、又都对着同一个”少暴露、少浪费”的目标，盲目调小会退化成一窝蜂提货，隐私与带宽收益双双缩水。三是把 5000 当”最多同时跟踪五千笔交易”的全局上限：它是每个对端各自计量的，多个连接之间互不挪用。理解这套秒表，就是理解比特币在”尽快拿到交易”和”别把自己暴露得太明显”之间的日常折中。

风险提示：本文为 P2P 传播机制科普，常量取值以 Bitcoin Core 当前版本源码为准，可能随版本调整；不构成交易传播时延承诺或投资建议。