为什么子交易的高费率还不够
CPFP 的基本思路，是让高费子交易为低费父交易提供一起被打包的激励。但接收节点需要知道父交易，才能验证子交易引用的输出。缺少输入时，节点不能立即将它作为完整有效交易接纳到内存池；这并不等于交易在共识层永久无效。节点可以暂存缺父交易并尝试索取父交易，具体资源限制取决于实现。
问题在于，补到父交易也未必足够：父交易单独评估时可能因费率太低而被拒绝，而子交易又需要父交易先被识别。包接纳尝试把相互依赖的交易放在一起评估。祖先包中继进一步研究节点之间怎样交换所需信息，两者的关系见 交易包与祖先限制。不能从“我的钱包支持加急”直接推断每条网络路径都支持同一种包协议。
BIP331 提议的是两轮交换
本文把 BIP331 作为协议提案解读，不宣称其完整消息协议已在 Bitcoin Core 发布版部署，也不保留没有版本依据的实验开关说法。提案区分包信息轮与交易数据下载轮：前者帮助接收方知道包中有哪些交易，再决定缺哪些数据；后者允许批量下载交易，减少逐笔请求和重复传输的开销。
规范列出四种新消息，而非简单的一对请求与响应。sendpackages 用于握手时协商包能力；ancpkginfo 返回祖先包的交易标识信息；getpkgtxns 与 pkgtxns 用于批量请求及发送交易数据。还定义了配套的库存类型。交易引用采用 wtxid，包能力需要双方协商，不能仅靠单方发送新消息就获得支持。
这些消息承担不同任务。知道祖先标识不等于已经取得交易，也不等于交易已经通过验证。接收方仍要验证输入、脚本、金额与本地内存池条件，不能把对端声明的包关系当作可信账本。网络中继解决信息传送的问题，最终接纳与出块选择属于后续层次。
缺父交易与费用提升如何衔接
按照提案思路，收到缺输入的子交易后，接收方可以请求其未确认祖先信息，确定需要补齐的交易集合，再下载并评估。若高费子交易足以补偿低费祖先，且整个组合符合本地政策，节点才有机会接纳。这是有条件的流程，不是“任一路径上有一个祖先就一定能够传播”。
发送方可能没有完整信息，对端可能不支持相关能力，节点还可能因为资源预算或冲突交易拒绝接纳。因此不能把设计目标写成公共节点中继成功率已经上升的实测结论，更不能把一笔实际加急很快确认归功于 BIP331。判断一笔交易经过哪条通道，需要对应实现的日志或其他可观测证据。
已发布的有限包中继是另一项证据
Bitcoin Core 28.0 的发行说明明确记载机会式的一父一子包中继：使用已有交易中继协议下载特定父子组合。这份说明同时警告，该 P2P 能力存在限制，在对抗条件下尚不可靠。它不能证明 BIP331 的四种新消息已经实现；“支持包中继”只是总称，不是某一份 BIP 的部署证明。
Core 30.0 的发行说明记录了这条机会式路径的改进，例如子交易已有其他未确认父交易在内存池时，部分组合也可传播。这里的结论仅对应所点名的发行版本，不能推断任意祖先图都被支持。本地 submitpackage 接口与 P2P 中继也不能互相代替：前者向指定节点提交，后者涉及节点之间的发现和传播。
不要混淆三类限制
本地包接口、机会式中继与 BIP331 提案可能共享部分概念，但不能据此声称它们拥有完全相同的资源预算。包的形状、交易数量、体积、缺父缓存和请求频率，各有对应的实现约束。增加新消息也需要考虑拒绝服务风险，不能断言防护成本原封不动。
CPFP carve-out 则属于内存池后代限制的特殊例外，并不等于保证低费父交易获准入池，更不是一套祖先下载协议。对开发者而言，应分别记录创建交易、提交本地节点、远端传播和最终确认四个环节的结果。只有这样，失败时才能定位是缺输入、费率不足、策略拒绝还是网络路径不支持。
用户如何使用这份知识
挑选钱包时，可以询问费用提升使用什么交易结构、兼容哪些节点版本、失败是否给出原因，以及是否支持在测试环境验证。不要仅凭“支持包”三个字判断复杂协议的安全性。测试网络可以帮助演练依赖关系和拒绝条件，见 比特币测试网络的选择；但测试环境成功不构成主网及时确认承诺。
祖先包中继的价值在于明确交换依赖信息，而不是取消手续费竞争或验证规则。本文保留提案机制与已发布实现之间的界线，不提供 BIP331 全网部署比例、钱包采用清单或确认性能保证。涉及时间锁和真实资金的方案，仍需逐版本核对并安排监控。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。