A technical deep-dive into Bitcoin's Replace-By-Fee mechanism - BIP-125 opt-in RBF, full RBF, wallet usage, mempool dynamics, and merchant implications.
You have just sent a Bitcoin transaction. You checked the mempool, saw that fees were relatively low, and set a fee rate of 5 sat/vB. But in the ten seconds between clicking "send" and your transaction being broadcast, a popular exchange initiated a massive consolidation - thousands of transactions at 8-12 sat/vB flooded the mempool. Your 5 sat/vB transaction now sits at the bottom of the priority queue. At the current block production rate, it might not confirm for hours. Or days. Or - if the mempool stays congested - it could be dropped entirely after the default 336-hour expiration.
This is the problem that Replace-By-Fee (RBF) solves. RBF allows you to create a new version of your unconfirmed transaction with a higher fee, effectively "bumping" it to a higher priority position in miners' transaction selection algorithms. It is one of the most practically important features in Bitcoin, yet it remains widely misunderstood.
At its core, RBF is simple: it permits a transaction's sender to replace an unconfirmed transaction in the mempool with a new transaction that spends the same inputs but pays a higher fee. The replacement transaction invalidates the original - both cannot be confirmed because they spend the same UTXOs (Unspent Transaction Outputs).
When a node receives a replacement transaction, it:
If all conditions are met, the node evicts the original transaction from its mempool and accepts the replacement.
Bitcoin's original implementation by Satoshi Nakamoto actually included a rudimentary replacement mechanism - transactions had a nSequence field that was intended to allow replacements. However, this feature was disabled early on because it was trivially exploitable: an attacker could replace transactions an unlimited number of times without paying additional fees, effectively DoS-attacking the network's mempool relay.
In February 2016, BIP-125 was implemented in Bitcoin Core 0.12.0. It introduced opt-in RBF: a transaction signals that it is replaceable by setting any input's nSequence value to less than 0xFFFFFFFE (4294967294). Specifically:
nSequence < 0xFFFFFFFE → Transaction signals opt-in RBF (replaceable)nSequence = 0xFFFFFFFE → Transaction signals relative time lock (not RBF)nSequence = 0xFFFFFFFF → Final transaction (not RBF, not time-locked)The "opt-in" design was a political compromise. Many in the Bitcoin community - particularly merchants and payment processors who relied on zero-confirmation (zero-conf) transactions - opposed unrestricted replacement because it made double-spending trivially easy. By making RBF opt-in, the argument went, merchants could distinguish between replaceable and non-replaceable transactions.
In practice, this distinction was always somewhat illusory. A miner is economically incentivized to include whichever transaction pays the highest fee, regardless of any opt-in signal. The opt-in flag is a relay policy enforced by nodes, not a consensus rule enforced by the blockchain. A miner running modified software could (and some did) accept replacement transactions regardless of the nSequence signal.
Bitcoin Core 25.0, released in May 2023, introduced the mempoolfullrbf option (defaulting to false), allowing node operators to accept replacement transactions regardless of the opt-in signal. By Bitcoin Core 28.0 (late 2024), full RBF became the default behavior.
The transition to full RBF was significant for several reasons:
Bitcoin Core's wallet has supported RBF since version 0.12.0. To send an RBF-enabled transaction:
# Send with RBF enabled (default in recent versions)
bitcoin-cli sendtoaddress "bc1q..." 0.01
# Bump the fee of an unconfirmed transaction
bitcoin-cli bumpfee "txid_of_original_transaction"The bumpfee command creates a replacement transaction that:
Sparrow Wallet provides an intuitive RBF interface:
Fee estimation is inherently imperfect because it requires predicting future mempool conditions. Even the best fee estimators can underestimate when sudden demand spikes occur - exchange withdrawals, airdrop claims, NFT mints (on protocols built on Bitcoin like Ordinals), or coordinated buying during market events.
RBF is your safety net. You can start with a conservative (lower) fee rate and bump it only if the transaction is not confirming within your desired timeframe. This strategy often saves money compared to always overpaying for "fast" confirmation.
You are paying for a time-limited purchase (concert tickets, a limited sale). Your transaction is stuck in the mempool. Without RBF, you would need to wait - potentially missing the purchase window. With RBF, you bump the fee to the current fast-confirmation rate and get mined in the next block.
Experienced users consolidate small UTXOs during low-fee periods. If you batch-consolidate at 1 sat/vB and fees suddenly rise, RBF lets you bump the consolidation without abandoning it and re-creating it at a higher fee (which would cost more due to creating a new transaction from scratch).
You sent 0.1 BTC to Alice but realized you meant to send 0.1 BTC to Bob. If the transaction is still unconfirmed, you can create an RBF replacement that sends 0.1 BTC to Bob instead. The original transaction to Alice will never confirm.
Important caveat: This only works while the original transaction is unconfirmed. Once a transaction has been mined into a block, it is final and irreversible - there is no RBF for confirmed transactions.
The most contentious aspect of RBF has always been its implications for zero-confirmation transactions - transactions that are broadcast to the network but not yet included in a block.
Some businesses, particularly brick-and-mortar stores and point-of-sale merchants, relied on zero-conf transactions for speed. A customer broadcasts a transaction, the merchant sees it in their mempool, and immediately provides the goods or services - without waiting for a block confirmation (which averages 10 minutes but can take over an hour).
The argument against RBF was that it made double-spending against merchants trivially easy: a customer could broadcast a transaction to the merchant, receive their goods, then immediately broadcast an RBF replacement that redirects the funds back to their own wallet.
The reality is that zero-conf was never a strong security guarantee, even before RBF:
The honest assessment: for transactions above trivial amounts, waiting for at least one confirmation (approximately 10 minutes on average) has always been the recommended practice. For high-value transactions, 3-6 confirmations provide strong probabilistic finality.
For businesses that need instant payment confirmation, the Lightning Network provides genuine instant finality with cryptographic security guarantees - making it a fundamentally better solution than zero-conf on-chain transactions.
Understanding RBF requires understanding the mempool - the queue of unconfirmed transactions that each Bitcoin node maintains independently.
Miners construct blocks by selecting transactions from their mempool to maximize fee revenue within the block size limit (approximately 4 million weight units, or ~1.5-2.5 MB of actual data). They use an algorithm that considers:
RBF directly interacts with this selection process. When you bump a fee, you are moving your transaction higher in this priority queue.
The mempool functions as a real-time auction for block space. At any moment, you can observe the current "going rate" for block inclusion by examining the fee rates of transactions at the top of the mempool (those likely to be included in the next block).
Tools like mempool.space provide real-time visualizations of the mempool, showing:
RBF allows you to participate rationally in this auction. If you initially bid too low, you can raise your bid. This is analogous to how any auction works - and from an Austrian Economics perspective, it is a beautifully pure free-market mechanism. Block space is a scarce resource, and the fee market is the price discovery mechanism that allocates it efficiently without any central authority dictating prices.
When bumping a fee with RBF, you need to understand the units:
Fee Rate = Total Fee (satoshis) / Transaction Size (virtual bytes)A typical single-input, two-output SegWit transaction is approximately 141 vBytes. If you want a fee rate of 20 sat/vB:
Total Fee = 20 × 141 = 2,820 satoshis ≈ 0.00002820 BTCAt a Bitcoin price of $95,000 (approximate as of early 2026), this is roughly $2.68. For the same transaction at 100 sat/vB during high congestion: $13.40.
An important technical detail: each replacement must pay not just a higher absolute fee, but must also cover the incremental relay fee - an additional fee that compensates nodes for the bandwidth consumed by relaying the replacement transaction. The default incremental relay fee in Bitcoin Core is 1 sat/vB of the replacement transaction's size.
This means you cannot simply bump from 5 sat/vB to 5.1 sat/vB. The minimum bump must cover the incremental relay fee. In practice, most wallets handle this automatically and bump to a meaningfully higher fee rate.
RBF is not the only way to accelerate a stuck transaction. Child-Pays-for-Parent (CPFP) is an alternative mechanism that works differently:
Instead of replacing the original transaction, CPFP creates a new transaction (the "child") that spends an output of the stuck transaction (the "parent"). The child pays a sufficiently high fee to make the combined fee rate of the parent-child package attractive to miners. Because miners must include the parent to include the child, both get confirmed together.
| Scenario | Use RBF | Use CPFP |
|---|---|---|
| You are the sender | Preferred | Possible (via change output) |
| You are the recipient | Not possible | Preferred |
| Transaction has many outputs | Works | Works (via any output) |
| Transaction is not signaling RBF (older wallets) | May not relay on some nodes | Always works |
The key difference: RBF is used by the sender, while CPFP can be used by either the sender (via the change output) or the recipient. This makes CPFP particularly valuable when you are waiting to receive a payment that is stuck - you can spend the incoming (unconfirmed) output with a high fee to accelerate the parent transaction.
Bitcoin Core development is actively improving how ancestor/descendant transaction packages are handled in the mempool. Package relay (being implemented in stages across Bitcoin Core versions) allows the mempool to evaluate groups of related transactions as a unit rather than individually. Cluster mempool (implemented in Bitcoin Core 28.0+) fundamentally restructures the mempool to use "clusters" of related transactions, improving eviction and selection decisions.
These improvements make both RBF and CPFP more reliable and predictable.
With full RBF as the default, the practical security implications for merchants are clear:
RBF is purely beneficial for users:
One sophisticated attack related to RBF is transaction pinning - an adversary creates a large, low-fee-rate descendant of a shared transaction (like a Lightning channel closing transaction), making it expensive to replace via RBF because the replacement must pay a higher absolute fee than the entire pinned package. Anti-pinning mechanisms including ephemeral anchors (introduced conceptually in v3 transaction relay policy) are being developed to mitigate this.