# What is Replace-by-Fee (RBF)? Source URL: https://help.blockstream.com/education/transactions/transaction-basics/what-is-replace-by-fee Updated: 2026-08-03T19:26:11.000Z Category: Transactions Section: Understanding Transactions --- **TL;DR:** Replace-by-Fee (RBF) lets you replace an unconfirmed Bitcoin transaction with a new version that pays a higher fee. If your transaction is stuck in the mempool because the fee was too low, RBF gives you a way to unstick it without waiting for it to drop out of every node's memory. Since Bitcoin Core 28.0, full RBF is enabled by default, meaning any unconfirmed transaction can be replaced. **Replace-by-Fee (RBF)** is a Bitcoin mempool policy that allows an unconfirmed transaction to be replaced by a new transaction that spends at least one of the same inputs and pays a higher fee. The replacement transaction effectively overwrites the original in nodes' mempools, giving the sender a mechanism to adjust fees after broadcast. RBF is defined by [BIP 125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) (opt-in) and was extended to full RBF with the `mempoolfullrbf` option added in Bitcoin Core 24.0.1 (December 2022), then enabled by default in Bitcoin Core 28.0 (October 2024). ## Why RBF Exists Bitcoin transactions do not confirm instantly. After you broadcast a transaction, it enters a waiting area called the **[mempool](https://help.blockstream.com/education/glossary/mempool)** (short for memory pool), where it sits until a miner includes it in a block. Miners are economically motivated to include transactions that pay the highest fees per unit of block space, so a transaction with a low fee can sit unconfirmed for hours, days, or indefinitely if the fee market moves against it. Before RBF, a stuck transaction left the sender with few options. The transaction would eventually either confirm at some unpredictable future time or be dropped from mempools after a timeout period (typically two weeks). There was no clean way to increase the fee after broadcast. RBF formalizes a replacement policy: create a new transaction that spends the same inputs with a higher fee, and nodes will accept the replacement and drop the original. Miners see the higher-fee version and have every incentive to include it instead. ## How RBF Works ### The Replacement Sequence 1. **Original broadcast.** You broadcast a transaction that spends one or more [UTXOs](https://help.blockstream.com/education/transactions/transaction-basics/what-are-utxos) as inputs. It enters the mempools of nodes across the network and waits to be included in a block. 2. **Fee becomes insufficient.** The fee market shifts. Other users broadcast higher-fee transactions, pushing yours down in the priority queue. Your transaction sits unconfirmed. 3. **Create the replacement.** You create a new transaction that spends _at least one of the same inputs_ as the original, with a higher total fee and fee rate (sats per virtual byte, or sats/vB). The new transaction can change the fee, the outputs, or both. 4. **Network propagation.** Nodes check the replacement against their mempool policy. If it meets the fee requirements, they drop the original and accept the replacement. 5. **Confirmation.** Miners see the higher-fee replacement and include it in a block. Once confirmed, the original can never confirm because its inputs have been spent. ### RBF Rules in Detail [Bitcoin Core](https://help.blockstream.com/education/nodes/set-up-and-optimization/what-is-bitcoin-core) enforces specific rules for transaction replacement (defined in BIP 125, implemented in [src/policy/rbf.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/policy/rbf.cpp), and updated in subsequent releases): | Rule | Requirement | Purpose | | ------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------- | | Conflicting inputs | Replacement must spend at least one input that the original spends | Establishes the replacement relationship | | Higher absolute fee | Replacement must pay a strictly higher total fee than all transactions it displaces (original + descendants) | Prevents free relay (bandwidth abuse) | | Sufficient fee rate | Replacement must meet the mempool's minimum relay fee rate independently | Prevents low-rate replacements from consuming relay resources | | No new unconfirmed inputs | Replacement must not introduce unconfirmed parent transactions the original did not depend on | Prevents cascading replacement chains | | Descendant limit | Original transaction and its descendants must not exceed 100 transactions | Caps computational cost of evaluating replacements | These rules protect the network from denial-of-service attacks while still allowing legitimate fee adjustments. ## Full RBF vs. Opt-in RBF The history of RBF in Bitcoin involves a shift from cautious, voluntary adoption to network-wide default behavior. ### Opt-in RBF (BIP 125) BIP 125, proposed in 2015 and implemented in Bitcoin Core 0.12.0 (February 2016), introduced opt-in RBF. A transaction had to explicitly signal replaceability by setting any input's `nSequence` value below `0xFFFFFFFE` (4294967294 in decimal). Specifically, any `nSequence` value from `0x00000000` through `0xFFFFFFFD` signals opt-in RBF. The value `0xFFFFFFFE` enables absolute locktime without signaling RBF, and `0xFFFFFFFF` (the maximum) disables both RBF and locktime. Nodes would only replace transactions that carried this signal. The opt-in approach was a compromise. Merchants worried that arbitrary replacement would undermine zero-confirmation payments. By requiring an explicit signal, opt-in RBF gave merchants a way to check whether an incoming transaction had flagged itself as replaceable. In practice, the signal provided no real security. A malicious sender could choose not to signal RBF, broadcast a low-fee transaction to a merchant, and then submit a conflicting transaction directly to a miner. The opt-in flag created a false sense of security rather than genuine protection. ### Full RBF (mempoolfullrbf) Bitcoin Core 24.0.1 (December 2022) introduced the `mempoolfullrbf` configuration option, which allowed node operators to accept replacements for any unconfirmed transaction regardless of whether it signaled RBF. Bitcoin Core 28.0 (October 2024) then enabled this option by default. Under full RBF, the opt-in signal is irrelevant. Any unconfirmed transaction can be replaced by a conflicting transaction that pays a higher fee. This is the current default behavior of Bitcoin Core and the standard mempool policy across the network. | Property | Opt-in RBF (BIP 125) | Full RBF (Core 28.0+) | | ---------------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Signaling required | Yes (nSequence < 0xFFFFFFFE) | No | | Which transactions can be replaced | Only those that signal replaceability | Any unconfirmed transaction | | Introduced | Bitcoin Core 0.12.0 (February 2016) | Option in Core 24.0.1 (December 2022); default in Core 28.0 (October 2024) | | Zero-conf security implication | Non-signaling transactions appeared "safe" (false sense of security) | All unconfirmed transactions are explicitly replaceable | | Current status | Superseded | Network default | The shift to full RBF was driven by several realities: - **The opt-in signal was not a security mechanism.** It never prevented double-spending. Miners were always free to include any valid transaction regardless of signaling. - **Simpler mempool policy.** A single replacement rule is easier to reason about than a two-tier system. - **Better fee estimation.** When all transactions can be replaced, the mempool more accurately reflects current demand for block space. - **Fewer stuck transactions.** Users no longer need to remember to signal RBF before broadcasting. ## When to Use RBF Common scenarios where RBF is the right tool: - **Stuck transaction:** The fee market spiked after you broadcast, and your transaction dropped to the bottom of the priority queue. RBF lets you match current conditions. - **Time-sensitive confirmation:** You sent a transaction during a calm fee period but need it confirmed faster than your original fee rate allows. - **Sent to the wrong address:** If the transaction has not yet confirmed, RBF lets you create a replacement that redirects the funds to a different address (including back to yourself). - **Batch consolidation:** You realize you can combine multiple payments into a single replacement transaction, saving total fees. ## How to Use RBF in Practice The exact steps depend on which wallet you use, but the general process is the same across any wallet that supports RBF. ### General Workflow 1. **Check the transaction status.** Open your wallet and find the unconfirmed transaction. It will show zero confirmations. 2. **Select the option to increase the fee.** Most wallets that support RBF label this as "Bump fee", "Speed up", "Increase fee", or "Replace transaction". 3. **Set the new fee.** The wallet will suggest a fee rate based on current mempool conditions. You can usually adjust this manually. The new fee must be higher than the original. 4. **Confirm and broadcast.** The wallet creates a new transaction spending the same inputs, signs it, and broadcasts it to the network. The original transaction is replaced in the mempools of nodes that receive the new one. 5. **Wait for confirmation.** The replacement transaction now competes in the fee market at the new fee rate. ### Checking Status With a Block Explorer After broadcasting a replacement, you can verify it propagated by looking up the transaction on a [block explorer](https://help.blockstream.com/education/wallets/managing-and-acquiring-bitcoin/how-do-i-look-up-my-bitcoin-transaction). [Blockstream Explorer](https://blockstream.info/) shows transaction details including fee, fee rate, and confirmation status. If the replacement was accepted, the original transaction ID will no longer appear in the mempool, and the new transaction ID will show as unconfirmed (pending) until a miner includes it in a block. ### What If RBF Fails? RBF can fail if: - The replacement fee is not high enough to meet the minimum relay fee increment. - The replacement introduces new unconfirmed parent transactions. - The original transaction has too many descendants in the mempool (exceeding the 100-transaction limit). - The original transaction has already been confirmed in a block. Once confirmed, a transaction is final and cannot be replaced. If RBF fails or is unavailable, CPFP (described below) is the alternative. ## CPFP: Child Pays for Parent CPFP is the other primary mechanism for unsticking a low-fee transaction. It works differently from RBF and is available to the _recipient_ of a stuck transaction, not just the sender. ### How CPFP Works When a transaction sends bitcoin to you but remains unconfirmed because its fee is too low, you can spend one of its outputs in a new "child" transaction that pays a high enough fee to cover both itself and its unconfirmed "parent". Miners evaluate transactions in packages: if the combined fee rate of the parent and child together is attractive enough, the miner includes both in the same block. For example, if the parent transaction pays a fee rate of 2 sats/vB but the current market demands 20 sats/vB, the child transaction needs to pay a fee rate high enough that the average fee rate across both transactions meets or exceeds 20 sats/vB. The child's fee compensates for the parent's shortfall. ### When to Use CPFP vs. RBF | Scenario | Use RBF | Use CPFP | | ------------------------------------ | ---------------------------------- | --------------------------------------------------- | | You are the sender | Yes | Only if you have a change output | | You are the recipient | No (only the sender can replace) | Yes | | You want to minimize fees | Usually more efficient | Requires a second transaction, so higher total fees | | The transaction has many descendants | May be limited by descendant count | Same limits apply | RBF is generally more fee-efficient because it replaces the original transaction entirely. CPFP is the only option when the recipient needs to accelerate confirmation without the sender's involvement. ### Package Relay and CPFP **Package relay**, an ongoing area of Bitcoin Core development, improves how nodes evaluate groups of related transactions. Historically, a parent transaction with a fee below the minimum relay threshold would not propagate at all, making CPFP impossible. Package relay lets nodes evaluate a parent and child as a unit, so the combined fee rate determines acceptance. This makes CPFP more reliable in edge cases. ## RBF, Merchant Acceptance, and Security RBF is sometimes characterized as a security concern. Understanding what RBF does and does not change about Bitcoin's security model matters for both merchants and protocol developers. ### Zero-Conf Was Never Safe A zero-conf transaction has been broadcast to the network but not yet included in a block. Some merchants historically accepted zero-conf payments for low-value goods, treating mempool visibility as "good enough". This was never a reliable security model. Even before RBF, a sender could broadcast two conflicting transactions simultaneously to different parts of the network (a "race attack"), or submit a conflicting transaction directly to a miner. The Bitcoin protocol has never guaranteed that the first-seen version of a transaction will be the one that confirms. Only inclusion in a block, protected by proof-of-work, provides settlement finality. RBF does not create new attack vectors. It standardizes what was always technically possible: replacing an unconfirmed transaction. This benefits users who need to adjust fees but does not change the security properties of unconfirmed transactions. ### What RBF Does Not Do - **Enable double-spending of confirmed transactions.** Once a transaction is in a block, it is final (subject to the extremely unlikely event of a chain reorganization). RBF only applies to unconfirmed transactions. - **Let someone else replace your transaction.** Only the holder of the [private keys](https://help.blockstream.com/education/wallets/security-and-storage/what-is-a-private-key-and-how-do-i-store-it) that signed the original can create a valid replacement. - **Weaken Bitcoin's security model.** Bitcoin's security has always been based on confirmations (proof-of-work), not mempool ordering. RBF aligns mempool behavior with this reality. ### Merchant Best Practices - **Wait for confirmations.** One confirmation provides strong assurance for most transaction sizes. Six confirmations is the conventional threshold for large amounts. - **Set policies based on value.** A coffee shop might accept one confirmation. A car dealership should require six. - **Do not rely on the RBF opt-in signal.** Under full RBF, the signal is irrelevant. Any unconfirmed transaction can be replaced. ### Transaction Pinning **Transaction pinning** is a concern related to RBF in multi-party protocols like [Lightning Network](https://help.blockstream.com/education/glossary/lightning-network) payment channels. In a pinning attack, one party deliberately creates conditions that make it expensive or impossible for the other party to replace a time-sensitive transaction. For example, attaching a large, low-fee-rate child transaction to a commitment transaction forces the counterparty to pay a fee exceeding the combined fees of the parent and all its descendants. Bitcoin Core developers have been addressing pinning through **package relay**, **v3 transaction policy** (also called TRUC, for Topologically Restricted Until Confirmation, specified in BIP 431), and **ephemeral anchors**. These mechanisms restrict how descendants can be attached to certain transaction types, making pinning attacks more difficult. ## RBF in Layer-2 Protocols Lightning channels rely on pre-signed transactions that may need to be broadcast under time pressure. If a channel counterparty attempts to cheat by broadcasting an old channel state, the other party must get a "justice transaction" confirmed within a specific timelock window. Because the party claiming those funds signs the justice transaction when they broadcast it, RBF lets them raise its fee to match current conditions, so a valid justice transaction does not fail to confirm because its fee was too low. The same principle applies to any protocol that uses pre-signed Bitcoin transactions: submarine swaps, DLCs (Discreet Log Contracts), coinjoins, and other multi-party constructions where fee estimation at signing time may not match conditions at broadcast time. ## Frequently Asked Questions ### Can someone else replace my transaction using RBF? No. Creating a replacement requires signing it with the private keys that control the inputs being spent. Only the original sender (or anyone with access to those keys) can create a valid replacement. ### Is RBF the same as double-spending? RBF replaces an _unconfirmed_ transaction that has not yet been secured by proof-of-work. A "double-spend" in the meaningful sense involves reversing a _confirmed_ transaction, which requires overpowering the network's hashrate. ### Do all wallets support RBF? Not all wallets expose RBF in their interface, but the feature operates at the network level. Most major Bitcoin wallets support fee bumping through RBF, including Bitcoin Core, Sparrow, Electrum, and the [Blockstream app](https://blockstream.com/app/). In the Blockstream app, you can bump the fee on an unconfirmed outgoing transaction directly from the transaction details screen. If your wallet does not support RBF directly, CPFP is an alternative. ### How much do I need to increase the fee? The replacement must pay a higher absolute fee than the original transaction plus all of its descendants in the mempool, and meet the minimum relay fee rate. Most wallets calculate the required increase automatically based on current mempool conditions. ### Can I RBF a transaction more than once? Yes. You can replace a replacement as many times as needed, as long as each successive replacement pays a higher fee than the one before it. There is no limit on the number of replacements, only the requirement that each one strictly increases the fee. ### What happens to the original transaction after RBF? Nodes that accept the replacement drop the original from their mempools. The replacement has a different transaction ID (txid), so the original txid will no longer appear as pending. Once the replacement confirms, the original can never confirm because its inputs have been spent. Navigation: Blockstream Help Center > Education > Transactions > What is Replace-by-Fee (RBF)? ## Related Articles in This Section - [Are Bitcoin transactions private?](https://help.blockstream.com/education/transactions/transaction-basics/are-bitcoin-transactions-private) - [Different Bitcoin transaction types](https://help.blockstream.com/education/transactions/transaction-basics/different-transaction-types) - [How does Bitcoin create and broadcast transactions?](https://help.blockstream.com/education/transactions/transaction-basics/how-does-bitcoin-create-and-broadcast-transactions) - [What are UTXOs and why do they matter?](https://help.blockstream.com/education/transactions/transaction-basics/what-are-utxos) - [What is Replace-by-Fee (RBF)?](https://help.blockstream.com/education/transactions/transaction-basics/what-is-replace-by-fee) (current) - [Why does Bitcoin have fees?](https://help.blockstream.com/education/transactions/transaction-basics/why-does-bitcoin-have-fees)