节点为什么收下一笔“没有来路”的交易：比特币孤儿交易池与待处理队列

一笔交易怎么会“没有来路”

比特币节点收到一笔新交易时，要先确认它花的每一分钱都真实存在：每个输入指向的前一笔输出，要么在 UTXO 集合里，要么在自己内存池已收录的交易里。如果这些前置交易还没见面，这笔交易在验证层面就暂时“没有来路”——老玩家习惯叫它孤儿交易（orphan transaction）。它不是无效交易，只是顺序问题：父交易在路上，孩子先到了一步。

在网络传播里这种情况很常见。交易经过多跳转发，节点 A 可能先收到高费率的孙交易，低费率的父交易却在另一条路径上绕路；或者有人用交易包之外的方式先广播了子交易。早期比特币客户端对此的处理很粗糙：收下少量孤儿交易等一会儿，或者直接扔掉，等父交易到了再指望发送方重新广播。

节点为什么收下一笔“没有来路”的交易：比特币孤儿交易池与待处理队列图 2 — 节点为什么收下一笔“没有来路”的交易：比特币孤儿交易池与待处理队列 · 图 2

等待区：从“收着”到有账本的孤儿池

比特币核心把这块等待区叫孤儿池（orphanage），它和内存池是两套独立的结构：内存池装“能立刻验证”的交易，孤儿池装“缺父待补”的交易。补全父亲的过程是主动的：节点会记下是哪条邻居先 announce 了这笔孤儿交易，然后向这些邻居请求缺失的父交易。29.0 版本（2025 年发布）起，这个补链动作进一步升级为向所有宣告过该孤儿的节点同时索取缺失父交易，减少单一路径丢包造成的卡死。

容量方面，旧版核心用一个简单粗暴的上限：默认最多存 100 笔唯一孤儿交易，可以用 -maxorphantx 调整。这个设计的弱点在于按“笔数”计数——攻击者构造一堆输入数量巨大的孤儿交易，笔数没超，内存和哈希查询开销却爆炸，属于典型的低成本骚扰面。

30.0 的规则重写：按资源定价

30.0 版本重做了孤儿池的防滥用边界，思路从“数笔数”改成“算资源”。新规则是：按（wtxid 加来源节点）计的条目数，加上每笔唯一交易输入数除以十后的累计，两者合计不得超过 3000；所有唯一交易的总重量不得超过每邻居 404000 重量单位。换句话说，一个邻居塞进来的孤儿，先按“占多少内存、要查多少次”折算成统一额度，恶意灌满变得昂贵。与此配套，-maxorphantx 参数不再有任何效果——官方发布说明直接建议用户从配置里删掉它，继续写会在未来版本因无法识别而报错。

需要注意边界：孤儿池是节点的可选优化，不是共识要求。邻居完全可以直接丢弃缺父交易而不等，你的交易不会因为进了某个节点的孤儿池就“更安全”，反之某节点没帮你暂存也不代表你的交易被拒。

对普通用户意味着什么

如果你是转账方，理解这个机制的价值在于排查节奏：交易广播后短暂“查无此链”往往只是父交易传播滞后，几分钟内会自然收敛；真正要担心的是长时间停留在“交易不存在或已在链上”这类返回（txn-missing-inputs 一类），说明整条依赖链断了，正确动作是核对原始交易是否仍有效、父交易是否被替换，而不是反复换节点重播。

对跑节点的人来说，结论更简单：默认的孤儿池参数不需要动。它是节点间自愈的小齿轮，不是性能旋钮。