Replace-By-Fee: An Evolutionary Path in Bitcoin

Author: Robin Wang

Foreword  

This report by Robin traces the evolution of fee-bumping mechanisms in Bitcoin, offering a detailed comparison of the strengths and weaknesses of RBF and CPFP. It then introduces and analyzes the various RBF variants, explaining why full RBF ultimately gained widespread adoption. The report closes by assessing the impact of full RBF's adoption on users, miners and mining pools, and other participants in the ecosystem. Throughout, it illustrates the strategic interplay behind how "rules" evolve within the Bitcoin protocol, in the hope of helping readers develop a deeper understanding of Bitcoin. As a note to the reader: full RBF reached widespread adoption while this report was being written, so its framing and structure were revised several times before settling into its final form as a retrospective study.  

- Xiang Yao

Introduction

The scarcity of block space gave rise to a fee market, and Bitcoin's decentralized design lets users compete through fee bidding to decide whose transactions get confirmed first. Under market volatility, how to handle unconfirmed transactions has become one of the core questions for Bitcoin's user experience and protocol design. The common solutions to this are RBF (Replace-by-Fee) and CPFP (Child Pays For Parent). Among these, RBF allows the creator of a transaction to proactively raise the fee and replace the original, while CPFP works by constructing a follow-up transaction that incentivizes miners to confirm the unconfirmed one. Although both mechanisms can improve a transaction's odds of confirmation, the replacement behavior RBF allows has reshaped how people think about unconfirmed transactions, sparking debate over transaction finality, double-spend risk, and node policy. This article therefore takes RBF as its main thread, covering its mechanics, evolution, and impact on the Bitcoin ecosystem, with a brief look at CPFP as well.

This article was first drafted between late 2022 and early 2023. At the time, the community was deeply divided over the development of Full RBF, with significant disagreement around assumptions about zero-confirmation payments, miner incentives, and the security of upper-layer protocols. Mapping out the different positions on RBF and tracing its evolution was, back then, a grounded and practically oriented effort. As the discussion continued to develop, the writing and revision of this article spanned a considerable period. By the time it was finally completed, Full RBF had shifted from being a subject of controversy to becoming an essential prerequisite for subsequent policies and mechanisms such as Cluster Mempool. Accordingly, this article preserves the survey of contested viewpoints and their evolution, while also attempting to reinterpret RBF's place in the evolution of Bitcoin from a present-day perspective.

Full RBF has now been deployed, and fee-related optimization is entering a new phase, with reforms such as Cluster Mempool continuing to advance. Revisiting the development and evolution of RBF not only helps explain why this new round of changes is unfolding in its current direction, but also offers a renewed understanding of the trade-offs and reasoning the Bitcoin community has worked through on transaction relay, fee management, and protocol security.

Background and Concepts

Fee-market volatility often leaves low-fee transactions stuck in the mempool. To address this, Bitcoin has developed two core strategies: RBF (Replace-By-Fee) and CPFP (Child-Pays-For-Parent). This chapter unpacks the underlying logic of these two mechanisms and clarifies the technical boundaries between them. The distinction is not just a matter of classification; it also matters for the more complex protocol designs discussed later, where selecting the right strategy for different transaction-competition environments is what allows transactions to be reliably driven to confirmation.

Background

In the Bitcoin network, once a transaction is initiated it is first broadcast to nodes and enters the mempool, and it is not considered confirmed until a miner packages it into a new block. However, in some small-value, speed-sensitive scenarios, the recipient may release goods as soon as a transaction enters the mempool, without waiting for block confirmation which is known as a “zero-confirmation payment.” It relies on the assumption that “a broadcast transaction will not be easily replaced,” and this very assumption is one of the focal points of the Full RBF debate discussed later. The higher the fee a transaction pays, the more likely it is to be included by miners. Transaction fees are not a fixed amount but are formed through open bidding in the market. In other words, the more transactions occur at the same time, the more candidate blocks miners can choose to mine. For miners, the rational choice is to mine blocks containing higher-fee transactions in order to earn more in fees.

A transaction may sit in the mempool for a long time because its fee was estimated too low, or because the network suddenly became congested after it was sent. In ordinary payment scenarios, this means confirmation delays and a degraded user experience; in certain protocol scenarios, the relevant transactions are also subject to time-window constraints, making it hard to accurately estimate the fee needed at confirmation time. In such cases, whether a transaction can be confirmed quickly is not merely a matter of user experience but directly affects fund safety: examples include the timely on-chain confirmation of a commitment transaction or an HTLC (Hash Time Locked Contract) in the Lightning Network, or topping up collateral in on-chain protocols. Because these transactions are often pre-signed long before they are broadcast, the prevailing fee at the time of broadcast may have already changed; any confirmation delay can therefore lead to financial loss or exploitation by counterparties. In such situations, if a user cannot raise the fee, they have no choice but to wait passively, which seriously degrades the user experience.

The handling of unconfirmed transactions may look like a matter of fees on the surface, but it actually touches on a much wider set of questions: whether nodes will accept a replacement, how miners weigh their revenue choices, how recipients evaluate the risk of zero-confirmation payments, and how underlying protocols like the Lightning Network design their transaction and fee-bumping paths. For this reason, revisiting the evolution of RBF today is not just about looking back at the debate over whether full RBF should be adopted, it's also about understanding why subsequent policies and mechanisms, such as v3 transactions, have continued to develop in their current direction.

Concepts

RBF (Replace-By-Fee)

Replace-By-Fee is a node policy. (Hereafter referred to as RBF.)[4]

When a transaction is broadcast with too low a fee, it may be delayed for a long time or never get processed at all, becoming what's known as a stuck transaction. To address this problem, we can turn to a method known as "fee replacement.” The user constructs and signs a replacement transaction that spends one or more of the same inputs as the stuck transaction[1] and pays a higher fee. This gives miners a stronger incentive to include the transaction in a block, allowing it to go through.

Figure 1: The Concept of RBF

CPFP (Child Pays For Parent)

Child Pays For Parent (CPFP) is a fee-bumping mechanism in which a user spends the output of an unconfirmed transaction (the parent) as the input of a new transaction (the child). The child transaction carries a sufficient fee, raising the combined fee rate of the parent and child. The newly created high-fee child effectively subsidizes the low-fee parent. When selecting which transactions to package into a block, miners consider the transaction “package” as a whole and look at the overall fee rate of the entire package[1] — thereby being drawn to process the transaction at the higher combined fee rate.

CPFP is more complex than RBF and harder to manage in practice. It cannot directly target a specific fee rate; instead, the user must work backward from the parent transaction's size and the fee it already paid to calculate how much the child transaction needs to pay. It also requires a spendable unconfirmed output to work with. And because both the parent and child transactions need to be confirmed on-chain, it consumes more block space than RBF, which simply replaces the original transaction.

Differences between CPFP and RBF use cases[11][24]

When to Use RBF	When to Use CPFP
/	Allows spending the outputs of unconfirmed transactions
Allows adding a new recipient or changing the payment destination	Does not allow adding a new recipient or changing the payment destination
For users who are fine with the transaction ID changing	For users who don't want the transaction ID to change
Lets the sender raise the fee	Lets the recipient raise the fee
Best for those who want a lower final fee — typically 30%–90% less than CPFP	Fine for those who don't mind a higher final fee, especially in multi-party payments

Table 1：RBF vs. CPFP use cases

Ultimately, RBF is "in-place optimization" through input replacement, while CPFP is "joint incentivization" through output linkage. Understanding the trade-offs between the two is the starting point for unpacking the logic behind more complex protocol designs that came later, such as the Lightning Network and Ark.When these mechanisms were first introduced, however, they were far from as mature as they are today. They sparked heated debate over "zero-confirmation safety" and exposed underlying vulnerabilities like "transaction pinning." To address these challenges, Bitcoin's transaction relay rules went through a long and contentious evolution.

Evolution

In this chapter, we'll trace how RBF evolved—step by step—from a feature originally disabled by Satoshi into one of the core mechanisms underpinning Bitcoin's mempool policy today. Behind this thread of evolution lies intense debate among community members over miner incentives, policy compatibility, and node relay rules, along with a recurring tension between "protecting zero-confirmation payments" and "improving the efficiency of the fee market.”

Figure 2: Timeline of Key RBF Discussions and Events

Early Exploration

In Satoshi’s original code, the Bitcoin implementation provided an nSequence field on each input so that transactions including that input could be replaced in the mempool. When receiving a replacement, nodes were supposed to replace a transaction whose input had a lower sequence number with one whose input had a higher sequence number.

Under this implementation, replacement transactions weren't required to pay any additional fee, so miners had no direct incentive to include them, and there was no built-in rate limiting to prevent abuse of relay node bandwidth. Satoshi removed the replacement feature in Bitcoin version 0.3.12, leaving only a comment that read "Disable replacement feature for now."[3]

To address these issues, community developers including Peter Todd created a variant of RBF called RBF-FSS (First-Seen-Safe RBF), which required replacement transactions to pay all the same outputs as the original transaction, or more. In practice, however, RBF-FSS required adding extra inputs: each fee bump meant adding more inputs, which further increased the transaction's size and pushed the fee higher still. Many wallets didn't have spare UTXO inputs available, making the strategy unusable for them, and frequently adding inputs also created privacy risks. As a result, RBF-FSS was never adopted in practice.[2]

Opt-in RBF was later proposed in BIP-125 in 2015. It used Satoshi's original semantics with a slight adjustment that allowed timelock users to opt out to signal that replacement was possible. This gave first-seen users the ability to ignore such transactions, while still preserving the efficiency advantages of full RBF[3]. BIP-125 was implemented in Bitcoin Core version 0.12.0 in 2016[29].

The Full RBF Proposal and the Controversy Around It

	2022 view	Background
Antoine Riard	Leans toward supporting Full RBF. In multi-party (coinjoin-type) transactions, if one participant initiates a non-replaceable, non-RBF transaction with a very low fee, the transaction can sit in the mempool indefinitely and block progress. Full RBF would resolve this.	Bitcoin Core developer; primary research focus on RBF and the Lightning Network[9]. Key member of consulting firm TheLab31.
Suhas Daftuar	Summarized arguments against Full RBF, and later raised many such objections in his PRs.[7]	Co-founder of Chaincode Labs, one of the largest donors to Bitcoin Core.
Jeremy Rubin	Supports running Full RBF nodes; encouraged the shift to Full RBF; outlined alternatives to BIP-125 opt-in RBF in mailing list posts.	Founder of Judica, which supports Bitcoin research and development. Main focus: Sapio, a Bitcoin smart-contract programming language.
Gloria Zhao	Supports running Full RBF nodes; actively posted on the topic early on, and later worked deeply on optimization strategies.	Bitcoin Core developer focusing on mempool and peer-to-peer logic, with particular attention to L2 security.
Larry Ruane	Leans toward supporting Full RBF; discussed whether replacements could be performed without changing a transaction’s txid.	Bitcoin Core developer; contributor to many open-source projects.
Peter Todd	Supports running Full RBF nodes; co-author of BIP 125.	Bitcoin Core developer; founded OpenTimestamps.
Dario Sneidermanis	Supports running Full RBF nodes, but believes the application layer needs to be properly notified so it can prepare in advance.	Founder of Muun Wallet.
Sergej Kotliar	Opposes Full RBF; defends the practical utility of zero-confirmation payments, which he argues has been validated in production. Also notes that Full RBF could introduce free-option problems.	Founder and CEO of Bitrefill.
John Carvaho	Opposes Full RBF; argues that it would make zero-confirmation payment risk harder to manage.	CEO of Synonym; formerly CCO of Bitrefill.
Anthony Towns	Leans toward supporting Full RBF nodes.	Bitcoin Core developer; formerly a Red Hat release engineer and Debian developer.

Table 1: Key figures in the 2022 Full RBF debate, their positions, and background

As shown in Table 1, In June 2022, Antoine Riard proposed adding a -mempoolfullrbf option in Bitcoin Core 24.0[38]. At the time, Opt-in RBF, anchored by BIP-125, was the mainstream policy on the network. The proposal sparked significant controversy and discussion. If enabled, the option would allow users to configure their individual nodes to relay and mine unconfirmed transaction replacements even when the replacement transaction did not include the BIP-125 signaling flag.[6] The debate continued through 2022. Dario Sneidermanis posted concerns that Full RBF and -mempoolfullrbf could cause problems for businesses accepting unconfirmed payments, such as Muun, and suggested that more time was needed to prepare. Sergej Kotliar defended zero-confirmation payment schemes, arguing that the current double-spend success rate is extremely low and that zero-confirmation payments have been commercially proven to transact safely; John Carvalho expressed a similar view. Anthony Towns supported Full RBF but agreed not to immediately enable the option on mainnet, proposing instead to deploy it first on testnet, and laid out an implementation timeline. In late November 2022, Bitcoin Core released version 24.0 with the option included.

Then in 2023, Peter Todd ran a test and found that around 17% of nodes had manually flipped -mempoolfullrbf from false to true, citing sites like mempool.space as supporting evidence.[13] Anthony Towns followed up on the thread regarding the motivations behind full RBF with a more detailed explanation. Towns pointed out that, from a short-term perspective, higher fees are certainly more attractive to miners—but miners who have made long-term capital investments in mining equipment may be more inclined to optimize fee revenue across multiple blocks. With this in mind, he laid out three possible scenarios in which full RBF would have different effects on the system as a whole:

1. Optimistic scenario:

   • Transaction volume and the existing fee level remain unchanged

   • Users can more easily cancel or replace mistaken transactions

   • Users no longer complain to wallet developers about slow RBF confirmations

   In this case, implementing full RBF would have no noticeable negative impact and could even improve the user experience while increasing miners' fee revenue.

2. Neutral scenario:

   Most users who currently make on-chain Bitcoin transactions would shift to layer-2 payment solutions such as the Lightning Network, leading to a decline in on-chain transaction volume and, consequently, lower fee revenue. If this scenario unfolds, on-chain transaction volume would shrink, but because the activity would simply move to layer 2, the overall impact on Bitcoin would be limited.

   In this scenario, Full RBF could attract broader community support. RBF’s role in raising fees to incentivize miners becomes less important here, but the scenario is actually more favorable to Full RBF in other ways:

   • While transactions are unconfirmed, RBF somewhat increases double-spend risk. If on-chain activity declines and users move to the Lightning Network — which uses mechanisms such as HTLCs to prevent double-spend attacks — using RBF to replace transactions does not directly undermine Lightning Network security.

   • With fewer on-chain transactions, pressure on block space eases, and RBF can further improve block-space utilization. Full RBF therefore becomes easier to push forward.

3. Pessimistic scenario:

   A large number of users switch to other cryptocurrencies or stablecoins for payment convenience. In that case, the discussion about Full RBF measures loses its relevance.

In August 2023, Peter Todd proposed switching Opt-in RBF to Full RBF. His measurements showed that a significant share of mining hashrate already followed Full RBF rules and that enough relay nodes had enabled Full RBF to let non-signaling replacements reach those miners. He listed pools applying Full RBF, including Foundry USA, Antpool, and Binance pool[13]. He pushed back on earlier claims that Bitrefill accepted unconfirmed transactions as final payment, stating that no active business currently accepts an unconfirmed on-chain transaction as final settlement[12], and he replied to the earlier zero-conf discussions.

In March 2024, BitGo announced that its wallet and API supported RBF, and provided its users with a detailed introduction and walkthrough of how to use it.[22]

In the second half of 2024, Bitcoin Core #30493 made RBF the default setting, while keeping opt-in RBF as a restorable option for node operators. In November, Bitcoin Core #30592 removed the -mempoolfullrbf option.

RBF Variants and Related Technical Discussions

RBF Variants

Post-cluster Package RBF discussion

In discussions on the cluster mempool, Daftuar[21] compared Bitcoin Core's existing RBF rules with the proposed cluster mempool RBF rules and found that, overall, the differences were small. That said, the newly proposed RBF rules protected the mempool to the maximum extent from an incentive-compatibility standpoint, specifically against incentive-incompatible replacements. In theory, it's now possible to block replacements that look better on the surface but would actually trigger undesirable behavior, a scenario that wasn't foreseeable back when BIP-125 was implemented.

Kindred RBF discussion

In January 2024, the topic of Kindred RBF drew widespread discussion. The conversation leaned toward introducing a new RBF mechanism in v3 transactions to either replace or de-emphasize the CPFP carve-out—the latter being a mempool exception rule that allows one additional small CPFP child transaction from an honest party to pass through, even when the descendant count limit has been reached, in order to mitigate the issue of anchor transactions being pinned by a counterparty. Compared with the traditional notion of replacement based on direct input conflict, Kindred RBF[19] refers to one transaction being able to replace another in the mempool when the two do not conflict but share a kinship relationship. Its main form is “kindred eviction” — an unconfirmed child transaction can replace another child. Kindred RBF was proposed as an optimization of CPFP carve-out, and is also better suited for implementation under a future cluster mempool. The rough flow:

• In the Lightning Network, Alice can send a commitment transaction together with a child transaction to pay the fee

• Alice can raise the fee by replacing the original child transaction

• Bob can use Kindred RBF to evict Alice’s child from the mempool by broadcasting a child transaction he constructs with a higher fee

• Alice can in turn build a higher-fee child to perform Kindred RBF on Bob’s transaction and evict it

If this approach is implemented, the CPFP carve-out policy would be removed from Lightning Network anchor transactions. So far, there has been little opposition.

Some have asked whether implementing this approach would make ephemeral anchors unnecessary. However, Gregory Sanders, the author of ephemeral anchors, noted that he would continue his optimization work, since zero-sat outputs still have use cases beyond the Lightning Network.

RBFr discussion

Peter Todd proposed One-Shot Replace-By-Fee-Rate (RBFr). The proposal aims to provide a set of methods that allow a transaction to be replaced in situations where existing RBF rules would not permit it. He suggested two different strategies:

1. Pure Replace-By-Fee-Rate (pure RBFr): a transaction in the mempool can be replaced by a conflicting transaction that pays a significantly higher fee rate (for example, twice the fee rate of the replaced transaction).

2. One-Shot Replace-By-Fee-Rate (one-shot RBFr): a transaction in the mempool can be replaced by a conflicting transaction paying a moderately higher fee rate (e.g., 1.25×), provided the replacement’s fee rate is also high enough to place it within the top 1,000,000 bytes of the mempool (meaning that if a block were generated immediately after the replacement was accepted, it would be mined directly)[20].

Mark Erhardt and Peter Todd subsequently discussed abuse risk, noting that an attacker could consume unlimited node bandwidth at very low cost. Peter then updated the proposal, adding new RBF restrictions that addressed the potential risk of attackers wasting unbounded node bandwidth at minimal cost. Gregory Sanders and Gloria Zhao raised additional concerns. Sanders believes that pursuing reasoning along this direction before cluster mempool is implemented would yield only marginal benefits. Before fully abandoning the idea of free relay protection, he argues, more thought should be given to handling RBF's incentive mechanisms correctly.

Gloria pointed out that the existing mechanism doesn't support calculating incentive compatibility or precise scoring for miners, because there's no limit on the size of transaction clusters. One of the advantages of cluster mempool is that it can impose certain limits on cluster size, and v3 transactions can serve as a simulated test case for this problem before cluster mempool is rolled out, since v3 transactions can introduce cluster limits (such as a limit of 2) ahead of time. She noted that one-shot replacement by fee rate is not a viable solution, as it neither addresses the free-relay problem nor can it be implemented accurately. Following this, Peter Todd published an experimental implementation for replacement by fee rate.

Other Technical Discussions

In February 2023, Bitcoin Core #25344 updated the bumpfee and psbtbumpfee RPCs used for RBF fee-bumping. The update allows outputs to be specified in the replacement transaction, meaning the output set of the replacement can differ from that of the original. This can be used to add new outputs (for example, in iterative payment batching) or to remove certain outputs (for example, to try to cancel an unconfirmed payment)[10].

In October 2023, there were four RBF-related discussion topics in the community:

1. Matt Corallo suggested that miners retain a record of transactions they have seen, so that if an important transaction is stuck in an unconfirmed state due to transaction pinning or network attacks, miners can choose to process those transactions again. Bastien Teinturier agreed, adding that improvements should be pushed down to Bitcoin’s base layer to provide guarantees for L2. Antoine Riard expressed a similar view: a sustainable solution can only be implemented at the base layer, for example by adding a memory-heavy visible transaction history[17].

2. Pre-signed fee bumps:

   Peter Todd argued: “the correct way to do pre-signed transactions is to pre-sign enough different transactions to cover all reasonable needs for bumping fees. […] There is zero reason why the B->C transactions should be getting stuck.”[8] That is, multiple transaction versions can be pre-signed and later broadcast based on network conditions. For example, if Bob and Mallory B execute an HTLC, they would prepare different transactions at fee rates of 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, and 1024 sats/vbyte and broadcast whichever one is appropriate. With this approach, because the transactions are already signed, inputs cannot be modified to perform RBF; even without RBF, this pre-signed payment pattern does not directly cause transactions to get stuck.

3. Effect of replacement cycling attacks[18] on HTLCs:

   Replacement cycling attacks generally refer to attackers exploiting protocol vulnerabilities (specifically RBF, in this case) to cause transactions to be replaced multiple times, affecting confirmation and completion. Typically, attacker Mallory and Bob share an HTLC output; when Bob spends that output, Mallory can immediately replace her own transaction input so that Mallory’s input no longer contains the shared output. Mallory can replace her transaction so that Bob cannot revoke his spend within the required time.

   Because of the HTLC mechanism, Bob may be forced to close the channel and pay fees, while the attacker captures the proceeds.

   The impact of replacement cycling on LN nodes is similar to existing transaction pinning. However, techniques designed to prevent pinning attacks in LN and similar protocols[25] (such as v3 transaction relay) cannot prevent replacement cycling.

In 2024, Peter Todd posted on the mailing list to open a discussion on the output type for Pay-to-Anchor (P2A). Pay-to-Anchor (P2A) is part of the ephemeral anchor proposal. P2A is an output that anyone can spend, which makes it particularly useful for fee bumping via CPFP in multi-party protocols such as the Lightning Network.

However, in the current Lightning Network, fee bumping via CPFP has a vulnerability: a counterparty can launch a two-stage attack known as a Replacement Cycle Attack. The steps are:

• The counterparty replaces the legitimate user's transaction with one of their own (the two transactions are largely identical in version content)

• The counterparty then replaces their own transaction with another one that has nothing to do with either party's earlier versions

When unresolved HTLCs exist in a Lightning Network channel, a single replacement can allow the attacker to steal funds from the legitimate user. In some cases, this attack is essentially free—for example, when the attacker was already planning to broadcast a transaction with a higher fee rate, and none of the versions get confirmed on-chain by a miner before the replacement cycle completes.

Among existing Lightning anchor output types, only the counterparty can carry out this attack. Todd noted that, in theory, since P2A is an output anyone can spend, anyone could in theory initiate it. But in practice only the transaction counterparty stands to gain economically, so others have no incentive to launch the attack.

All replacement-cycling mitigations currently deployed in the Lightning Network[26] remain effective against P2A.

From being disabled by Satoshi early on over security concerns, to becoming the network-wide default consensus rule, RBF’s evolution reflects a deeper shift in Bitcoin’s underlying logic: the network no longer relies on relay-layer policy to maintain stable expectations around zero-confirmation payments, and has instead moved toward a more transparent, more incentive-aligned game-theoretic model.With this, RBF has completed its transition from an “optional plugin” to “infrastructure.” It has not only changed how fees on unconfirmed transactions can be adjusted, but has also given rise to a series of technical variants.

Classification and Development of RBF

In this chapter, we first survey the various variants that emerged during this evolution: some were adopted by mainstream clients, while others stayed at the discussion stage. Each of them, however, corresponds to a specific problem the community was trying to solve at a particular time.

Classification

Figure 3: Classification of RBF

Opt-in RBF (Opt-in full-RBF, hereafter abbreviated as Opt-in RBF)

Concept

Opt-in RBF allows the creator of a transaction to signal that they are willing to have the transaction replaced by a higher-fee version until it is confirmed in a block.

Design rationale

In the most primitive transaction-replacement policy, replacing a transaction required no extra fee and there was no built-in rate limit. Under such a design, miners had no incentive to include a new replacement. BIP-125 gave users a defined way to do fee replacement, with rules far more granular than the original version.

BIP-125[3]

BIP-125 introduced the concept of Opt-in RBF. It allows the sender of a transaction to add a signal indicating that they want the transaction to be replaceable later, so they can handle unexpected network delays or any other situation that calls for a replacement.

Implementation details

A replacement transaction must meet the following conditions to replace a transaction in the mempool:

1. The original transaction is explicitly marked as replaceable, or inherits replaceability.

2. The replacement transaction must include the same unconfirmed inputs that were in the original transaction.

3. The absolute fee paid by the replacement transaction is at least equal to the amount paid by the original.

4. The replacement transaction must also pay for its own bandwidth at or above the node’s minimum relay fee rate.

5. The total count of the original transaction plus the descendants that would be evicted from the mempool must not exceed 100.

Sender and recipient wallet principles

In response to this signal, nodes may allow transactions carrying it to be replaced in their mempool.

• If a sending wallet does not want to emit a replaceability signal, it should use the maximum sequence number (0xffffffffffff) or sequence (0xffffffffff-1).

• Nodes and recipients can choose to ignore such transactions and proceed normally, or, when encountering a transaction carrying this signal, choose not to treat it as payment until it is confirmed.

Motivation

At a micro level, by requiring the replacement transaction to pay a higher fee, BIP-125 provides a way to align miners’ interests with the sender’s intent, improving network efficiency.

Importance

• Improved user experience. Senders can include a signal in their transaction indicating intent to replace. Recipients can choose to treat such transactions as payment only after confirmation, or to ignore them.

• Greater transaction flexibility. Users can raise the fee to adjust costs when network conditions change.

Pros

1. Provides a flexible way to adjust fees

2. Relatively low risk for zero-confirmation payments

Potential weaknesses

1. Still has an impact on zero-confirmation payments

2. Bound by the opt-in rules — a transaction must be flagged before it can be replaced, which is more cumbersome than Full RBF

Adoption

The BIP-125 proposal was created on December 4, 2015 and, after discussion, was rolled out in Bitcoin Core 0.12.0 in February 2016. Opt-in RBF remained in use until November 2024, just before Full RBF saw widespread adoption.

RBF-FSS (RBF First Seen Safe)

Concept

FSS (First Seen Safe) means that once a transaction has been broadcast to the network and seen by other nodes for the first time, it is treated as safe — i.e., it will not be replaced or modified.

Design rationale

A transitional proposal aimed at the risks introduced by changes in user habits resulting from Opt-in RBF.

Mechanism

RBF-FSS requires the replacement transaction to pay at least the same amount to the same addresses; the replacement must include all of the same outputs as the current transaction, with an additional input added to pay the extra fee.

Pros

1. Allows fees to be adjusted

2. Preserves the safety of zero-confirmation payments

Potential weaknesses

1. Propagation is highly sensitive to network conditions, so users cannot easily predict whether a replacement will succeed; the experience is unstable

2. Each replacement requires an extra input, enlarging the transaction and pushing the fee higher.

3. Many wallets have no spare UTXO inputs and cannot use this strategy.

4. Frequently adding inputs reduces privacy, because UTXOs from different sources end up aggregated in the same transaction.

Adoption

Although RBF-FSS was proposed amid controversy as a transitional alternative to Opt-in RBF, it was never implemented in practice. Bitcoin Core implemented Opt-in RBF directly.

Time-based RBF

Concept

Time-based RBF is another strategy based on RBF-FSS: once a transaction is first seen, the FSS policy is enforced for a fixed number of blocks; only if the transaction has not been mined in that window is RBF replacement allowed[2].

Mechanism

When a transaction is broadcast to the network, the node records its “first seen” time (in block height).Within a configured number of blocks N, the node accepts only the first-seen transaction and does not allow RBF replacement.Only if the transaction has not been mined into a block after N blocks does the node allow a new higher-fee transaction to replace the original.

Design rationale

The proposal aims to balance two needs: protecting the recipient by ensuring the transaction cannot be replaced in the short term — lowering double-spend risk — while still allowing the sender to use RBF to speed up confirmation when the transaction has been stuck for a long time.

Actual adoption

Time-based RBF was only ever a discussed strategy and was never implemented in mainstream Bitcoin clients.

Full RBF[5]

Concept

Compared with Opt-in RBF, Full RBF does not require a signal to be added to the transaction in order to allow replacement.

Design rationale

Provides a way to replace stuck transactions when the network is congested or when a transaction’s fee is too low, thereby speeding up confirmation.

Mechanism

1. The replacement transaction must spend at least one of the same inputs as the original

2. The replacement must pay a fee equal to or greater than the original

3. The other BIP-125 rules apart from the explicit opt-in signal still apply

Pros

1. Compared with CPFP, RBF saves more on cost and block space

2. Compared with Opt-in RBF, Full RBF allows replacement without an opt-in signal

3. Full RBF benefits the development of Layer 2 protocols such as the Lightning Network

4. Paves the way for future fee-estimation optimizations

Potential weaknesses

1. Adopting Full RBF significantly reduces zero-confirmation payment security(Ed.: zero-confirmation payment security refers to the ability to resist RBF double-spend attacks, i.e. after the merchant releases the goods, the payer broadcasts a fee-bumped double-spend transaction that overrides the original)

2. Unlike CPFP, RBF also changes the transaction’s txid, invalidating downstream transactions that depend on the original txid

Adoption

After ongoing community discussion and refinement, Full RBF gradually became mainstream from 2024 onward. In November, the -mempoolfullrbf option was removed, marking the broader adoption of Full RBF.

Post-cluster Package RBF

Concept

Post-cluster Package RBF is an extension of Full RBF. RBF itself tends to resolve the case of a single stuck transaction, whereas Post-cluster Package RBF focuses on the total revenue of an entire cluster.

Cluster Mempool[31]

The cluster mempool is a proposal that links every unconfirmed transaction in the mempool with its related transactions, forming a cluster.

Design rationale

Post-cluster Package RBF provides better optimization and support for complex use cases such as the Lightning Network and CoinJoin, expanding the situations in which Full RBF is useful.

Mechanism[32]

• When the system receives a replacement transaction, it creates a new temporary transaction cluster that includes all transactions that would be affected (including the one that might be replaced).

• The system generates new chunks (chunking) based on this new cluster version and computes the fee revenue per chunk.

• The new chunk revenue is compared against the existing chunks in the mempool (excluding the transaction that may be replaced).

• If, at any data size (vbytes[16][23]), the new temporary cluster’s chunks can earn at least as much fee revenue as the original cluster, and the additional total fees from the new replacement (mempool-wide) are enough to cover broadcast and relay costs, then the replacement transaction is accepted.

Adoption

Post-cluster Package RBF was proposed as an RBF optimization in discussions in December 2023[14][15], and was ultimately consolidated by Sipa[32][32]. The cluster mempool is still being refined; in June 2024, Bitcoin Core #28984 added support for Post-cluster Package RBF for cluster size 2 (one parent and one child), including v3 transactions. These transaction clusters can only replace an existing cluster of the same or smaller size. Posts on Post-cluster Package RBF continue to be actively discussed.

Looking back over these categories, it's clear that the development of RBF has consistently revolved around two themes: rule clarity and incentive compatibility. From the early FSS attempt at compromise, which was ultimately rejected, to today's algorithmic fee-rate ordering represented by cluster mempool, Bitcoin has been steadily compressing its zones of ambiguity. But greater rule clarity has never come without cost: every time a "gray area" gets filled in, some role that depended on it has to readapt.

The Impact of RBF

Who exactly does this “readaptation” happen to, and in what form? In this chapter we step away from technical detail and look at RBF’s gains and costs from three perspectives: users, miners and mining pools, and wallet and protocol developers.

For Users

Pros

1. Running RBF gives users a viable option when their transactions get stuck, improving the overall user experience.

2. Compared with CPFP, RBF consumes less block space and doesn't require constructing an additional transaction, making it a more cost-effective option for users, especially in multi-party transactions.

Cons

1. For users on the receiving end, zero-confirmation payment risk increases

2. The change in txid after replacement can confuse users and cause downstream transactions to fail

For Miners and Mining Pools

Pros

1. RBF makes fee bidding more open, encouraging users to adjust fees based on market conditions, which in turn raises miners’ revenue

2. Compared with CPFP, RBF makes more efficient use of block space, making transaction handling easier for miners

3. Higher fees and a healthier market mechanism raise the overall revenue of mining pools

4. Impact of the cluster mempool: The cluster mempool groups related unconfirmed transactions under “cluster” management, letting miners use a unified, efficient algorithm to identify the highest-revenue transaction combinations and better aligning node mempool ordering with the logic miners actually use to construct blocks. A reasonable inference is that when clients provide near-optimal ordering by default, miners’ incentive to develop private ordering logic of their own should also decrease (this is still an expectation; no clear empirical evidence yet).

For Other Ecosystem Participants

1. Wallet developers: must add RBF-related features when building products — for example, thinking through how to surface RBF-related options smoothly in UI/UX.

2. Protocol developers: RBF is no longer just a transaction feature — it is becoming an integral part of protocol security models. Around Full RBF, a series of mempool-policy reforms have landed together, reshaping the conditions under which Layer 2 protocols are developed.

   1. v3 transactions: With Full RBF in place, v3 transactions impose a “at most one parent and one child” limit on unconfirmed transactions and have become the standard policy in Bitcoin Core 28.0. On top of Full RBF’s “replace without signaling” baseline, v3 solves v3-type transaction-pinning attacks, sparing L2 protocols from writing dedicated “patch” code for mempool limits.

   2. Package Relay: Package relay allows “parent and child” transactions to be replaced as a unit. The core problem it solves: under the old mechanism, a low-fee-rate parent might fail to meet the minimum relay fee and never enter the mempool, leaving the child with nothing to subsidize. By evaluating the package as a whole, complex L2 protocols can still “buy their way out” through a child transaction even under extreme congestion.

   3. Enabling pre-signed protocols: Newer L2 protocols like Ark depend heavily on pre-signed transactions. Users hold pre-signed unilateral exit paths to guarantee fund safety. Because such transactions are hard to reconstruct or re-sign at broadcast time, their fee adjustment relies more on CPFP at broadcast time. Full RBF’s uniform replacement environment, combined with the predictable, pinning-resistant package-relay capabilities provided by v3 transactions and Package Relay, jointly reduces the propagation uncertainty these protocols face under fee-rate volatility.

   4. Lower development barrier: The cluster mempool (merged into Bitcoin Core main in November 2025) replaces the previously scattered replacement rules with unified cluster-fee-rate ordering. Developers no longer need to deal with complex edge cases one by one, lowering the difficulty of writing safe Layer 2 protocols.

3. Merchants accepting Bitcoin payments: with higher zero-confirmation risk, merchants must consider waiting for one confirmation; if they need a faster, more efficient solution, they should start moving to the Lightning Network.

Beyond these, the community is also working to further optimize the fee-estimation system to improve confirmation efficiency, user experience, security, and resource utilization.

Outlook

Since Bitcoin Core 24.0 introduced the -mempoolfullrbf option in 2022, allowing nodes to opt in to full RBF, the policy went through sustained debate throughout 2023 over its adoption, miner incentives, and the risks it posed to zero-confirmation payments. By 2024, Bitcoin Core #30493 had made full RBF the default policy, and Bitcoin Core #30592 ultimately removed the -mempoolfullrbf option altogether. Full RBF has thus evolved from a highly contentious opt-in node policy into a reality of the present phase in Bitcoin's mempool. This, however, is not the end of the story.

If we had to distill the evolution of RBF into a single throughline, it would be this: the design focus of Bitcoin's mempool policy is shifting from "protecting zero-confirmation payments" toward "optimizing miner incentive compatibility and layer-2 protocol security." Full RBF established this direction, while v3 transactions, Package Relay, and cluster mempool together form the key components of this round of mempool policy reform.

This shift is still playing out at the protocol layer. Improvements to LND's sweeper system have substantially raised the cost of replacement cycling attacks: under default parameters, an attacker typically has to spend at least around 20 times the HTLC amount to successfully pull off a single replacement cycling attack. At the same time, LND has introduced an RBF cooperative close flow[27] based on the BOLT[28] proposal, which allows either party to use their own channel funds to bump the fee.[35]

For this reason, revisiting this overview means more than just looking back at the history of a single feature. Full RBF is at once the end of one debate and the start of a deeper round of reform; the way it moved from controversy to consensus also offers a useful reference point for understanding the latest disagreements over topics like OP_RETURN.

Acknowledgments

This article would not have been possible without the support and help of many people. My sincere thanks to Mi Zeng, Xiang Yao, Feng Liu for their suggested revisions and ongoing support, and to Raphina for searching materials and producing the timeline figure. My heartfelt thanks to everyone for their patience and encouragement, which gave me the confidence to bring this article to completion.

Glossary

1. Transaction pinning[36]

   Transaction pinning is a way to abuse the protections nodes have against bandwidth-, CPU- and memory-consumption attacks, making it very expensive to add more fee. When multiple parties have the right to raise the fee on a transaction, an attacker can pin their own transaction at some limit, preventing other participants from bumping the fee via RBF or CPFP.

2. v3 transactions[34]

   Full name: Version 3 transaction relay. v3 transactions follow all standard transaction rules (such as min/max transaction weight), and add some extra rules on top, to allow transaction replacement while preventing transaction-pinning attacks. v3 transactions solve rule-3 pinning attacks, and may make it possible to remove CPFP carve-out (a mechanism used to mitigate pinning), facilitating the development of the cluster mempool. For the specific new rules introduced by v3 transactions, see BIP-0431[35].

3. Ephemeral anchors[37]

   Ephemeral anchors is a proposal that allows certain transactions to be relayed without paying any fee, provided they are part of a transaction package and a child transaction in the package pays enough fee to cover the entire package.

   The proposal is built on top of v3 transactions and is intended for contract protocols (such as the Lightning Network). Transactions in these protocols are signed by contract participants long before being broadcast, making it hard to estimate an appropriate fee rate at confirmation time. Ephemeral anchors let multiple participants — or any participant — use the anchor output to create a child transaction and add fees at broadcast time.

4. HTLC[33]

   HTLC(s), short for Hash Time Locked Contracts, is a conditional-payment mechanism widely used in Lightning Network payment channels, cross-chain atomic swaps, on-chain zero-knowledge conditional payments, and other contract protocols.

   An HTLC has two basic clauses: a payment clause protected by a hash lock, and a refund clause protected by a time lock. To open the hash lock and claim the payment, the recipient must disclose the preimage of the hash digest encoded in the contract; to open the time lock and obtain a refund, the sender must wait until the specific time set in the contract has passed.

   Because the disclosed preimage and a past timestamp do not uniquely identify who should receive the payment, an HTLC is only secure when it also requires a unique signature matching the public key of the sender (refund party) or the designated recipient.

5. Cluster mempool[30]

   The cluster mempool is a proposal that links every unconfirmed transaction in the mempool with its related transactions, forming a cluster. Each cluster contains chunks ordered by fee rate, and each chunk consists of one or more transactions. By bounding cluster size, we can bound the amount of recomputation required when a new transaction enters the mempool, allowing algorithmic decisions that affect the whole mempool to complete more quickly. Compared with CPFP carve-out’s eviction approach, the cluster mempool also improves transaction selection and eviction policies, allowing the mempool to identify the optimal transaction set more efficiently.

References

1. https://www.btcstudy.org/2022/03/17/introduction-to-fee-bumping-by-Bitcoin-Optech/#RBF-的历史

2. https://en.bitcoin.it/wiki/Transaction_replacement

3. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

4. https://bitcoinops.org/en/topics/replace-by-fee/

5. https://en.bitcoin.it/wiki/Replace_by_fee

6. https://bitcoincore.org/en/releases/24.0.1/

7. https://bitcoinops.org/en/newsletters/2022/12/21/#rbf

8. https://bitcoinops.org/en/newsletters/2023/10/25/#presigned-fee-bumps

9. https://muckrack.com/antoine-riard/articles  

10. https://github.com/bitcoin/bitcoin/pull/25344  

11. https://bitcoin.stackexchange.com/questions/117877/best-practices-with-multiple-cpfps-cpfp-rbf  

12. https://gnusha.org/pi/bitcoindev/ZMaFZLW7+HdPVtYW@petertodd.org/  

13. https://github.com/bitcoin/bitcoin/pull/28132 

14. https://delvingbitcoin.org/t/cluster-mempool-rbf-thoughts/156/6 

15. https://delvingbitcoin.org/t/post-clustermempool-package-rbf-per-chunk-processing/190 

16. https://bitcointalk.org/index.php?topic=5454183.0 

17. https://gnusha.org/pi/bitcoindev/CALZpt+GeLLShrJckLG1UMDQ9tMGzqP1pBsUpEZ+82e9wHZGYw@mail.gmail.com/ 

18. https://bitcoinops.org/en/newsletters/2023/10/25/#fn:rbf-warning 

19. https://bitcoinops.org/en/topics/kindred-replace-by-fee/ 

20. https://bitcoinops.org/en/newsletters/2024/02/07/#proposal-for-replace-by-feerate-to-escape-pinning 

21. https://delvingbitcoin.org/t/mempool-incentive-compatibility/553 

22. https://blog.bitgo.com/available-now-for-clients-bitgo-introduces-replace-by-fee-f74e2593b245 

23. https://learnmeabitcoin.com/technical/transaction/size/ 

24. https://www.btcstudy.org/2022/03/17/introduction-to-fee-bumping-by-Bitcoin-Optech/#CPFP-的历史 

25. https://bitcoinops.org/en/newsletters/2023/10/25/#deployed-mitigations-in-ln-nodes-for-replacement-cycling 

26. https://bitcoinops.org/en/newsletters/2025/03/21/#discussion-of-lnd-s-dynamic-feerate-adjustment-system 

27. https://bitcoinops.org/en/newsletters/2025/03/28/#lnd-8453 

28. https://github.com/lightning/bolts/pull/1205 

29. https://bitcoin.org/en/release/v0.12.0#how-to-upgrade 

30. https://bitcoinops.org/en/topics/cluster-mempool/ 

31. https://github.com/bitcoin/bitcoin/issues/27677 

32. https://bitcoinops.org/en/newsletters/2023/12/06/#post-cluster-package-rbf 

33. https://bitcoinops.org/en/topics/htlc/ 

34. https://bitcoinops.org/en/topics/version-3-transaction-relay/ 

35. https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki

36. https://bitcoinops.org/en/topics/transaction-pinning/ 

37. https://bitcoinops.org/en/topics/ephemeral-anchors/ 

38. https://github.com/bitcoin/bitcoin/pull/25353