What is Replace-By-Fee?

Introduction

Replace-By-Fee (RBF) is a Bitcoin mempool policy that allows an unconfirmed transaction to be replaced by a different transaction spending at least one of the same inputs if the replacement offers better fee incentives. That idea sounds small, but it sits exactly at the fault line between two things Bitcoin users often want at once: fast payments and reliable finality. If a transaction can be updated before it is mined, a sender can rescue a stuck payment by raising the fee. But the same mechanism also makes it explicit that seeing a transaction on the network is not the same thing as having a confirmed payment.

That tension is the point. Bitcoin blocks arrive on an irregular schedule, fee conditions change quickly, and wallets cannot always guess the right fee on the first try. Without some way to adjust an unconfirmed transaction, users either overpay up front or risk waiting a long time. RBF is the mechanism that lets the sender revise that tradeoff while the transaction is still only a mempool object and not yet part of the blockchain.

The most important thing to keep in view is this: **RBF is not a consensus rule about what the blockchain is. It is a policy rule about what nodes relay and keep in memory before confirmation. ** That single distinction explains most of the confusion around it. Once a transaction is confirmed in a block, RBF is no longer relevant. Before confirmation, different nodes may apply somewhat different replacement policies, and that is why replacement is about mempools, relay, miner behavior, and wallet design rather than about chain validity itself.

Why do Bitcoin wallets need Replace-By-Fee?

A Bitcoin transaction competes for scarce block space. Miners generally prefer transactions that pay more fees per unit of size, because that increases revenue. If you broadcast a transaction with a fee that turns out to be too low for current mempool conditions, the transaction can sit unconfirmed for a long time. The sender then faces an awkward problem: the coins are already committed to that transaction, but the network is not obligated to confirm it quickly.

At first glance, the obvious solution is simple: just send a new version of the same payment with a higher fee. But naive replacement has a flaw. If nodes relay every new version for free, an attacker can flood the network with endless variants of the same transaction while paying only for the one that eventually gets mined. Early transaction replacement in Bitcoin existed, but it was removed because this kind of behavior created denial-of-service problems. So the real design problem was not merely “should replacement exist?” It was “how do you allow replacement without turning relay into a cheap bandwidth and CPU abuse vector?”

Here is the mechanism that makes the idea workable: **a replacement must pay enough more that relaying it is economically justified. ** In BIP125’s opt-in design, the replacement must at least pay the sum of the fees of the transactions it replaces, and it must also pay an additional amount sufficient to cover its own relay bandwidth according to node policy. In other words, replacement is not free rewriting. It is a costly update, and that cost is what prevents the policy from degenerating into spam.

This is also why RBF is tightly connected to Bitcoin’s fee market. It is not a special exception to the fee market; it is a way of interacting with it after broadcast. The sender first places a bid for block space. If that bid turns out to be too low, RBF lets the sender raise the bid before confirmation.

Which parts of a transaction can be replaced by RBF?

It helps to strip the idea down to the minimum. Suppose Alice has a wallet UTXO worth 100,000 satoshis and creates a transaction paying Bob 95,000 satoshis with a 1,000 sat fee. That transaction enters mempools but does not confirm because fee pressure rises. Alice now creates a second transaction that spends the same input but pays Bob the same 95,000 satoshis and uses a 3,000 sat fee instead. Both transactions cannot be confirmed, because they try to spend the same coin. In mempool terms, they are conflicting transactions.

RBF is the policy that tells a node whether it should keep the first one, accept the second one instead, relay the second one to peers, and evict the first from memory. That is why the mempool matters so much: this is not about rewriting history, but about updating the current candidate set of unconfirmed transactions.

The conflict is defined mechanically. Bitcoin Core’s mempool replacement policy describes a transaction as directly conflicting with an in-mempool transaction if they spend one or more of the same inputs. If a replacement is accepted, it may also evict descendants of the original transaction from the mempool. That descendant behavior matters because mempool transactions do not live in isolation. If an original transaction has children that spend its outputs, replacing the parent can invalidate those children as mempool entries too.

This is why replacement is more than “higher fee wins.” The node has to account for the small local economy of related unconfirmed transactions that may be displaced together. If it did not, nodes could accidentally replace a parent with something that looks better in isolation but is worse once the whole package of descendants is considered.

How did BIP125 opt-in RBF signaling work?

The most widely known form of RBF is opt-in full-RBF as specified in BIP125. “Opt-in” means the original transaction signals that the sender wants the option to replace it later. “Full-RBF” means that, once the transaction has opted in, the replacement is not constrained to preserve the same outputs. The sender can genuinely change the transaction, so long as replacement-policy rules are satisfied.

In BIP125, explicit signaling uses the input sequence field. A transaction is considered to have opted in if any input has nSequence < 0xffffffff - 1. BIP125 also defines inherited signaling: even if a transaction does not explicitly signal replaceability, it is treated as replaceable while any unconfirmed ancestor signals replaceability. That inherited rule is easy to miss, but it matters for wallets that spend unconfirmed change. A child transaction can become replaceable not because it asked to be, but because it depends on a parent that did.

The reason for using nSequence is partly historical and partly practical. The field already existed, and opt-in signaling could be implemented as a relay and mempool policy change without a consensus fork. The signal is not a magic on-chain command forcing all nodes to accept replacements. It is a convention that upgraded nodes recognize when deciding whether a candidate replacement is eligible.

That last point explains why BIP125 adoption was described as gradual. A replacement is only as effective as its path through the network to miners. If too few nodes relay replacements, or too little hash rate mines them, then a wallet can create a valid replacement that is still unreliable in practice. From the start, the specification warned that real-world replacement would depend on sufficient node and miner support.

What fee requirements must a replacement meet under RBF?

People often summarize RBF as “pay more and replace the old transaction,” but the actual policy is stricter because nodes need protection against churn.

Under BIP125’s initial rules, the replacement had to pay an absolute fee at least as large as the sum of the fees of the transactions it replaced. That prevents a sender from lowering the total miner incentive while asking the network to discard existing mempool entries. But matching the old fees is not enough. Relaying a replacement itself consumes bandwidth and processing, so the replacement also had to pay an extra amount based on the node’s minimum relay policy. In the BIP’s example, if the node’s minimum relay fee implied 500 satoshis for the replacement’s size, the replacement had to exceed the originals by at least that much.

There were additional guardrails. A replacement could include an unconfirmed input only if that input already appeared in one of the original transactions being replaced. That rule limits a class of abuse where replacements could drag in new unconfirmed dependencies and enlarge the replacement surface unpredictably. There was also a bound on the number of transactions that could be evicted: the originals and their descendants could not exceed 100 transactions in the initial implementation. This kept replacement from becoming a way to trigger expensive mempool surgery on very large unconfirmed clusters.

These rules reveal the underlying invariant. **A node should only accept a replacement if doing so leaves the mempool in a strictly better economic state and does not impose disproportionate processing cost. ** Newer Bitcoin Core policy documents express this idea even more directly by requiring strict improvement in the mempool’s feerate diagram. The exact policy has evolved, but the principle has remained stable: replacement is allowed when it improves expected block revenue and does not create cheap relay abuse.

How does a wallet 'speed up' a stuck transaction with RBF?

Imagine a wallet sends a transaction during a quiet period using a low feerate because recent blocks were mostly empty. Ten minutes later, a burst of demand hits the mempool. The transaction is now far below the going market rate and likely to wait. The wallet notices this and offers a “speed up” button.

When the user accepts, the wallet constructs a new transaction spending the same original inputs. It usually keeps the payment to the recipient unchanged and finds the extra fee by reducing the change output. If there is not enough change, a wallet may need to add another input it controls. Bitcoin Core’s bumpfee RPC describes this behavior directly: it replaces an opt-in-RBF wallet transaction with a higher-fee version, includes all original inputs, may reduce change, may add inputs, and may create a new change output if needed.

Why does each of those details happen? The wallet cannot simply “append more fee” to an existing transaction, because Bitcoin transactions are signed messages over specific inputs and outputs. Changing the fee means changing the transaction. Usually the cleanest place to take the extra amount from is change, because reducing the recipient’s payment would alter the intended payment itself. If the original transaction had no useful change cushion, the wallet may need another input to fund the higher fee, which can affect privacy and size.

If the replacement satisfies local mempool policy, the node accepts it, removes the original transaction and any affected descendants from its mempool, and relays the replacement. Miners who see the replacement now have a stronger incentive to include it than the original. The user experiences this as “speeding up” a stuck payment, but mechanically it is the creation and propagation of a different unconfirmed transaction.

Does RBF make double-spending easier for zero-confirmation payments?

The criticism most often directed at RBF is that it “allows double spends.” The calm way to put this is: **RBF makes some replacement behavior more explicit and structured, but unconfirmed Bitcoin transactions were never final in the first place. ** A sender can always attempt to race one transaction against another, exploit network topology, or send conflicting transactions directly to miners. Bitcoin Core’s opt-in RBF FAQ is blunt on this point: unconfirmed transactions are intrinsically unsafe, and most of the practical safety of zero-confirmation acceptance comes from surrounding conditions, not from an absence of formal replacement policy.

What RBF changes is not the existence of conflict risk, but the shape of incentives and expectations. By giving wallets a standard way to update fees, RBF helps honest users recover stuck transactions. By signaling replaceability in the opt-in model, it also tells recipients that the sender has preserved that option. BIP125 therefore advised wallets and services that act on unconfirmed transactions either to treat opt-in transactions with added suspicion or to ignore them until confirmation.

This is not merely a legalistic warning. It reflects the basic distinction between network acceptance and economic finality. A transaction entering your node’s mempool means “this looks valid and relayable under current policy.” It does not mean “the payer can no longer redirect these funds.” Confirmation in a block is the event that changes the situation decisively.

RBF vs CPFP: When should I use each fee-bumping method?

RBF is often introduced alongside Child Pays For Parent (CPFP) because both are fee-bumping tools, but they operate from different positions.

RBF is controlled by the sender of the original transaction, because it replaces the original with a new version. CPFP works when someone can spend an output of the stuck transaction in a high-fee child transaction, giving miners a reason to include both parent and child together. In ordinary wallet use, that often means the receiver can rescue a stuck incoming payment if they can spend its output, while the sender can rescue it with RBF if the original transaction was created to allow replacement.

The contrast matters because it explains why neither technique completely subsumes the other. If you are the original sender and the transaction is marked replaceable, RBF is often the cleanest tool. If you are the recipient and cannot alter the sender’s transaction, CPFP may be your lever instead. Bitcoin Core’s FAQ explicitly describes CPFP as another way of adding fees to a transaction by creating a dependent child.

The two mechanisms also interact with mempool policy in subtle ways. Descendants matter for replacement logic, and package relay or package RBF work has tried to make these combined fee-bumping patterns more reliable. That is part of why recent Bitcoin Core releases discuss limited package RBF and TRUC policy: the hard problem is not merely single-transaction replacement, but reliable fee management for connected sets of unconfirmed transactions.

When does RBF cause 'pinning' in multiparty protocols?

RBF sounds straightforward in a single-sender wallet, but more advanced protocols expose its edges. In multiparty transactions, such as some channel-closing or collaborative constructions, the participants may want the ability to raise fees later. But the exact replacement rules can create transaction pinning problems, where one party or an attacker constructs a transaction in a way that makes economically sensible replacement difficult.

A key source of this problem is the combination of absolute-fee and feerate constraints. Requiring the replacement to pay a higher absolute fee as well as a better feerate helps defend relay resources, but it can also force a replacement to find extra value that may not be available or convenient inside the transaction structure. Bitcoin Optech notes that these BIP125-style requirements have motivated discussion of feerate-only replacement proposals, though such proposals raise their own incentive-compatibility questions.

This is a good example of a broader truth: mempool policy is not pure economics and not pure security. It is a negotiated engineering compromise among miner incentives, node resource limits, and wallet usability. A rule that is clearly helpful against cheap spam can still be painful for time-sensitive contract protocols. That does not make the rule irrational; it means the system is balancing multiple failure modes at once.

How has Bitcoin Core's RBF policy changed since BIP125?

Historically, Bitcoin Core 0.12 introduced opt-in RBF support as a local policy behavior. Nodes could disable transaction replacement with -mempoolreplacement=0, and the Core wallet at that time did not yet create replaceable transactions itself. Over the years, wallet tooling matured, RPCs exposed replaceability information, and fee-bumping features such as bumpfee became normal wallet behavior.

Meanwhile, node policy continued to evolve. Full-RBF (allowing replacement regardless of BIP125 opt-in signaling) was added as a configurable setting through -mempoolfullrbf, initially defaulting to false. The rationale was practical: some protocols, especially multiparty ones, were exposed to mempool attacks when replacement depended on opt-in signaling and heterogeneous network topology. Later releases changed the default of mempoolfullrbf from 0 to 1, making full-RBF the default behavior in Bitcoin Core 28.0. The release notes for that version also enabled a limited form of package RBF and highlighted related policy changes.

The direction of travel is important. What began as an opt-in policy designed to make replacement socially palatable has moved toward broader acceptance that first-seen is not a dependable finality guarantee and that mempool policy should reflect miner incentives more directly. A later Core pull request removed the -mempoolfullrbf option entirely, with the rationale that widespread adoption meant disabling full-RBF locally provided no meaningful security benefit. That same discussion updated documentation around BIP125 signaling and treated the old opt-in signaling requirement as obsolete in current Core policy.

This does not mean the original BIP125 ideas were pointless. They were an important bridge. Opt-in signaling created a deployable path for wallets and merchants during a period when replacement policy itself was contested. But if you are trying to understand present-day Bitcoin rather than only the historical design, you should separate BIP125 as a specific opt-in convention from RBF as the broader practice of mempool replacement. The concept outlived the exact initial signaling regime.

How do wallets implement RBF and fee-bumping in practice?

For most users, RBF appears as a wallet button labeled something like “Speed up.” Trezor Suite, for example, presents RBF exactly this way: a pending transaction can be replaced with a higher-fee version to get confirmed faster. Under the hood, that is the same fee-bump mechanism described earlier.

But wallet behavior is not only about confirmation speed. RBF also changes initial fee strategy. If a wallet knows it can raise the fee later, it can start with a lower fee estimate and avoid systematic overpayment. Bitcoin Core’s FAQ notes this directly: wallets may want to increase fees later, compress multiple unconfirmed payments into one, or support advanced workflows such as background coinjoins. In other words, RBF is not only a rescue tool for mistakes. It is part of a broader strategy for flexible transaction construction under uncertainty.

There are tradeoffs. Every fee bump raises the total fees paid. Replacements can also change the transaction shape by consuming change differently or adding inputs, which can have privacy consequences. Wasabi’s user guidance, for example, advises using RBF only when necessary as part of a broader effort to avoid making change outputs easier to identify. That is not a protocol rule; it is a wallet-level judgment that fee management and privacy are entangled.

Recipients and services also have practical choices to make. If they care about zero-confirmation convenience, they may distinguish between replaceable and non-replaceable transactions in their UI or risk engine. But they should not confuse that distinction with a hard security boundary. Even non-signaled unconfirmed transactions are not guaranteed final before confirmation.

Key takeaways about Replace-By-Fee and unconfirmed transactions

Replace-By-Fee is best understood as a rule for updating bids in Bitcoin’s block-space auction before a transaction is confirmed. The original puzzle it solves is simple: users cannot always know the right fee at broadcast time, but naive replacement would invite spam and abuse. RBF works because replacements are costly, local mempool policy decides whether they are accepted, and miners ultimately confirm whichever valid transactions best fit their incentives.

If you remember only one thing, remember this: **an unconfirmed Bitcoin transaction is a proposal, not a settlement. RBF is the formal mechanism that lets that proposal be revised by paying more. ** It helps honest users fix stuck transactions, clarifies the limits of zero-confirmation trust, and reveals how much of Bitcoin’s real-world behavior lives not in consensus alone, but in the policies nodes use before consensus ever happens.

How do you buy or trade Bitcoin after learning about Replace-By-Fee?

To get practical exposure to Bitcoin after studying Replace-By-Fee, you can buy or trade BTC on Cube and then observe how on-chain confirmations behave when you move funds. Cube handles the market execution and custody flow, and if you want to observe or test RBF-related behavior on-chain you can withdraw to a self-custodial wallet that supports fee bumping.

1. Fund your Cube account with fiat via the on-ramp or with a supported crypto transfer (choose USD or USDC if you plan to trade BTC/USDC).
2. Open the BTC/USDC (or BTC/USD) market on Cube and pick an order type; use a limit order for price control or a market order for immediate execution.
3. Enter the BTC amount or fiat spend, review estimated fees and estimated settlement time, then submit the order.
4. If you want to observe RBF behavior on-chain, withdraw the purchased BTC to a self-custodial wallet (select native SegWit/bech32 for lower fees) and use a wallet that offers a "speed up" or "bump fee" option to test fee-bumping.