手续费替换在比特币生态的演化之路

Robin Wang
2天前
讀畢需時 26 分鐘

作者：Robin Wang


前言

Robin 的这篇报告讨论了比特币中的手续费提升方案的演进历程，详细比较了 RBF 和 CPFP 方案的优劣。进一步地，对 RBF 的各变种进行了介绍和分析，解释了全面 RBF 得到普及的原因。文章最后还总结了全面 RBF 普及对用户、矿工及矿池和其它参与方的影响。文章展现出比特币协议中“规则”演进的博弈，希望可以帮助读者更好地理解比特币。全面 RBF 的普及发生在本报告的撰写过程中，因此报告的框架和结构进行了多次调整，最终定位为回顾性研究，特此说明。

— 姚翔

简介

区块空间的稀缺催生了手续费市场，比特币的去中心化机制让用户通过竞价来决定谁的交易优先被确认。市场波动下，未确认交易的处置是比特币用户体验和协议设计的核心问题之一。应对这种情况，一般性的解决方案有 RBF(Replace-by-Fee) 和 CPFP(Child Pays For Parent)。其中，RBF 允许交易创建者主动提高手续费并替换原有交易，而 CPFP 则通过构造后续交易激励矿工打包未确认交易。虽然两种机制都能提高交易被确认的概率，但 RBF 所允许的交易替换行为改变了人们对未确认交易的认知，并引发了关于交易最终性、双花风险以及节点策略的一系列讨论。因此，本文将以 RBF 为主线，介绍其工作原理、发展历程及其对比特币生态的影响，并对 CPFP 作简要说明。

本文最初起笔于 2022 年底至 2023 年初。当时，社区围绕全面RBF的发展众说纷纭，围绕零确认支付、矿工激励与上层协议安全的假设分歧较多。彼时，梳理RBF的不同立场和演化路径是一项面向现实的工作。随着相关的讨论持续推进，本文的写作与修订也跨越了较长时间。到本文最终完成时，全面RBF已从争议对象转变为后续集群内存池（Cluster mempool）等政策和机制的重要前提。因此，本文既保留了对争议性观点及发展的梳理，也尝试从现在的角度重新理解RBF在比特币生态演化中的位置。

目前全面 RBF(Full RBF)已落地推行，关于手续费的优化也在进入新的阶段，集群内存池等改革正在持续发展，回看 RBF 的发展及演化历程，不仅有助于理解新一轮的变化为何会沿着当前方向展开，也有助于重新认识比特币社区在交易中继、手续费管理和协议安全问题上的权衡和逻辑。

背景与概念

为应对手续费市场波动常导致低费交易卡在内存池中的问题，比特币生态演化出了两种核心策略：RBF(手续费替换)与 CPFP(子为父偿)。本章拆解这两种机制的底层逻辑，并厘清它们之间的技术边界。这种区分不止是为了归类，也因为它关乎在后续更复杂的协议设计中，如何根据不同的交易竞争环境选择合适的策略，从而可靠地推进交易确认。

背景

在比特币网络中，一笔交易被发起后会先被广播到节点，此时这笔交易会先进入内存池，交易要被矿工打包进一个新区块中才可以视为确认。但在一些小额、对速度敏感的场景中，收款方有时不等区块确认、仅凭交易进入内存池就放行商品，这称为「零确认支付」；它依赖「已广播的交易不会被轻易替换」这一假设，而这一假设正是后文全面 RBF 争议的焦点之一。交易支付的手续费越高，越容易被矿工打包。交易费用不是一个固定的数额，而是在市场中自由竞价形成的。也就是说，在同一时间发生的交易越多，矿工可选择挖出的区块就越多。而对矿工来说，理性的选择是挖出交易费用更高的区块以赚取更多的手续费。

一笔交易可能因手续费估算过低，或发送后网络突然拥堵而长时间滞留在内存池中。对于普通支付场景而言，这会带来确认延迟与体验下降；另外在某些协议场景下，相关交易会受到时间窗口的约束，难以准确预估确认时所需的费用。此类情况下，能否快速确认并非只关乎体验，更直接关乎资金安全：例如闪电网络中一笔承诺交易或 HTLC(哈希时间锁合约) 的及时上链、链上协议中保证金的追加等，由于交易常常在广播前很久就已预签名，实际广播时的手续费可能已经发生变化，一旦确认延迟，就会导致资金损失或被对手方利用。此时若用户不能增加手续费就只能陷入被动等待，严重影响用户体验。

未确认的交易如何处理，表面上是手续费决定的，实际牵涉节点是否接受替换、矿工如何进行收益选择、收款方如何评估零确认支付风险以及闪电网络等底层协议如何安排交易与费用提升路径。正因如此，今天重新梳理 RBF 的演化，不仅是在回顾关于全面 RBF 是否该实施的讨论，也是在理解后续v3 交易等政策与机制为何会沿着当前方向继续发展。

概念解释

RBF(Replace-By-Fee)

手续费替换(Replace-By-Fee)是一种节点策略。（下文统称为 RBF）[4]

当发送一笔交易但设置的交易费用太少，交易可能会被延迟很长时间或不会被处理，即变成被阻交易。为了解决这个问题，我们可以采取“手续费替换”这种方法。用户可以构造并签名一笔替换交易，替换交易需要花费被阻交易的一个或多个相同输入[1]，并且支付更高的手续费，这样一来矿工就更有动力去打包这笔交易，从而使交易顺利进行。

CPFP(Child Pays For Parent)

子为父偿（CPFP）是一种费率提升机制，用户可以花费一笔未确认的交易（父交易）的输出、作为一笔新交易（子交易）的输入。子交易应附带足够的交易费，从而提高父交易和子交易的联合交易费率。新建的高费率子交易会在某种程度上补贴低费率的父交易。在选择打包入块的交易时，矿工将需要考虑交易 “包”，要看整个交易包的总体费率[1]。进而以更高的总费率吸引矿工来处理这笔交易。

CPFP 相较于 RBF 操作的复杂度更高，在实际应用中控制的难度也较高。它无法直接设定目标费率，而需根据父交易的体积与已付费用倒推子交易应付的金额，同时它依赖一笔可供花费的未确认输出，并因父子两笔交易都需上链，相较于直接替换原交易的 RBF 而言会占用更多区块空间。

CPFP与RBF使用场景的区别[11][24]

使用RBF的场景	使用CPFP的场景
/	允许花费未确认交易的输出的情况
允许增加收款人或修改付款对象	不允许增加收款人或改变付款对象
可以接受txid改变的用户	不希望txid改变的用户
允许发送交易的人增加手续费	允许接受交易的人改变手续费
希望替换后的费用相对较低的人，相比CPFP更低（30%-90%）	不介意替换后的费用较高的人（尤其是在多方支付中）

表 1：CPFP与RBF使用场景的区别

归根结底，RBF 是基于输入替换的「原地提效」，CPFP 则是基于输出关联的「联合激励」。理解这两者的权衡，是拆解后续闪电网络、Ark 等复杂协议设计的逻辑起点。然而，这些机制在被引入之初，远不如今天这般成熟：它曾引发关于「零确认安全」的激烈争论，也暴露出诸如「交易钉死」之类的底层漏洞。为应对这些挑战，比特币的交易中继规则经历了一段漫长且充满争议的演化。

演化历程

本章我们将回溯 RBF 如何从一个被中本聪禁用的功能，一步步成长为支撑今日比特币内存池策略的核心机制之一。在这条线索演化背后，是社区多个成员围绕矿工激励、政策兼容、节点中继规则等的激烈讨论，以及在「保护零确认支付」与「提升手续费市场效率」之间的反复权衡。

早期探索

在中本聪最初的代码中，比特币实现在每个输入中提供了 nSequence 序列号字段，以便在内存池中替换包含该输入的交易。在接收替换时，节点应该用序列号较高的交易替换输入序列号较低的交易。

在这种实现方式中，替换交易无需支付额外费用，因此矿工没有直接的动力去包含替换交易，也没有内置的速率限制来防止过度使用中继节点带宽。中本聪在比特币 0.3.12 版本中删除了替换功能，只留下 "暂时禁用替换功能 "的注释[3]。

为了解决这些问题，Peter Todd 等社区开发者创建了 RBF 的变体——RBF-FSS，要求替代交易支付与原始交易相同或更多的所有输出。但 RBF-FSS 实际上要求增加额外的输入，每次增加费用都增加额外的输入使交易体积进一步变大，交易费用进一步提高，而很多钱包中没有多余的 UTXO 输入，无法使用该策略，而频繁添加输入也有暴露隐私的风险。因此 RBF-FSS 最终并没有在实际情况中被采用[2]。

而后 Opt-in RBF 于 2015 年在 BIP-125 中被提出。Opt-in RBF 使用中本聪的原始语义（稍作调整，允许时间锁用户选择退出）来表示替换是可能的，为第一眼看到的用户提供了忽略这些交易的能力，同时也兼具了 Full RBF 的效率优势[3]。 2016 年，Bitcoin Core 0.12.0 版本实现了 BIP-125[29]。

全面 RBF 的提出和争议

	2022 年观点	介绍
Antoine Riard	倾向于支持全面RBF。在多方发起的交易中（coinjoin-type），如果其中的一个参与者发起了不可被替换的非RBF交易，且交易手续费很低，交易在内存池中无限期停留，则不能顺利推进。如果使用 Full RBF 则可以解决这个问题。	Bitcoin Core 核心开发者，主要研究分支为 RBF 和闪电网络[9]。咨询公司TheLab31 主要人员。
Suhas Daftuar	总结了一些反对全面 RBF 的论点，之后在其 PR 中也有许多反对观点[7]。	Chaincode Labs 联合创始人，Chaincode 是 Bitcoin core 的最大捐赠者之一。
Jeremy Rubin	赞成运行全面 RBF 节点；鼓励转向全面 RBF，在邮件中阐述了BIP-125的 opt-in RBF 替代方法。	Judica 创始人。Judica 意在支持比特币研究和发展，主要焦点为Sapio（一门比特币智能合约编程语言）。
Gloria Zhao	赞成运行全面 RBF 节点；早期积极发布相关讨论，后期深入研究优化策略。	Bitcoin Core 核心开发者，主要关注内存池和点对点网络逻辑，特别关注 L2 的安全。
Larry Ruane	倾向于支持全面 RBF，讨论了能否在不改变交易 txid 的情况下进行替换。	比特币核心开发者，参加过诸多开源项目。
Peter Todd	赞成运行全面 RBF 节点；BIP-125 作者之一。	Bitcoin Core 核心开发者，创办了 Opentimestamps。
Dario Sneidermanis	赞成运行全面RBF节点，但需要做好应用层的通知以让其做好准备。	Muun Wallet 创始人。
Sergej Kotliar	不赞成全面 RBF，他维护零确认支付的实用性，并且这种方法已经在应用中得到了验证，他还指出全面 RBF 可能会导致一些免费期权问题。	Bitrefill 创始人、CEO。
John Carvaho	不赞成全面 RBF，他认为全面 RBF 将使零确认支付的风险更难管理。	Synonym CEO，曾任Bitrefill CCO。
Anthony Towns	倾向于赞成运行全面 RBF 节点。	Bitcoin Core 核心开发者，曾任红帽发布工程师、Debian 开发等。

表2: 2022 年全面 RBF 之争的核心人物、立场与背景

如表 1 所示，2022 年 6 月，Antoine Riard 提出在 Bitcoin Core 24.0 版本中加入 -mempoolfullrbf 选项[38]，在这个时间段，以 BIP-125 为核心的 Opt-in RBF 策略在网络应用中是主流。帖子被发出后引起了很大的争议和讨论，如果启用该选项，即使替换的交易不包含 BIP-125 选择信号，也将允许用户更改其单个节点用于中继和挖掘未确认交易[6]。该讨论一直持续到了 2022 年。其中 Dario Sneidermanis 发帖表示担心全面 RBF 以及-mempoolfullrbf 选项会给接受未确认支付的企业带来问题，例如 Muun，他建议应多一些时间来准备，Sergej Kotliar 表达了对零确认支付方案的维护，目前双花的成功率是极低的，零确认支付可以安全地进行交易已经过商业验证；John Carvaho 对此表达了类似的观点。Anthony Towns 支持全面RBF，但他同意不立即在主网应用此选项，而是先部署在测试网，并且他还创建出一个相应的实施时间表。2022 年 11 月底，Bitcoin Core 发布了带有该选项的 24.0 版本。

而后在 2023 年，Peter Todd 进行了一次测试，发现约有 17% 的节点在使用时手动将 -mempoolfullrbf 选项由 false 改为了 true，并用 mempool.space 等进行了举例佐证[13]。Anthony Towns 对全面 RBF 的动机相关的帖子进行了回复之后进行了展开说明。Towns 指出，从短期利益的角度来说，更高的费用对于矿工来说的确更具吸引力，但在采矿设备上进行长期资本投资的矿工可能更倾向于优化多个区块的费用收入。对此，他提出了三种可能的情况，在这三种情况中，全面RBF对整个系统产生的影响各不相同——

乐观情况：
- 交易量和现有交易手续费的水平维持不变
- 用户可以更方便地取消或替换错误交易
- 用户不再因 RBF 交易确认慢而向钱包开发者投诉
在这种情况下，全面 RBF 的实施不会带来明显的负面影响，甚至可以改善用户体验，增加矿工的手续费的收入。
中性情况：
大多数使用比特币进行链上交易的用户会转向使用闪电网络等二层支付方案，这会导致链上交易量下降，从而降低手续费的收入。如果这种情况发生，链上的交易量会减少，但因交易转向了二层并未对比特币整体产生太大的影响。
这种情况下全面 RBF 可能会获得更多的社区支持。RBF提高费用以提高矿工的激励的作用在此情况下显得不再那么重要，但在另外一些方面这种情况反而对于全面RBF更加有利：
- 在交易未确认时，RBF 会一定程度增加双花风险。如果链上交易减少，用户转而使用闪电网络，闪电网络使用HTLC等机制来防止双花攻击，所以即使使用 RBF 来替换交易，也不会直接影响到闪电网络的安全性。
- 链上交易减少后，区块空间压力变小，RBF 可以进一步提高区块空间的利用效率。因此全面 RBF 可能更加容易推动实施。
悲观情况：
大量用户为了支付的便利性选择改用其他加密货币或稳定币进行支付。此针对全面RBF举措的讨论不再具有意义。

2023 年 8 月，Peter Todd 提议将 Opt-in RBF 改为全面 RBF，因为根据他的测量结果，相当大比例的挖矿哈希率遵循了全面 RBF 规则，而且有足够多的中继节点启用了全面 RBF，允许非信号替换传递给这些矿工。他列举了包括 Foundry USA、Antpool、Binance pool等内存池对全面 RBF 的应用情况[13]。他反驳了之前有人提到的 Bitrefill 会接受未确认交易未付款的观点，并表示目前没有任何活跃的企业接受未经确认的链上交易作为最终付款[12]。并对之前零确认交易相关的讨论进行了回复。

2024 年 3 月，BitGo 宣布该旗下的钱包和 API 支持运行 RBF，并向其用户详细介绍和普及了 RBF 的用法[22]。

2024 年下半年，Bitcoin Core #30493 使 RBF 变成了默认设置，同时，也将 opt-in RBF 作为可恢复的选项留给了节点运营者。11 月，Bitcoin Core #30592 移除了 -mempoolfullrbf 选项。

RBF变种的提出和部分技术讨论

RBF的变种

Post-cluster package RBF 相关讨论

在针对集群内存池的讨论中，Daftuar[21]针对 Bitcoin Core现有的RBF机制和集群内存池RBF机制进行了比较，总的来说结果相差不大。不过，新提出的RBF规则从激励兼容的角度最大限度地保护了内存池，即免受激励不兼容替换的影响。理论上讲，目前可以做到将一些看似更好实则会触发不理想行为的替换被阻止，这种情况是在BIP-125实行时无法洞见的。

Kindred RBF 相关讨论

2024 年 1 月，Kindred RBF 相关的话题引起了广泛的讨论，讨论倾向于在 v3 交易中引入一种新的 RBF 机制来取代或弱化 CPFP carve-out —— 后者是一条内存池例外规则，即在交易后代数量已达上限时，额外放行一笔诚实方的小体积 CPFP 子交易，从而缓解锚点交易被对方钉死的问题。Kindred RBF（同类 RBF、亲缘 RBF）相关的话题引起了广泛的讨论。相较于传统意义上基于直接输入冲突的替换，Kindred RBF[19]是指针对两笔不冲突但存在亲缘关系的交易，一笔交易能够在内存池中替换另一笔交易。其主要形式为亲缘驱逐，即一笔未确认的子交易可以替换另一笔子交易。Kindred RBF 的提出意在对 CPFP carve-out 进行优化，亲缘 RBF 也可以更好地在未来的集群内存池中实施。大概的流程如下：

在闪电网络中，Alice 可以发送承诺交易，并配套一个子交易用来支付手续费
Alice 可以通过替换原有的子交易来提高手续费
Bob 可以使用亲缘 RBF 将 Alice 的子交易驱逐出内存池，即广播一个由他构建手续费更高的子交易
Alice 同样可以构造一个手续费更高的子交易对 Bob 的交易进行亲缘 RBF，并对其进行驱逐

如果实施此策略那么 CPFP carve-out 策略将会从闪电网络的锚点交易中移除。目前来说反对的声音较少。

但有人提出实施此策略是否会使临时锚点变得不再必要，不过临时锚点的作者 Gregory Sanders 指出他会继续进行优化工作，因为零聪输出在闪电网络之外仍有应用场景。

RBFr 相关讨论

Peter Todd 提出了 One-Shot Replace-By-Fee-Rate（RBFr）。该提案旨在提供一组可以在现有的RBF情况下无法允许替换交易时进行交易替换的方法。对此他提出了两种不同的解决策略：

纯按费率替换（纯 RBFr）：在内存池中的交易可以被支付显著更高费率的冲突交易所替换（例如，替换交易支付的费率是被替换交易费率的两倍）。
一次性按费率替换（一次性 RBFr）：在内存池中的交易可以被支付略高费率的冲突交易所替换（例如，1.25 倍），前提是替换交易的费率也足够高，使其位于内存池的前 100 万字节中（这意味着如果在替换交易被接受后立即生成区块，它将被直接挖出）[20]。

之后，Mark Erhardt 和 Peter Todd 针对其滥用风险进行了讨论，称攻击者可以以极低的成本消耗无限节点的带宽。随后 Peter 更新了这个提案，添加了新的 RBF 限制，解决了允许攻击者以最小成本浪费无限量节点带宽的潜在风险。此外，Gregory Sanders 和 Gloria Zhao 提出了其他关注点。Sanders 认为在集群内存池实施之前进行这个方向的推理获得的成效十分微弱，在完全放弃自由中继保护的想法之前，应该更多地考虑更加正确地处理 RBF 的激励机制。

Gloria 提到现有的机制不支持对矿工的激励兼容性或具体的评分进行计算，因为交易群规模不受限。集群内存池的优势之一就是可以对交易群规模进行一定的限制，而 v3 交易可以在集群内存池实施之前作为这个问题的模拟场景因为 v3 交易可以先行引入集群限制（如为 2）。她表示一次性按费率替换不是一个可行的方案，因为它即没有解决免费中继问题，也很难准确实现。之后Peter Todd 发布了一个针对于按费率替换的实验性实施方案。

其他技术讨论

2023 年 2 月，Bitcoin Core #25344 对 bumpfee 和 psbtbumpfee 这两个用于 RBF 费率提升的 RPC 命令进行了更新。此次更新允许在替换交易中指定输出，这意味着替换交易中的输出集可以与被替换的交易不同。这一功能可以用来添加新的输出（例如用于迭代式支付批处理），或者移除某些输出（例如尝试取消一笔未确认的支付）[10]。

2023 年 10 月，社区内有关 RBF 的讨论议题有四个：

Matt Corallo 建议矿工保留他们见过的交易记录，若有重要的交易因交易钉死（Transaction Pinning）或网络攻击等原因被卡在未确认状态，矿工可以选择再次处理这些交易。Bastien Teinturier 对此表示赞同，他还表示应尽量改进更比特币底层协议，为 L2 提供保障。Antoine Riard 也提出过相似观点，他表示可持续的解决方案只能在基础层实现，比如增加一个消耗大量内存的可见交易历史记录[17]。
预签名费用问题：
Peter Todd 认为，“正确的预签名交易方式是预先签署足够多的不同交易，以满足所有合理的费用上涨需求。没有任何理由让 B->C 的交易卡在未确认状态。”[8] 即，可以预先签署多版本的交易，在未来根据网络情况选择合适的版本进行广播。如 Bob 和 Mallory B 进行了一笔 HTLC 交易，他们准备了费率为 1、2、4、8、16、32、64、128、256、512、1024 sats/vbyte 的不同交易，再选择合适的进行广播。不过如果使用这种方式，因为已签名所以无法修改输入进行RBF操作，即便不能使用 RBF，使用这种预签名支付方式也不会直接导致交易卡住。
替代循环攻击[18]对 HTLC 的影响：替代循环攻击通常指攻击者利用协议漏洞（这里特指RBF），使得交易被多次替换，从而影响交易的确认和完成。通常，攻击者 Mallory 和 Bob 共享一个 HTLC 输出，当 Bob 使用该输出时，Mallory 可以立即替换她的交易输入，使Mallory的输入不再包含共享输出。Mallory 可能会替换她的交易，使 Bob 无法在规定时间内撤销其花费。由于 HTLC 机制，Bob 可能被迫关闭交易并支付费用，而攻击者会获取这些收益。另外，替代循环对LN节点的影响类似于现有的交易钉死。然而，旨在防止 LN 和类似协议中的固定攻击的技术[25]（如 v3 交易转发）无法防止替代循环。

2024 年，Peter Todd 在邮件列表发帖针对支付锚点（P2A）的输出类型进行了讨论。支付锚点（P2A）是临时锚点提案的一部分。P2A 是一种任何人都可以花费的输出。这在多方协议（如闪电网络）中，尤其适用通过 CPFP 进行手续费提价。

然而，在当前的闪电网络中，使用 CPFP 进行手续费提价有一个漏洞，对手方可以发起一个成为替代循环攻击（Replacement Cycle Attack)的两段式攻击。步骤如下：

对手方用自己的交易替换掉真实用户的那一笔交易（两笔交易的版本内容基本相同）
对手方使用一个与双方版本交易都无关的交易替换掉之前自己的那一笔交易

当闪电网络通道中存在未解决的 HTLC 时，一笔替换可以使窃取方从真实用户处窃取一笔资金。在某些情况下，这种攻击几乎是免费的，例如攻击者本就计划广播一笔手续费率更高的交易，而且成功完成替换循环前，没有哪个版本被矿工确认上链。

在现有的闪电网络锚点输出类型中，只有对手方才能实施这种攻击，Todd 指出，理论上 P2A 是一种任何人都能花费的输出因此理论上任何人都能发起。但在实际用例中，只有交易对手方才能获得经济利益，因此其他人并无动机发起这种攻击。

目前闪电网络已部署的所有替代循环攻击防护措施[26]在针对 P2A 时仍是有效的。

从早期因安全隐患被中本聪禁用，到成为全网默认的共识规则，RBF 的演化折射出比特币底层逻辑的一次变迁：网络不再依赖中继层面的策略维系零确认支付的稳定预期，而是转向更透明、更符合市场激励的博弈模型。至此，RBF 完成了从「可选插件」到「基础设施」的转变。它不仅改变了未确认交易的手续费调整方式，也催生出一系列技术变种。

RBF 的分类及发展

本章我们将先梳理演化中出现过的各类变体：有的被主流客户端采纳，有的仅停留在讨论阶段，但每一种都对应着社区某一时期试图解决的具体问题。

分类

选择性 RBF（Opt-in full-RBF，以下简写为Opt-in RBF）

概念

Opt-in RBF 允许交易的创建者发出信号，表明他们愿意让该交易被付费更高的版本所取代，直到它们在区块中得到确认。

设计初衷

在最原始的替换交易策略中，替换一笔交易并不需要支付额外费用，也没有内置速率限制，替换交易无需支付额外费用。矿工在这种情况下并没有动机来打包新的替换交易。BIP-125 的出现为用户提供了手续费替换的方法，并且规则相较于最初版本更加细致。

BIP-125[3]

BIP-125 引入了 Opt-in RBF 的概念。其允许支付交易的一方在交易中添加一个信号，表明他们希望将来能够替换该交易，支付方可以通过这个功能来应对意外的网络延迟或其他需要替换的情况。

实现细节

替换交易必须符合以下条件才能替换内存池中的交易：

原始交易明确表示可替换，或通过继承表示可替换。
替换交易须包含已包含在原始交易中的未确认的输入。
替换交易支付的绝对费用至少等于原始交易支付的金额。
替换交易还必须按照或高于节点最低中继费设定的费率支付自己的带宽。
被替换的原始交易及其将从内存池中驱逐的后代交易的总数不得超过 100 个。

支付钱包和收款钱包原则

作为对该信号的回应，节点可允许在其内存池中替换包含该信号的交易。

若支付钱包不想发出可替换信号应使用最大序列号 (0xffffffffffff) 或序列号 (0xffffffffff-1)。
节点和收款人可以选择忽略该类型交易并正常进行其他操作；或在遇到包含该类信号的交易时选择在交易确认前不将其视为付款。

动机

微观来说，通过对替换交易支付更高手续费的方式，BIP-125 提供了一种使矿工利益与支付者意愿相同的途径，进而提高网络效率。

重要性

增强用户体验。支付方可以选择在交易中加入信号表明替换意愿。收款方可以选择在确认交易后将其视为付款或忽略该类型交易。
提高交易的灵活性。可以使用户在在网络条件变化时进行时通过增加手续费的方式调整费用。

优点

提供了灵活调整手续费的一种方法
对零确认支付的影响相对风险较低

潜在不足

会对零确认支付产生影响
受限于规则，需启用后才能进行替换，相比全面RBF操作较为繁琐

实际被采用情况

BIP-125 提案在 2015 年 12 月 4 日被创建，经过讨论后在 2016 年 2 月 Bitcoin Core 0.12.0 版本中被推广实施。Opt-in RBF 一直沿用至 2024 年 11 月，即全面 RBF 被广泛使用之前。

RBF-FSS (RBF First Seen Safe)

概念

FSS（First Seen Safe）指在交易被广播到网络中并被其他节点第一次看到后，就视为是安全的，即交易就不会被替换或修改。

设计初衷

针对因实施 Opt-in RBF 导致的一系列用户习惯改变所带来的风险提出的过渡性方案。

工作机制

RBF-FSS 要求替代交易至少支付相同地址的相同金额，替换交易需要包括当前交易的所有相同的输出，在此基础上增加一笔额外的输入来作为多支付的手续费。

优点

允许对手续费进行调整
保护了零确认支付的安全性

潜在不足

传播易受网络环境影响，用户难以预测是否还能成功替换，体验不稳定
由于每次替代都需增加新的输入，导致交易体积变大，手续费进一步上升。
很多钱包没有多余的 UTXO输入，无法使用该策略。
频繁添加输入会降低隐私性，因为不同来源的UTXO会被聚合到同一笔交易中。

实际被采用情况

尽管 RBF-FSS 作为 Opt-in RBF 的过渡方案在争议中被提出，这种策略并没有在实际应用中实现。Bitcoin Core 直接实现了 Opt-in RBF 。

Time-based RBF

概念

Time-based RBF 是基于 RBF-FSS 提出的另一项策略；在交易被首次看到后，在一定数量的区块内执行 FSS 策略，之后，只有在该交易未能被挖掘出来的情况下，才允许用 RBF 将其替换[2]。

工作机制

当一笔交易被广播到网络后，节点会记录其“首次见到”的时间（以区块高度计）。在设定的区块数 N 内，节点只接受这笔最先见到的交易，不允许用 RBF 机制替换。如果这笔交易在 N 个区块后仍未被矿工打包进区块，节点才允许新的高手续费交易替换原交易

设计初衷

该方案旨在平衡两种需求：一方面保护收款方，短时间内交易不会被替换，降低了双花的风险；另一方面又允许付款方在交易长时间未确认时通过RBF机制加快确认速度。

实际应用情况

Time-based RBF 只是一种被讨论过的策略，并未在主流比特币客户端中实现。

全面 RBF[5]

概念

与 Opt-in RBF 相比，全面 RBF 不需要在交易中添加信号即可进行替换。

设计初衷

在网络较为拥堵或一笔交易的交易费用相对太少的时候，提供一种替换被阻交易，从而加快交易速度的方案。

工作机制

替换交易至少花费原交易的一个相同输入
替换交易需要支付与原交易相等或更多的交易费用
除标明交易可替换的 BIP-125 其他原则

优点

相比 CPFP，RBF 更节省成本和区块空间
相比 Opt-in RBF，全面 RBF 无需添加信号即可替换
全面 RBF 有利于二层协议如闪电网络等的发展
为后续升级优化手续费估算体系铺路

潜在不足

实施全面 RBF 零确认支付的安全性会显著降低（编者按：指抗 RBF 双花攻击的能力，即付款方在商家放行商品后、提费广播一笔双花交易将原交易覆盖）
相比 CPFP，RBF 还会改变交易的 txid，使后续依赖于原先 txid 的交易失效

实际被采用情况

在经过社区不断讨论和改进后，全面 RBF 在 2024 年后逐渐成为主流。11 月，-mempoolfullrbf 选项被移除，标志着全面 RBF 的普及。

Post-cluster Package RBF

概念

Post-cluster Package RBF 是全面 RBF 的延伸。RBF 本身倾向于解决某一笔被阻交易的情况，而 Post-cluster Package RBF 聚焦于整个集群的总收益。

集群内存池（Cluster Mempool）[31]

集群内存池是一项提案，只在将内存池中每笔未确认的交易与相关的交易关联起来，从而创建一个集群(Cluster)。

设计初衷

Post-cluster Package RBF 可以为复杂的用例如闪电网络、CoinJoin 等提供更好的优化和支持，可以扩展全面 RBF 的使用场景。

工作机制[32]

当系统收到替换交易时，会创建一个新的临时交易集群（cluster），这个集群包括所有会受到影响的交易（包括有可能被替换的那一笔）。
系统会根据新的集群版本生成新的分块（chunking），之后对各块的费用收益进行计算。
新的分块收益会和内存池中原有的分块（不包含可能被替换的交易）进行对比。
如果新建的临时交易集群分块在任意数据大小（vbytes[16][23]）情况下所能赚取的费用收益不低于原来的集群，且因发起新的替换交易增加的总手续费（对整个内存池来说的手续费）足够支付广播和中继费用，则被替换交易会被接受。

实际被采用情况

Post-cluster package RBF 作为一种优化 RBF 的方案在 2023 年 12 月的讨论中提出[14][15]，并最终由 Sipa 归纳[32]。目前集群内存池依旧在被完善的过程中，2024 年 6 月，Bitcoin Core #28984 将为大小为 2（一个父交易、一个子交易）的 Post-cluster package RBF 提供支持，其中也包括 v3 交易。这些交易集群只能替换一个已存在的同等大小或更小的集群。目前关于 Post-cluster Package RBF 的帖子依然被热切讨论。

梳理完这些分类不难发现，RBF 的发展逻辑始终围绕「规则清晰度」与「激励兼容」展开：从早期试图折衷、却未被采纳的 FSS，到如今以集群内存池为代表的算法化费率排序，比特币正逐步压缩模糊的中间地带。但规则的清晰化从来不是无代价的，每一次「模糊地带」被填平，都意味着某些依赖它的角色必须重新适应。

RBF的影响

这种「重新适应」具体发生在谁身上、又以什么形式发生？本章我们将跳出技术细节，分别从用户、矿工与矿池、以及钱包与协议开发者三个视角，梳理 RBF 的收益与代价。

对用户

优点

1.运行 RBF 可以使用户交易被阻时拥有可选择的解决方案，从而提升用户体验

2.相比于 CPFP，由于 RBF 占用区块空间较少，且无需额外构造交易，所以对用户来讲是一种更加省钱的方案，在多方交易中尤为突出

缺点

作为交易接收方的用户，零确认支付风险增加
替换交易后 txid 的变化容易给用户造成误解，从而使下游交易失败

对矿工和矿池

优点

RBF 可以使手续费的竞价更加自由，鼓励用户根据市场情况进行手续费调整，从而提高矿工的收入
相比 CPFP，RBF 对区块空间的利用效率更高，为矿工处理交易带来一定的便利
更高的手续费及健康的市场机制可以提高矿池的整体收益
集群内存池的影响:集群内存池将相关的未确认交易划入「集群」管理，使矿工能以统一、高效的算法找出当前收益最高的交易组合，让节点对内存池的排序与矿工实际构造区块的逻辑更好地对齐。一种合理的推论是,当客户端默认就提供接近最优的排序时,矿工自行开发私有排序逻辑的动力也会相应降低（仍属预期，尚未有明确的实证。）

对其他生态参与者

对钱包开发者：需要在构建产品时添加 RBF 相关的功能，如考虑 RBF 相关的内容在 UI/UX上如何丝滑体现
对协议开发者：RBF 不只是一项交易功能，它正成为协议安全模型必须纳入考量的一部分。围绕 Full RBF，一系列内存池策略改革集中落地，重塑了二层协议的开发条件。

v3 交易：全面 RBF 落地后，v3 交易对未确认交易施加「最多一父一子」的限制，已随 Bitcoin Core 28.0 成为标准策略。在 Full RBF 提供的「无需信号即可替换」基线之上，它解决了v3 类型的交易钉死攻击，使 L2 协议无需再为内存池限制专门写「补丁」代码。
Package Relay：交易包中继允许「父子交易」作为整体替换。它解决的核心问题是：旧机制下低费率父交易可能因达不到最低中继费而进不了内存池，导致子交易无从补贴。整体评估交易包后，复杂 L2 协议在极端拥堵下仍能靠子交易「加钱自救」。
赋能预签名协议：Ark 等较新的二层协议高度依赖预签名交易。用户持有事先签好的单方退出路径以保证资金安全。由于这类交易在广播时重新构造或重签的难度较大，其费率调整更依赖广播时的 CPFP。 Full RBF 提供的统一替换环境，加上 v3 交易、Package Relay 带来的可预测、抗钉死的交易包中继能力，共同降低了这类协议因费率波动而面临的传播不确定性。
降低开发门槛：集群内存池(2025 年 11 月合入 Bitcoin Core 主干)以统一的集群费率排序取代了原先分散的替换规则，开发者不必再逐一处理复杂的边缘案例，编写安全二层协议的难度随之下降。

对接受比特币支付的商家：由于零确认支付风险增加，商家必须考虑等待一次确认支付，如需更快捷高效的解决方法需要开始转向闪电网络

此外，社区也在致力于进一步优化手续费估算体系，以提高交易确认效率、用户体验、安全性、和资源利用效率。

展望

自 2022 年 Bitcoin Core 24.0 引入 -mempoolfullrbf 选项、允许节点主动启用全面 RBF 后，经过 2023 年围绕采用情况、矿工激励、零确认支付风险等的持续争论，到 2024 年 Bitcoin Core #30493 将全面 RBF 设置为默认策略，最终 Bitcoin Core #30592 移除 -mempoolfullrbf 选项。全面 RBF 已经从一项备受争议的可选节点策略，演变为了当下的比特币内存池中的阶段性现实。不过，这并非故事的结束。如果要为 RBF 的演化归纳一条主线，那么比特币内存池策略的设计重心，正从「保护零确认支付」转向「优化矿工激励兼容性与二层协议安全」。全面 RBF 确立了这一方向，v3 交易、Package Relay、集群内存池则是与之共同构成这一轮内存池策略改革的关键组成部分。

这一转变在协议层仍在继续。通过改进 LND 的 sweeper 系统，替代循环攻击的成本已大幅提高，在默认参数下攻击者通常需付出至少 HTLC 金额约 20 倍的代价，才能成功实施一次替代循环攻击。与此同时 LND 也引入了[27]基于 BOLT[28] 提案的 RBF 协作关闭流程，允许任意一方是用自己的通道资金来提高手续费[35]。因此，重读这份梳理，意义已不只是回顾一项功能的历史。全面 RBF 既是一段争议的终点，也是一轮更深改革的起点；它从争议走向共识的治理历程，也为理解当下 OP_RETURN 等议题的新一轮分歧，提供了一个可参照的样本。

致谢

在本文的完成过程中，我得到了许多支持和帮助。由衷感谢曾汨老师，姚翔老师，刘锋老师对本文提出的修改意见以及支持，感谢 Raphina 对资料的检索、制作时间线图。衷心地感谢各位对我的耐心和鼓励，让我能够坚定信心顺利完成这篇文章。

手续费替换在比特币生态的演化之路

简介

背景与概念

背景

概念解释

RBF(Replace-By-Fee)

CPFP(Child Pays For Parent)

CPFP与RBF使用场景的区别[11][24]

演化历程

早期探索

全面 RBF 的提出和争议

RBF变种的提出和部分技术讨论

RBF的变种

其他技术讨论

RBF 的分类及发展

分类

选择性 RBF（Opt-in full-RBF，以下简写为Opt-in RBF）

BIP-125[3]

RBF-FSS (RBF First Seen Safe)

Time-based RBF

全面 RBF[5]

Post-cluster Package RBF

RBF的影响

对用户

对矿工和矿池

对其他生态参与者

展望

致谢

相关概念解释

参考信源

最新文章

留言