Replace-by-fee (RBF) explained: BIP 125 and full RBF

Replace-by-fee (RBF) lets you replace an unconfirmed Bitcoin transaction with a new version that spends the same coins and pays a higher fee, usually to get a stuck payment confirmed faster. BIP 125 defined how a transaction signals that it may be replaced and which replacements nodes accept. Since Bitcoin Core 28.0, released in October 2024, nodes accept replacements by default even without that signal ("full RBF"). RBF is mempool policy, not a consensus rule.

Updated 2026-10-20 · 7 min read

What is replace-by-fee?

When you broadcast a transaction it waits in nodes' mempools until a miner includes it in a block. Miners generally pick the transactions that pay the most per vbyte, so if your fee rate is too low compared with everyone else's, your transaction can wait for hours or days.

Replace-by-fee solves this by letting you send a replacement: a new transaction that spends at least one of the same inputs, so only one of the two can ever confirm, and pays a higher fee. Nodes that accept the replacement drop the original from their mempool. Wallets usually call this "bump fee" or "speed up". Because the replacement is a different transaction, it gets a new txid.

Mempool policy, not consensus

Nothing in Bitcoin's consensus rules says which of two conflicting unconfirmed transactions is "the real one". Either is valid until one is in a block. What RBF changes is node policy: which transaction a node keeps in its mempool and relays to peers. BIP 125's signal is just a value in an existing field, and as the BIP notes, miners have mined transactions using it "since Bitcoin's first release".

That has two consequences. First, an unconfirmed payment is never final, with or without RBF. Second, different nodes can run different policies, and changes to replacement rules ship in node software releases rather than in soft forks.

BIP 125: opt-in RBF signaling

BIP 125, by David A. Harding and Peter Todd, was written in December 2015 and implemented in Bitcoin Core 0.12.0. It defined opt-in RBF: a transaction is replaceable only if it says so.

• Explicit signal: at least one input has an nSequence value below 0xfffffffe (that is, less than 0xffffffff minus 1).
• Inherited signal: a transaction that doesn't signal is still replaceable while any of its unconfirmed ancestors signals.

Wallets that don't want replaceability use 0xffffffff, or 0xfffffffe when they also use a locktime. The design reuses Satoshi Nakamoto's original idea: the first software let higher sequence numbers replace lower ones, but without a fee requirement, and Nakamoto disabled it in version 0.3.12. An intermediate idea, "first-seen-safe" RBF, required replacements to pay all the same outputs; BIP 125 explains that it cost an extra input every time and hurt privacy.

How to tell if a transaction signals RBF

Look at the nSequence of each input: any value below 0xfffffffe means the transaction opted in. Most block explorers show this as an "RBF" flag, and Bitcoin Core's RPC results have reported it as a bip125-replaceable field. With full RBF now the default (below), the flag tells you what the sender intended rather than whether a replacement can actually propagate.

The BIP 125 replacement rules

BIP 125 lists the rules of its first implementation. A replacement is accepted if:

1. The original transactions signal replaceability, explicitly or by inheritance.
2. It adds no new unconfirmed inputs (any unconfirmed input must already be in an original).
3. It pays an absolute fee at least as high as the sum of the originals' fees.
4. It also pays for its own relay bandwidth at the node's minimum relay rate. The BIP's example: at 1 satoshi per byte, a 500-byte replacement must pay at least 500 satoshis more than the originals.
5. It evicts no more than 100 transactions in total, counting the originals and their descendants.

Bitcoin Core also requires the replacement to have a higher fee rate than the transactions it replaces, and its rules have evolved since 2015; BIP 431 notes that Core's policy is "slightly different from what is described in BIP 125". The current rules are in Bitcoin Core's mempool replacement documentation.

Full RBF

Full RBF means nodes accept a fee-paying replacement whether or not the original signaled. Bitcoin Core 24.0 added an option for it, mempoolfullrbf, off by default. Bitcoin Core 28.0, released in October 2024, turned it on by default.

In practice this makes the opt-in signal far less important: a replacement can propagate even if the original didn't signal. The change was debated. Some merchants accepted unconfirmed payments without RBF signals and relied on first-seen behavior. Supporters of full RBF argued that first-seen was never enforceable, since a miner can include whichever version pays more, and that predictable replacement helps multi-party transactions such as coinjoins avoid being blocked. Either way, BIP 125's advice to receivers still applies: treat unconfirmed transactions with suspicion, or wait for confirmation.

RBF vs CPFP

Child-pays-for-parent (CPFP) is the other way to speed up a transaction. Instead of replacing it, you spend one of its unconfirmed outputs in a new "child" transaction with a high fee. Miners evaluate the parent and child together, so a generous child pulls the parent into a block.

A CPFP example. A 200 vB parent paid 400 sats (2 sat/vB) and you want 20 sat/vB. Your child spends its change and is 110 vB. Together they are 310 vB, so they need 6,200 sats in total; the child must pay 5,800 sats, about 52.7 sat/vB on its own. The transaction size calculator estimates vbytes for your inputs and outputs.

Package relay, TRUC transactions and anchors

CPFP has limits. If the parent pays less than a node's minimum mempool fee rate it is rejected outright, so the child has nothing to attach to. And in shared transactions a counterparty can sometimes "pin" a transaction, making replacement or CPFP prohibitively expensive. Lightning and other contract protocols depend on fee bumping at broadcast time, so several proposals address this.

• BIP 331, Ancestor Package Relay (Gloria Zhao) defines peer-to-peer messages for relaying a transaction together with its unconfirmed ancestors as a package, so a low-fee parent can travel with the child that pays for it.
• BIP 431, TRUC transactions (Gloria Zhao) describes "Topologically Restricted Until Confirmation" policy. A transaction with nVersion=3 is always replaceable, may have at most one unconfirmed parent or child, is limited to 10,000 vB (1,000 vB for a child), and may pay below the minimum fee rate if its package pays enough. These limits make pinning much harder.
• BIP 433, Pay to Anchor (Gregory Sanders) defines a tiny keyless output, OP_1 <0x4e73> (address bc1pfeessrawgf), that anyone can spend to attach a CPFP child. BIP 433 says Bitcoin Core treats spending it as standard. Used with TRUC, it gives pre-signed transactions an anchor output for adding fees later.

How Lightning uses these is covered in the BIPs behind Lightning.

How to speed up a stuck Bitcoin transaction

1. Check the fee rate. Look up the transaction on your own node or a block explorer and note its fee rate in sat/vB. Compare it with current fee estimates for the next few blocks.
2. If you sent it, use RBF. In a wallet that supports it, choose "bump fee" or "speed up" and pick a higher rate. The wallet builds a replacement, usually by reducing your change output. Some wallets can also "cancel" by replacing the payment with one back to yourself, which only works if the original hasn't confirmed.
3. If you received it, or RBF isn't available, use CPFP. Spend the output you received (or the sender's change) to yourself with a fee high enough that parent and child together reach your target rate, as in the example above.
4. Otherwise, wait. Unconfirmed transactions often confirm when fees fall. Bitcoin Core drops transactions from its mempool after two weeks by default, but any copy can be rebroadcast, so never assume the original is gone: a transaction is only truly canceled once a conflicting one confirms.
5. Next time, pay less for the same payment. Native SegWit and Taproot inputs use fewer vbytes; see the SegWit guide.

Never type a seed phrase or private key into a website that offers to "accelerate" a transaction. Fee bumping is done in your own wallet, and no tool on this site asks for keys.