节点排障时有这样一种尴尬：交易明明广播出去了，对端说见过，钱包就是不见它进内存池；日志里偶尔闪过一句与 orphan 相关的字样，然后什么都没有。比特币核心对”输入还没到齐的交易”有一套专门的暂存机制——孤儿交易库，而查看它状态的实验性命令是 getorphantxs。知道内存池怎么查的人不少，知道孤儿库怎么查的人很少，而它恰恰是”交易卡在半路”类问题里最能直接给出线索的一层。本文按 v31.0 源码拆解这条命令的用法、返回字段和它背后的暂存规则。
孤儿交易是什么，节点为什么要留着一个”废件箱”
一笔交易的输入引用的父交易如果还没被节点见到，这笔交易此刻就是”孤儿”——不是无效，而是暂时无法验证。节点的行为取决于它是否已经通过 INV 宣告见过这笔交易：宣告过的交易被拒绝后节点会记住结论，短时间内不再重新处理；而孤儿库承担的是”先收着，等父交易到位再重试”的职责。在 v30 及之后的实现里，孤儿库的容量模型做过一次重构：不再是简单的条数上限，而是”唯一交易条目数加上每条输入数除以十的总和不超过一个固定额度，同时所有交易的总权重不超过按连接数放大后的另一个额度”。旧的 -maxorphantx 选项在新实现里已经不起作用，官方发布说明明确建议用户把它从配置里删掉，因为未来的版本会直接把它当不认识的参数报错。这段历史对读旧教程很重要：老文档里”默认 100 条孤儿”的描述与新版行为已经脱节。
getorphantxs 的三档 verbosity
命令签名只有一个参数 verbosity，默认 0。档位 0 返回一个 txid 数组，注意源码文档里特意标注”可能含重复项”——同一笔交易如果从多个对端收到，会按对端分别记录，数组里就会出现重复 txid。档位 1 返回对象数组，每个对象带 txid、wtxid、bytes、vsize、weight 和一个 from 数组，from 里列出把这笔孤儿交易送来的 peer id 集合。档位 2 在档位 1 的基础上额外附带交易的十六进制原文。命令标注了 EXPERIMENTAL 警告，未来版本可能变更；同时它属于帮助分类里的隐藏命令，help 列表里不会主动出现，但直接调用是可用的——这也是它能进生产脚本的原因，和”仅供测试”标记的 sendmsgtopeer、addpeeraddress 不同，getorphantxs 的定位是可用但未承诺稳定的观测面。
排障时怎么读这些字段
拿到输出后有几个高信号读法。from 数组只有一个 peer，而你的节点连着多个对端，说明这笔孤儿只有单一来源，父交易大概率没有全网广播，问题在发送方组包或者其上游节点，不在你这里。同一 txid 反复出现在 verbosity 0 的结果里且 from 很宽，说明父交易在某条传播路径上丢失，属于网络瞬态，通常会自愈。孤儿长期滞留且交易权重很大，要怀疑它踩到了容量模型的上限被反复挤出。wtxid 与 txid 不相等意味着这是隔离见证交易，做缓存键时两者不能混用。另外别把孤儿库和内存池混淆：getmempoolentry 查不到的交易如果出现在 getorphantxs 里，状态是”等待父交易”，不是”被拒绝”；反过来两者都查不到，才需要往更早的广播环节查。
一条边界提醒
孤儿库是节点内部的内存态结构，节点重启即清空，命令返回空数组不能推断”网络上没有孤儿交易”，只能说明这个节点当前没暂存。把它当成持续性监控数据时，要在报告里注明观测点是单节点视角，避免用单机视图给全网状态下定论。
风险提示：本文是节点运维机制说明，不涉及任何交易操作与收益安排，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。