比特币交易替换规则详解：冲突集合、费用差与全量 RBF 时代

替换不是把旧交易删掉，而是制造冲突

一笔比特币交易一旦广播，理论上就存在两种被“换掉”的路径：要么它自己从没被节点接受，要么它被另一条花同一批输入的新交易挤出内存池。本文只讨论后者。比特币协议没有撤销指令，替换的全部机制建立在同一个规则上：同一笔未花费输出（UTXO）只能被花一次，两条冲突交易在内存池里只能活一条。

节点收到冲突交易时怎么算账

节点先把新交易的冲突集合算清楚：与它共享任一输入的现有内存池交易，连同那些交易的未确认后代，全部进入待定名单。Bitcoin Core 的判断条件大致有五条。第一，新交易费用必须严格高于冲突集合的总费用，而且高出的差额至少要达到节点的最低增量费率（默认与最低中继费率同源，约每虚拟千字节一千聪，即通常说的每虚拟字节一聪量级）。第二，新交易自身的有效费率要高于冲突集合，防止只加总价不效率的刷单。第三，新交易不能是零fee交易，也不能超过父交易数量等包结构限制。第四，冲突集合大小有上限（一次替换最多涉及一百条左右交易），且新交易的依赖关系不能把更多未确认交易拖进来。第五，如果新交易本身要依赖内存池里的某条交易，它必须与冲突集合完全一致，否则拒绝。这些条件全部通过，旧交易及其被牵连的后代才会被丢弃。

三个容易搞错的细节

其一，替换不要求签名或收件人不变。只要新交易的花费者签名合法，它可以完全重写收件人和找零，这既是加速手段也是双花风险来源。其二，替换只在未确认阶段有效。一旦旧交易写进某个区块并获得了合理确认深度，替换窗口基本关闭，此时只能靠分叉回收，那属于节点选链的结果，不是用户可操作的机制。其三，替换交易要重新完整广播，钱包通过 sendrawtransaction 提交新交易即可，不需要也不应该尝试“通知”节点删除旧交易。

默认规则的历史转向

早期比特币钱包几乎都允许替换，因为没人认真区分。2016 年随 Bitcoin Core 0.12 系列引入的 BIP 125 确立了 opt-in 信号：只要任一输入的 nSequence 不大于 4294967293（即 0xFFFFFFFD），就宣告该交易可替换，节点据此区分“可替换”与“不可替换”两类交易，收款方也从 nSequence 判断风险。转折发生在 v28.0 与 v29.0：前者把 -mempoolfullrbf 的默认值改为开启，节点默认接受无信号交易作为替换候选；后者（2025 年 4 月发布）以“该政策已被广泛采用、关闭它不再有收益”为由移除这个配置项，full RBF 成为标准行为。也就是说，今天用新版 Core 的节点不再看信号位，只按费用决定去留；把“对方没开 RBF”当作安全保障的时代已经结束，收款风控应回归确认数本身。

收款方怎么看替换风险

小额即时交付场景，零确认交易在任何年代都只是便利而非结算。0-conf 交易随时可能被等额加费的双花替换，这与对方是否显式开启 RBF 无关。稍高价值交易应等待至少一个区块确认，并在收到付款后继续核对同一笔输入是否出现在其他区块。作为付款方想加速旧交易时，正确姿势是构造一条花费相同输入、总费用更高的替换交易，或者更省事：让钱包走 bumpfee / psbtbumpfee 接口，或直接使用 CPFP 给低费子交易加钱。

常见误区

“手续费越高越不会被替换”只对了一半——替换看的是相对冲突集合的费用优势，高费率交易同样可能被出价更高者替换，只是概率更低。“没带 RBF 标记就绝对安全”在 full RBF 时代已不成立。“替换是隐私友好的”则完全相反：两条冲突交易会一起泄露给监听者，它们大概率出自同一钱包，这是所有加速手段共同的隐私代价。