子交易付钱，父交易没人带
子付费父（CPFP）的思路很简单：一笔交易卡住了，就发一笔花费它输出的子交易，给子交易附上足够的手续费，让矿工把父子两笔一起收走，父交易顺带被打包。麻烦出在广播阶段：节点的重传策略普遍要求“先见过父，才转发子”。父交易还没进内存池时，子交易在节点眼里是一个找不到前序交易的孤儿——按老规矩直接丢弃。结果 CPFP 变成死锁：子交易的费率明明足够，却因为父亲不在场，谁也不肯先帮忙带这一对。包重传（package relay）的目标就是把“一对交易”升级成中继决策的基本单位。
从测试接口到 1p1c 中继的路线
Bitcoin Optech 的主题页记录了这条路线的脉络。2022 年，为包重传设计的 v3 交易格式被提出，用于限制包结构带来的攻击面；同年加入了按包验证重传策略的逻辑基础，submitpackage RPC 也先只在回归测试网络可用。2023 年，submitpackage 从仅回归测试放开到更多网络，实验可以真实提交交易包。2024 年是关键一年：Bitcoin Core 合入一父一子（1p1c）包重传、不改 P2P 协议的版本，节点把这对交易当作一个单位评估转发；同期合入限定形态的包替换手续费支持，以及用父交易费率为整包定序的配套规则，BIP331 则被预留给更广的祖先包重传方向。2025 年起的收尾工作包括限制孤儿重传面以抵御拒绝服务攻击、改进孤儿解析流程，2026 年又允许一父一子场景中的父交易费率低于本地最低重传费率——这些条目的生效版本与边界以该主题页与对应发布说明为准。
为什么孤儿要单独管理
包重传带来一个新问题：为了让节点“帮忙保管找不到父亲的孩子”，每个节点都要给孤儿交易留一小块缓冲区。缓冲区是免费的拒绝服务攻击面——攻击者可以海量广播找不到父亲的孤儿，占满所有人的内存。所以 2025 年起的工作重点之一是限制哪些孤儿值得被收留：只有一父一子形态、子交易费率达标等条件满足时才进缓冲区，其余照旧丢弃；同时把孤儿按交易的签名后哈希做索引，减少“同一笔交易换个身份再来一遍”的绕过。理解了这层攻防，就能明白为什么包重传不是一句“支持转发子交易”就宣布完成，而是围绕一个小小缓冲区的多年收紧。对普通节点运营者，这意味着升级到新版本后不必手动调整：缓冲区大小与准入条件由客户端内置策略管理，真正的风险点反而是某些第三方中继或自建网关仍在用旧的“丢弃一切孤儿”策略，让加急交易在最后一公里被静默吃掉。
钱包与用户看到的差别
对使用 CPFP 加急的人，包重传落地后的直接变化是：加急时子交易更容易被网络传播，而不是静静躺在某个节点里等父亲。在钱包与节点并行的环境里，还可以用 submitpackage 一类接口把父子成对提交，跳过“先广播父亲、再祈祷父亲先被看见”的竞态——具体暴露哪个接口、允许什么网络环境，以所用客户端版本的 RPC 文档为准。钱包侧要注意两点。第一，1p1c 的“一父一子”是硬边界：一个父带多个子、或孙交易链，仍会被按旧策略处理，加急设计应贴合这个形状。第二，v3 交易形态对父子结构有额外约束，这正是当年为包重传设计该版本的动机；父交易本身费率再低，只要整包费率达标就能被中继，这修正了“低费父交易带不动”的老问题，但钱包仍应展示整包有效费率而不是只看子交易。闪电通道场景还涉及通道开户交易的 CPFP 另一条规则（carve-out 豁免），与本文的包重传是互补机制；CPFP carve out 是什么？闪电通道开户交易如何保证双方都能加急。本文只描述中继与费率的机制事实，费率数值随网络拥堵波动，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。