You send Bitcoin, see the transaction appear as unconfirmed, and then nothing happens.

Minutes pass.

Then an hour.

Maybe the transaction is still sitting in the mempool, waiting for a miner to include it in a block.

One common reason is that the transaction paid a fee rate that was too low for the conditions at the time.

This is where Replace-by-Fee (RBF) becomes useful.

RBF allows an unconfirmed Bitcoin transaction to be replaced by another transaction that spends the same input(s) while paying a higher fee, provided the replacement satisfies the relevant node policy rules. Bitcoin Core currently supports full replace-by-fee as its standard mempool replacement policy.

That means a transaction that looked “stuck” does not necessarily have to remain stuck until it eventually confirms.

In many cases, the sender can increase the effective fee and give the transaction a better chance of being selected for a block.

What Is RBF in Bitcoin?

RBF stands for Replace-by-Fee.

The basic idea is simple:

Original transaction → Higher-fee replacement transaction

The replacement spends the same input or inputs as the original transaction.

Because both transactions try to spend the same UTXOs, they conflict with each other.

A node that accepts the replacement removes the conflicting transaction from its mempool and keeps the replacement instead.

For example:

Original Transaction

Input:  0.010 BTC
Output: 0.0098 BTC
Fee:    0.0002 BTC

          ↓

Replacement Transaction

Input:  0.010 BTC
Output: 0.0096 BTC
Fee:    0.0004 BTC

The recipient can still receive approximately the same payment.

The difference is that more of the input value is now being used for the transaction fee.

The exact replacement rules are determined by node policy, not simply by the sender deciding to attach a larger fee.

Why Do Bitcoin Transactions Get Stuck?

Bitcoin doesn’t process every transaction immediately.

When your wallet broadcasts a transaction, it normally enters a node’s mempool.

The mempool stores transactions that are valid but have not yet been confirmed in a block.

Miners or block-building software then select transactions for inclusion in blocks.

When demand for block space is high, transactions offering relatively low fee rates may wait longer.

For example, imagine the mempool contains transactions offering:

2 sat/vB
5 sat/vB
10 sat/vB
25 sat/vB

A miner trying to maximize fee revenue may have little reason to prioritize a transaction paying only 2 sat/vB when more profitable transactions are available.

This doesn’t necessarily mean the transaction is invalid.

It may simply be economically unattractive to include at that moment.

That’s one reason a Bitcoin transaction can remain unconfirmed for a significant period.

What Does “Stuck” Actually Mean?

A Bitcoin transaction isn’t really frozen on the blockchain when it is unconfirmed.

It hasn’t become part of the blockchain yet.

Instead, it may be sitting in one or more nodes’ mempools while waiting for confirmation.

This distinction matters.

There are three broad states:

Broadcast

The transaction has been sent to the network.

Unconfirmed

The transaction has been accepted into mempools but isn’t in a block yet.

Confirmed

A miner or block producer has included it in a block accepted by the network.

RBF applies to the unconfirmed stage.

Once a transaction has been confirmed, you cannot replace it using RBF.

How Does RBF Actually Work?

Suppose you send:

0.005 BTC

to someone.

Your wallet uses a UTXO worth:

0.010 BTC

The transaction contains:

0.005 BTC → Recipient

0.0048 BTC → Change

0.0002 BTC → Fee

The transaction enters the mempool.

But network conditions change.

Now the fee rate needed for faster confirmation is much higher.

Rather than waiting, your wallet can create a replacement transaction.

The new transaction may use:

0.005 BTC → Recipient

0.0044 BTC → Change

0.0006 BTC → Fee

The recipient amount stays the same.

The change output becomes smaller.

The higher fee gives the replacement better economic attractiveness.

This is one reason change outputs are important to fee bumping: wallets can sometimes increase the fee by reducing the amount returned as change.

Bitcoin Core’s bumpfee functionality has historically used this approach, reducing change or adding inputs when necessary.

Does RBF Send the Bitcoin Twice?

No.

This is a common misunderstanding.

Suppose the original transaction spends:

UTXO A

You cannot have both the original transaction and the replacement successfully spend that same UTXO in the blockchain.

They conflict.

If the replacement is accepted and eventually confirmed, the original transaction becomes irrelevant because its input has already been spent by the confirmed replacement.

The same Bitcoin is not successfully spent twice.

The network’s consensus rules prevent both conflicting transactions from becoming valid parts of the same chain history.

RBF and Double Spending

RBF is technically based on transaction replacement, so it is closely related to the concept of conflicting transactions.

But a normal fee bump is not the same thing as a successful double spend.

In a legitimate RBF workflow, the sender replaces their own unconfirmed transaction with another version, usually keeping the intended payment while increasing the fee.

The important point is that the original remains unconfirmed.

Only one conflicting transaction can ultimately consume the same UTXO in the confirmed blockchain.

Is RBF the Same as Cancelling a Bitcoin Transaction?

Not exactly.

Bitcoin transactions generally cannot simply be “cancelled” once broadcast.

A transaction is either confirmed, remains unconfirmed, or eventually disappears from a particular mempool if it is evicted or otherwise no longer relayed there.

RBF doesn’t erase the transaction from history.

Instead, it lets the sender propose a different transaction that conflicts with the unconfirmed one.

For example:

Original
     ↓
Unconfirmed
     ↓
Replacement
     ↓
Confirmed

The original transaction may have been seen by nodes and other systems, but the replacement is the transaction that ultimately gets confirmed.

RBF Is a Mempool Policy

This is one of the most important technical details.

RBF is not a rule saying:

“Every Bitcoin node must accept every higher-fee replacement.”

Instead, transaction replacement is governed by mempool and relay policy.

Bitcoin Core’s current replacement documentation specifies conditions a replacement transaction must satisfy, including paying at least the combined absolute fees of the transactions it replaces and paying enough additional fee to cover the replacement’s relay bandwidth at the configured incremental relay fee. Current policy also imposes limits related to transaction clusters and requires the replacement to improve the mempool’s fee-rate structure.

That’s why simply saying:

“I’ll just make the new fee higher.”

is incomplete.

The replacement still needs to satisfy the node’s acceptance rules.

The Original BIP-125 Approach

You will often see RBF discussed together with BIP-125.

BIP-125 is titled:

“Opt-in Full Replace-by-Fee Signaling.”

It originally described a system where transaction creators could signal that an unconfirmed transaction was replaceable.

One method was to use an input’s nSequence value to signal replacement eligibility.

This became the basis for what many wallets and Bitcoin articles historically call opt-in RBF.

However, the terminology can be confusing today.

Bitcoin Core’s policy has evolved.

What Changed With Full RBF?

Bitcoin Core introduced configurable full RBF policy in version 24.0.

Then, in Bitcoin Core 28.0, full RBF became the default mempool replacement policy. In later releases, the configuration option was removed, making full RBF the standard Bitcoin Core behavior.

This means current Bitcoin Core policy no longer requires BIP-125 signaling for a transaction to be replaceable by policy.

That is an important update because many older articles still describe RBF entirely in terms of opt-in signaling.

Opt-In RBF vs Full RBF

The distinction can be summarized like this.

Opt-In RBF

The transaction signals that it may be replaceable.

This was the traditional approach associated with BIP-125.

Full RBF

A transaction does not need to contain the traditional BIP-125 opt-in signal for a node following full-RBF policy to consider a valid replacement.

Bitcoin Core uses full RBF as its current default policy.

This does not mean every node on the global Bitcoin network necessarily runs identical software or identical policies.

Different nodes can configure policies differently.

So it is more accurate to say:

Bitcoin Core’s current default is full RBF, rather than claiming that every Bitcoin node everywhere behaves identically.

Why Would Someone Want RBF?

The main reason is simple:

The transaction fee wasn’t competitive enough for current conditions.

Imagine you send a transaction when the mempool is relatively calm.

You choose:

3 sat/vB

Then demand increases.

Thousands of additional transactions enter the mempool offering substantially higher fee rates.

Your transaction can now sit below a large portion of the transactions competing for block space.

RBF gives you a way to respond.

Instead of waiting indefinitely, you can create a replacement with a higher fee.

RBF Is Not a Guarantee of Immediate Confirmation

This is extremely important.

Increasing the fee does not guarantee that a transaction will appear in the next block.

The replacement still has to:

Reach nodes.
Be accepted into their mempools.
Meet replacement policy.
Compete with other transactions.
Be selected by a block producer.

If demand rises again, even the replacement can take time to confirm.

So RBF is better understood as a fee-bumping mechanism, not a confirmation guarantee.

What Happens to the Transaction ID?

Because the replacement transaction is a different transaction, it generally has a different transaction ID.

That matters when tracking it.

You might start with:

Original TXID

Then your wallet creates:

Replacement TXID

A block explorer may show the original transaction as replaced, conflicted, or no longer in the active mempool depending on how the explorer tracks transactions.

Therefore, after using RBF, don’t assume the original TXID is still the transaction that will eventually confirm.

The replacement becomes the transaction you need to track.

RBF and Your Change Output

Your change output can play an important role in a fee bump.

Suppose you have:

0.010 BTC input

and your transaction sends:

0.006 BTC

You might initially have:

0.0038 BTC change

and:

0.0002 BTC fee

To increase the fee, the wallet may reduce the change:

0.0030 BTC change

and:

0.0010 BTC fee

The recipient still receives:

0.006 BTC

The difference comes out of your change.

Bitcoin Core’s wallet documentation for fee bumping describes reducing change outputs or, when necessary, adding inputs to pay the higher fee.

RBF and Wallets

You normally don’t need to understand every RBF rule to use it.

A modern wallet may offer a button such as:

“Increase fee”

or:

“Speed up transaction”

Behind the scenes, the wallet can construct a replacement transaction and sign it with your keys.

The important thing is that the wallet must have enough flexibility to create a valid replacement.

For example, if there is sufficient change available, reducing the change may be enough.

Some transactions may be harder to bump.

Bitcoin Core’s wallet RPC also supports fee bumping through bumpfee and psbtbumpfee, with the latter useful in workflows involving PSBTs. Current Bitcoin Core allows these replacement operations under full-RBF policy without requiring BIP-125 signaling.

RBF in One Simple Example

Let’s imagine:

You send 0.005 BTC

Your wallet uses:

0.010 BTC input

The original transaction pays:

0.0048 BTC change

0.0002 BTC fee

But the network becomes busy.

Your wallet creates a replacement:

0.0042 BTC change

0.0008 BTC fee

The recipient still gets:

0.005 BTC

You pay an additional fee.

The new transaction conflicts with the old transaction because both spend the same input.

If the replacement satisfies the applicable mempool policy and is accepted, it can take the original transaction’s place in participating mempools.

The Main Idea to Remember

RBF isn’t a magical way to force Bitcoin to confirm a transaction.

It is a mechanism for replacing an unconfirmed transaction with a conflicting transaction that offers a more attractive fee structure and satisfies the node’s replacement rules.

The basic process is:

Transaction broadcast

↓

Transaction remains unconfirmed

↓

Fee becomes too low for current conditions

↓

Wallet creates replacement

↓

Replacement pays a higher fee

↓

Nodes evaluate the replacement

↓

Replacement competes for block space

↓

One transaction eventually confirms

Once you understand this process, the phrase “Bitcoin transaction stuck” becomes much less mysterious.

How Does a Wallet Increase the RBF Fee?

When you create a Bitcoin transaction, your wallet normally divides the input value between:

Payment outputs

Change outputs

and:

Transaction fee

Suppose your wallet spends:

0.010000 BTC

and sends:

0.006000 BTC

to the recipient.

The original transaction might use:

0.003800 BTC change

and:

0.000200 BTC fee

Now imagine the wallet wants to increase the fee.

It cannot simply create Bitcoin from nowhere.

The additional fee has to come from somewhere.

Usually, the most convenient source is the change output.

The replacement could look like:

Original:

Input      0.010000 BTC
Payment    0.006000 BTC
Change     0.003800 BTC
Fee        0.000200 BTC


Replacement:

Input      0.010000 BTC
Payment    0.006000 BTC
Change     0.003000 BTC
Fee        0.001000 BTC

The recipient still gets 0.006 BTC.

The wallet simply gives less Bitcoin back to itself as change.

Bitcoin Core’s fee-bumping implementation can reduce change outputs to increase the fee; when that isn’t sufficient, it can also use additional inputs where the wallet allows it.

Why Your Change Output Matters

This connects RBF directly to the way Bitcoin transactions work.

The wallet cannot edit a transaction after signing it.

Instead, it creates an entirely new transaction.

That new transaction spends the same original input but allocates the value differently.

For example:

Original Transaction

0.010 BTC input
       ↓
 ┌─────┴─────┐
 ↓           ↓
0.006 BTC   0.0038 BTC
recipient    change
       +
    0.0002 BTC fee


Replacement

0.010 BTC input
       ↓
 ┌─────┴─────┐
 ↓           ↓
0.006 BTC   0.0030 BTC
recipient    change
       +
    0.0010 BTC fee

The original and replacement transactions conflict because they both attempt to spend the same input.

Only one can eventually spend that UTXO in the confirmed blockchain.

What If There Isn’t Enough Change?

Sometimes the original transaction doesn’t have enough change to pay a significantly higher fee.

For example:

Input = 0.010 BTC

Payment = 0.0099 BTC

Original fee = 0.0001 BTC

There is almost nothing left to take from the change output.

In that situation, the wallet may need to add another input to the replacement transaction.

Imagine the wallet has another UTXO worth:

0.003 BTC

It could potentially add that UTXO to the replacement and use part of its value to increase the fee.

However, adding an input also makes the transaction larger.

That means some of the additional input value must cover the extra transaction data as well.

Wallet software therefore has to calculate the replacement carefully.

Why RBF Isn’t Simply “Pay More”

This is one of the biggest misunderstandings about RBF.

You can’t take an existing transaction and simply say:

“Add another 50,000 satoshis to the fee.”

A Bitcoin transaction is a cryptographically signed object.

Changing its outputs changes the transaction itself.

That produces a new transaction and therefore a new transaction ID.

RBF works by creating that new conflicting transaction and getting nodes to accept it under replacement policy.

The Replacement Has to Meet Policy Rules

Bitcoin Core’s current replacement policy is more complicated than simply:

New fee > old fee

The replacement must satisfy several conditions.

For example, the replacement must pay an absolute fee at least as large as the combined fees of the transactions it replaces.

It also needs enough additional fee to cover the bandwidth cost of relaying the replacement according to the node’s incremental relay fee.

Current policy also limits the number of conflicting transaction clusters and requires the replacement to improve the mempool’s fee-rate structure.

For a simple transaction with no complicated descendants, the basic intuition is easier:

The replacement should offer a sufficiently higher fee and fee rate than the original.

But the full policy matters for more complicated transaction chains.

What Is a Fee Rate?

You will often see Bitcoin fees described in:

sat/vB

This means satoshis per virtual byte.

For example:

5 sat/vB

means the transaction pays about five satoshis for every virtual byte of transaction data.

Fee rate matters because Bitcoin blocks have limited space.

Suppose two transactions need roughly the same amount of space:

Transaction A → 5 sat/vB

Transaction B → 40 sat/vB

A miner generally has a stronger economic reason to include the higher-fee transaction, all else being equal.

That’s why wallets consider both the transaction’s total fee and its size.

Absolute Fee vs Fee Rate

These terms are related but not identical.

Imagine:

Transaction A

Size: 200 vB

Fee: 10,000 sats

Fee rate: 50 sat/vB

Now consider:

Transaction B

Size: 500 vB

Fee: 15,000 sats

Fee rate: 30 sat/vB

Transaction B pays a larger total fee.

But Transaction A pays the higher fee rate.

This distinction becomes especially important for RBF.

Current Bitcoin Core replacement policy requires the replacement to pay at least the combined absolute fees of the transactions it replaces, plus the applicable incremental relay cost. It also considers the broader mempool fee-rate structure.

What Is CPFP?

RBF isn’t the only way to accelerate an unconfirmed Bitcoin transaction.

The other major technique is:

CPFP — Child Pays for Parent

The concept is very different.

With RBF, you replace the original transaction.

With CPFP, you create a new child transaction that spends an output from the original unconfirmed transaction.

The child transaction pays a high fee.

Together, the parent and child can become economically attractive for inclusion in a block.

The basic idea looks like this:

Parent Transaction
Low Fee
     ↓
Unconfirmed Output
     ↓
Child Transaction
High Fee
     ↓
Combined Package
     ↓
Miner

The high fee on the child can compensate for the low fee on the parent.

A Simple CPFP Example

Imagine Alice sends Bob Bitcoin.

The parent transaction pays:

0.0001 BTC fee

but network congestion increases.

The transaction remains unconfirmed.

Bob’s wallet has already received the unconfirmed output.

Bob now creates a second transaction spending that output.

The child transaction pays:

0.001 BTC fee

A miner considering both transactions can earn the combined fees by including the parent and child.

So the package may become attractive even though the parent itself has a low fee rate.

That is the core idea behind CPFP.

RBF vs CPFP

The two methods solve related problems differently.

Feature	RBF	CPFP
Full name	Replace-by-Fee	Child Pays for Parent
Basic action	Replace an unconfirmed transaction	Create a child spending an unconfirmed output
Who normally initiates it?	Sender	Sender or recipient with a spendable output
Original transaction	Replaced	Remains the parent
New transaction	Conflicts with original	Depends on original
Main tool	Higher-fee replacement	High-fee child
Requires change?	Often useful	Not necessarily
Works after receiving an unconfirmed output?	Usually sender-focused	Often useful to recipient

The important difference is:

RBF replaces.

CPFP adds.

When Is RBF Better Than CPFP?

RBF is naturally useful when you are the sender and the original transaction has a replaceable structure.

For example:

You send Bitcoin → Fee becomes too low → You increase the fee

That’s a classic RBF scenario.

CPFP can be useful when the recipient already controls an unconfirmed output.

For example:

You receive Bitcoin → Parent transaction has a low fee → You spend the incoming output with a high-fee child

This can motivate miners to include both transactions.

Can You Use Both RBF and CPFP?

They are different mechanisms, but a transaction can exist within a broader chain where both mechanisms matter.

For example, the sender might replace a parent transaction.

A recipient might then spend an output from the accepted version using a child transaction.

In more advanced transaction systems, these interactions can become complicated.

Bitcoin Core’s modern mempool design evaluates connected transaction groups, called clusters, rather than viewing every transaction as completely isolated. Current Core policy limits clusters and uses their fee-rate structure when evaluating mempool transactions and replacements.

For ordinary users, the main takeaway is simply:

A transaction’s children can affect the economics of the transaction package.

What Happens if Your Transaction Has a Child?

Suppose your original transaction creates a change output.

You immediately spend that change output in another unconfirmed transaction.

Now the original transaction has a descendant.

The two transactions form a connected chain:

Parent
  ↓
Child

Replacing the parent becomes more complicated because the replacement may conflict with the parent and its descendants.

Bitcoin Core’s current RBF policy considers the directly conflicting transactions and their unconfirmed descendants together when evaluating a replacement.

This means a transaction that has already been spent by another unconfirmed transaction is not equivalent to a standalone transaction.

Why Descendants Matter

Imagine:

Parent → Child → Grandchild

If you attempt to replace the parent, you are dealing with a connected transaction structure rather than one isolated transaction.

A replacement may need to account for the entire affected set.

This is one reason advanced wallet software has to understand transaction dependencies.

Bitcoin Core 31.0 introduced the cluster-mempool design, which changed how connected unconfirmed transactions are represented and evaluated. Current default cluster limits include up to 64 transactions and 101 kB of virtual size per cluster.

You don’t need to memorize these limits to use Bitcoin.

But they explain why modern RBF behavior can be more sophisticated than the simple examples found in older Bitcoin tutorials.

Why Some Transactions Cannot Be Bumped Easily

Several things can make fee bumping more difficult.

The Transaction Is Already Confirmed

RBF only concerns unconfirmed transactions.

Once a transaction is confirmed in the blockchain, you cannot replace it with another transaction spending the same input.

Your Wallet Doesn’t Support RBF

A wallet needs to know how to construct and sign the replacement.

Not every wallet exposes fee bumping in the same way.

There Isn’t Enough Value to Increase the Fee

A transaction may have little or no change.

If the outputs already consume almost all the input value, there may be limited room to increase the fee without changing the payment itself.

The Replacement Doesn’t Meet Policy

A replacement with a higher fee can still be rejected if it doesn’t satisfy the node’s replacement conditions.

Current Bitcoin Core policy includes absolute-fee, incremental-fee, cluster, and fee-rate-structure requirements.

The Transaction Has Complicated Descendants

If the transaction has unconfirmed children, replacing it may affect the connected transaction structure.

This can make the replacement more complicated than simply increasing the fee on a standalone transaction.

What About Opt-In RBF Signaling?

Historically, BIP-125 defined opt-in RBF signaling using transaction sequence numbers.

A wallet could mark a transaction as replaceable so nodes following the policy would treat it as eligible for replacement.

But current Bitcoin Core policy has moved beyond that model.

Full RBF became the default policy in Bitcoin Core 28.0, and the signaling requirement was later removed. The current Core documentation states that signaling is no longer required for replacement under its default policy.

So an older article saying:

“RBF only works if the transaction opted in.”

can be outdated when describing current Bitcoin Core policy.

However, different nodes and wallet software can still implement different policies, so users should not interpret this as saying every node on the network behaves identically.

How Do Wallets Actually Perform Fee Bumping?

The user experience varies.

A wallet may show:

Increase fee

Speed up

Bump fee

or a similar option.

Underneath the interface, the wallet can:

Find the original transaction.
Check that it can construct a replacement.
Select the appropriate inputs.
Adjust change or inputs.
Calculate a higher fee.
Sign the new transaction.
Broadcast the replacement.

Bitcoin Core’s bumpfee RPC creates a replacement transaction, while psbtbumpfee produces a PSBT instead, allowing an external signer to participate in the fee-bumping workflow.

This is particularly useful for hardware-wallet setups.

RBF With Hardware Wallets

Suppose you created a transaction using a hardware wallet.

The private key stays inside the hardware device.

Later, the fee turns out to be too low.

The wallet software can construct a replacement PSBT.

The hardware wallet can then review and sign the replacement.

The workflow becomes:

Original Transaction
        ↓
Transaction remains unconfirmed
        ↓
Wallet constructs replacement PSBT
        ↓
Hardware wallet signs replacement
        ↓
Replacement broadcast
        ↓
Confirmation

The hardware wallet doesn’t need to expose the private key.

This is one reason PSBT is useful in advanced Bitcoin wallet workflows.

What Happens to the Original Transaction?

Once a replacement is accepted by a node, the conflicting original transaction may be removed from that node’s mempool.

However, different nodes can have different mempool states.

A node may have:

Original transaction

while another node may already have:

Replacement transaction

because transaction relay takes time and policies can differ.

Eventually, one transaction can be confirmed on-chain.

The confirmed transaction becomes part of the blockchain history.

Why Different Block Explorers May Show Different Statuses

After an RBF replacement, you may notice confusing information on different block explorers.

One explorer might show:

Replaced

Another might show:

Conflicted

Another might simply stop displaying the transaction as unconfirmed.

These interfaces can differ because explorers use their own infrastructure and indexing logic.

The important thing is to identify the transaction that ultimately appears in a confirmed block.

Can a Recipient Reject an RBF Transaction?

This question matters for merchants.

An unconfirmed Bitcoin transaction is not the same as a confirmed payment.

A recipient may see a transaction in their wallet and consider it “pending.”

But if the transaction is replaceable under the relevant network policies, the sender may potentially replace it with another transaction.

For high-value payments, relying solely on an unconfirmed transaction can therefore introduce additional risk.

The safest point for final settlement is confirmation according to the recipient’s required policy.

RBF is one reason merchants need to distinguish between:

Seen by my wallet

and:

Confirmed by the Bitcoin blockchain

Can a Merchant Prevent RBF?

A merchant can choose its own acceptance policy for unconfirmed transactions.

However, a merchant cannot control what every Bitcoin node on the network does.

Current full-RBF behavior means the absence of traditional opt-in signaling no longer guarantees that a transaction won’t be replaced by nodes following current Bitcoin Core policy.

For that reason, applications that accept zero-confirmation payments need their own risk policies rather than assuming an unconfirmed transaction is permanently fixed.

RBF Does Not Reverse a Confirmed Payment

Suppose your transaction has already been confirmed.

You cannot use RBF to undo it.

RBF is specifically about replacing conflicting unconfirmed transactions.

Once your transaction is confirmed, changing it would require creating another transaction spending the newly created outputs, assuming those outputs are yours and spendable.

That is an entirely different operation.

A Simple Decision Tree

When your Bitcoin transaction is stuck, the situation can be thought about like this:

Is the transaction confirmed?
        |
      YES → RBF is no longer applicable.
        |
       NO
        ↓
Can your wallet create a replacement?
        |
      YES → Consider RBF.
        |
       NO
        ↓
Do you control a spendable
unconfirmed output?
        |
      YES → CPFP may be possible.
        |
       NO
        ↓
Wait for confirmation or
use your wallet's available
recovery/fee tools.

This is only a simplified guide.

Wallet capabilities and node policies vary, and complicated transaction chains can require more analysis.

The Most Important Difference

If you remember only one thing from this article, remember this:

RBF replaces the transaction.

CPFP creates another transaction that helps pay for the original.

RBF:

Old transaction
      ↓
Higher-fee replacement

CPFP:

Low-fee parent
      ↓
High-fee child

Both mechanisms can help when a transaction isn’t confirming quickly enough.

But they work at different levels of the transaction chain.

Why RBF Is an Important Bitcoin Feature

Bitcoin’s block space is limited.

Users compete for inclusion by offering transaction fees.

When network demand changes, a fee that looked reasonable earlier may become less attractive later.

RBF gives senders a mechanism to adapt.

Instead of treating the original fee as permanently fixed, the wallet can construct a replacement transaction with a different fee structure.

That’s useful for ordinary users who accidentally underpay a fee and for advanced Bitcoin applications that need predictable fee-management tools.

However, RBF doesn’t guarantee immediate confirmation.

It simply gives the sender another transaction that can compete under the network’s replacement policy.

How Can You Tell Whether a Bitcoin Transaction Is RBF?

This question is more complicated than it used to be.

Historically, wallets could signal RBF using transaction sequence numbers under the rules described by BIP-125.

That meant an observer could examine a transaction and determine whether it had explicitly signaled opt-in replaceability. BIP-125 was designed around this opt-in signaling model. (github.com)

However, Bitcoin Core’s policy has changed.

Full RBF became the default policy in Bitcoin Core 28.0, and current Bitcoin Core no longer requires the traditional BIP-125 signal for a transaction to be considered for replacement under its default policy.

So an old rule like:

“No RBF signal means the transaction cannot be replaced.”

is no longer accurate for current Bitcoin Core policy.

Different nodes can still use different policies, so the exact behavior of a transaction across the network can vary.

Does RBF Mean a Transaction Is Unsafe?

Not automatically.

RBF is a fee-management mechanism.

For the sender, it can be extremely useful because it provides a way to respond when the original fee is too low.

The bigger concern is with zero-confirmation payments.

Imagine a merchant sees:

Payment received

but the transaction has:

0 confirmations

The merchant may deliver goods before the transaction enters a block.

If the transaction is later replaced by another conflicting transaction, the merchant could face a loss.

This doesn’t mean RBF itself is malicious.

It means an unconfirmed Bitcoin transaction should not be treated as equivalent to a confirmed transaction.

For larger payments, businesses can require one or more confirmations according to their own risk policy.

What Are Zero-Confirmation Transactions?

A zero-confirmation transaction is simply a transaction that has been broadcast but has not yet been included in a confirmed block.

For example:

Wallet
  ↓
Transaction broadcast
  ↓
Mempool
  ↓
0 confirmations

Once a miner includes the transaction in a block:

Mempool
  ↓
Included in block
  ↓
1 confirmation

Additional blocks can then build on top of it.

RBF matters most during that unconfirmed period.

Once the transaction is confirmed, its inputs have been consumed in the blockchain history and it is no longer an RBF candidate.

Why Should Merchants Care About RBF?

Suppose a customer wants to buy something worth:

$500

They send Bitcoin.

The merchant’s wallet detects the transaction immediately.

But the transaction has:

0 confirmations

The merchant could accept the payment instantly.

Or the merchant could wait for confirmation.

Those are different risk choices.

A transaction appearing in the mempool doesn’t provide the same settlement finality as a confirmed transaction.

RBF makes this distinction especially important because an unconfirmed transaction can potentially be replaced under the applicable network policy.

For this reason, businesses that accept Bitcoin should define their own rules for zero-confirmation payments rather than assuming every visible transaction is final.

What Happens If Your Transaction Disappears From the Mempool?

This can be confusing.

You send a transaction.

You see it in your wallet.

Later, a block explorer says:

“Transaction not found.”

Or the transaction disappears from the node’s mempool.

That doesn’t automatically mean your Bitcoin is lost.

Several things could have happened.

Possibility 1: The Transaction Was Replaced

The sender may have used RBF.

The original transaction stopped being the transaction that the network was attempting to confirm.

A replacement transaction now spends the same input and may eventually confirm instead.

You should check whether your wallet generated a replacement transaction ID.

Possibility 2: The Transaction Was Evicted

Mempools are not permanent databases.

Nodes can remove transactions from their mempool for policy reasons, including when the mempool is full and transactions are evicted.

A transaction disappearing from one node’s mempool does not automatically mean that the transaction has become invalid.

Your wallet may rebroadcast it later if it remains valid and unconfirmed.

The exact behavior depends on the wallet, node, and network conditions.

Possibility 3: The Transaction Never Reached Every Node

Bitcoin transactions spread through a peer-to-peer network.

A transaction shown in your wallet may not have reached every node.

Different nodes can temporarily have different mempool contents.

Therefore, seeing a transaction on one explorer or node doesn’t guarantee every other node currently holds the same transaction.

What Should You Do When a Transaction Is Stuck?

Start by checking its status.

Look for:

Transaction ID

Confirmation count

Fee rate

Current mempool status

If it has:

0 confirmations

and your wallet supports fee bumping, check whether an Increase Fee, Bump Fee, or Speed Up option is available.

If the wallet creates a replacement, keep track of the new transaction ID.

Don’t repeatedly attempt to send the payment again without understanding what happened to the original transaction.

Doing so can create unnecessary confusion.

Don’t Panic and Send the Same Payment Again

This is an important beginner mistake.

Suppose you send:

0.005 BTC

and the transaction remains unconfirmed.

You might be tempted to simply press:

Send

again.

But doing so may create another transaction.

You could end up with multiple conflicting or related transactions and make the situation more complicated.

First determine:

Is the original transaction still pending?

Was it replaced?

Did it confirm?

Can the wallet bump its fee?

Your wallet’s transaction history and a block explorer can help answer these questions.

RBF Does Not Mean You Pay the Higher Fee Twice

Suppose your original transaction paid:

20,000 satoshis

in fees.

You replace it with one paying:

50,000 satoshis

You are not necessarily paying:

20,000 + 50,000

as two confirmed transaction fees.

The replacement is intended to take the place of the original conflicting transaction.

Only the transaction that ultimately becomes part of the blockchain consumes the relevant input in the confirmed chain.

The original fee may have existed only in the unconfirmed transaction that was later replaced.

Can RBF Be Used to Steal Bitcoin?

RBF itself doesn’t give someone the ability to take arbitrary Bitcoin.

A valid replacement still needs to satisfy Bitcoin’s transaction validation and signing rules.

A stranger cannot simply choose your UTXO and create a replacement transaction spending it without the required authorization.

The real concern is different:

A sender can potentially replace their own unconfirmed payment before confirmation.

That is why recipients should distinguish between:

unconfirmed payment

and:

confirmed payment

The security model of Bitcoin still requires control of the relevant private keys to spend the inputs.

Is RBF a Double-Spend?

RBF involves conflicting transactions because the replacement spends the same inputs as the transaction it replaces.

So, technically, there are two transactions competing to spend the same UTXO.

But that doesn’t mean both transactions become confirmed.

Only one can ultimately spend that UTXO in the blockchain’s valid history.

A normal fee bump is therefore better understood as:

Replacing an unconfirmed transaction with another transaction

rather than:

Successfully spending the same Bitcoin twice.

RBF vs CPFP vs Waiting

When a transaction is unconfirmed, there are several possible paths.

Situation	Possible approach
You control the sender wallet and it supports fee bumping	RBF
You control an unconfirmed child output	CPFP
Fee is already competitive	Wait
Transaction has disappeared from your node	Check wallet/node status
Transaction is confirmed	RBF no longer applies
Replacement is rejected	Investigate policy and transaction structure

This isn’t a universal troubleshooting rule.

Wallet software, node configuration, transaction structure, and mempool conditions all matter.

But it provides a useful starting point.

RBF and Modern Bitcoin Core

RBF policy has changed considerably over Bitcoin Core’s history.

The timeline is useful:

Bitcoin Core 0.12

Opt-in RBF support was introduced.

Bitcoin Core 24.0

Full RBF became available as configurable mempool policy.

Bitcoin Core 28.0

Full RBF became the default policy.

Later releases

The traditional full-RBF configuration option was removed because full RBF had become standard behavior.

Bitcoin Core’s current replacement policy also uses newer mempool concepts introduced with cluster mempool.

Since Bitcoin Core 31.0, connected transactions are organized into clusters, and replacement validation considers whether the replacement improves the mempool’s fee-rate structure.

This is why some older RBF explanations no longer describe the complete modern behavior.

Why Bitcoin Core 31 Changed the Mempool Model

This may sound very technical, but the basic idea is useful.

Transactions are often connected.

For example:

Parent
  ↓
Child
  ↓
Grandchild

Older mempool logic treated ancestor and descendant limits differently.

Bitcoin Core 31 introduced cluster mempool, which organizes connected transactions into clusters and uses their combined economics when ordering, evicting, and evaluating replacements.

Current default policy limits a cluster to 64 transactions and 101 kB of virtual size.

For most Bitcoin users, you won’t need to think about these limits.

But they matter to wallet developers and applications building advanced transaction systems.

How Hardware Wallets Handle RBF

RBF doesn’t require giving up self-custody.

A hardware wallet can still protect your private keys while your wallet software constructs the replacement transaction.

For example:

Unconfirmed Transaction
        ↓
Wallet creates replacement PSBT
        ↓
Hardware wallet reviews/signs
        ↓
Replacement transaction
        ↓
Broadcast

Bitcoin Core’s external-signer documentation describes fee-bumping workflows using bumpfee, while psbtbumpfee can produce a PSBT for manual signing by an external signer.

The private key can therefore remain inside the signing device.

How to Avoid Getting Stuck in the First Place

RBF is useful, but avoiding unnecessary fee problems is even simpler.

Use a Reliable Wallet

Choose wallet software that provides sensible fee estimation and fee-bumping options.

Understand Fee Rates

Bitcoin fees depend on transaction size and network demand.

A fee that was reasonable earlier may become less competitive later.

Keep Change Available

If your wallet has no meaningful change and the transaction consumes almost all input value, fee bumping can be more complicated.

Don’t Rush When Fees Are Unusually High

When the network is busy, consider whether the transaction is urgent.

Keep Your Wallet Updated

Fee-bumping behavior and Bitcoin Core policy can evolve over time.

Common RBF Mistakes

Mistake 1: Assuming a Higher Fee Guarantees the Next Block

It doesn’t.

The replacement still competes with other transactions.

Mistake 2: Assuming RBF Means the Original Transaction Is Confirmed Twice

It isn’t.

The conflicting transactions compete for the same inputs.

Mistake 3: Thinking Every Unconfirmed Transaction Can Be Bumped

Wallet support and transaction structure matter.

Mistake 4: Treating RBF as a Way to Cancel a Payment

RBF doesn’t provide a general “undo” function.

A replacement still has to spend the same inputs and obey Bitcoin’s rules.

Mistake 5: Assuming Old BIP-125 Rules Describe All Modern RBF Behavior

BIP-125 remains an important historical and deployed specification, but current Bitcoin Core full-RBF policy has evolved beyond its original opt-in signaling model.

Mistake 6: Paying an Enormous Fee Without Checking the Transaction

A fee increase can cost significantly more Bitcoin.

Always review the new fee before signing.

Hardware wallets and reputable wallet software can help make that review easier.

Frequently Asked Questions

What does RBF mean in Bitcoin?

RBF means Replace-by-Fee. It allows an unconfirmed transaction to be replaced by a conflicting transaction that satisfies the applicable replacement policy and generally pays a higher fee.

Can RBF speed up a Bitcoin transaction?

It can improve a transaction’s fee competitiveness, which may help it confirm sooner, but RBF does not guarantee a particular confirmation time.

Can I use RBF after a transaction confirms?

No. RBF applies to unconfirmed transactions.

Does RBF send Bitcoin twice?

No. Conflicting transactions compete to spend the same inputs, but only one can ultimately spend those inputs in the confirmed blockchain.

Does RBF cancel the original transaction?

It doesn’t literally erase the original transaction from every system that has seen it. Instead, a replacement transaction can take its place in the mempool and eventually become the confirmed transaction.

What is full RBF?

Full RBF is a replacement policy that does not require the traditional BIP-125 opt-in signal. It is the default replacement policy in current Bitcoin Core.

Is BIP-125 still relevant?

Yes. BIP-125 remains the historical specification for opt-in full-RBF signaling and is still listed as deployed. Current Bitcoin Core policy, however, has evolved beyond requiring that signal.

What is the difference between RBF and CPFP?

RBF replaces the original unconfirmed transaction.

CPFP creates a new child transaction that spends an output from the unconfirmed parent and uses the child’s fee to improve the economics of the package.

Can the recipient use RBF?

RBF is primarily a sender-side replacement mechanism because replacing the transaction requires creating a new transaction spending the same input set. A recipient who controls an unconfirmed output may instead be able to use CPFP.

Why did my Bitcoin transaction disappear?

It may have been replaced, evicted from a mempool, or simply no longer be present in the node or explorer you are checking. Check the transaction status and your wallet’s transaction history before taking further action.

Can a hardware wallet use RBF?

Yes. The wallet software can construct a replacement transaction or PSBT, and a compatible hardware wallet can sign it without exposing the private key. Bitcoin Core supports both bumpfee and PSBT-based fee bumping workflows.

Does RBF cost extra?

Replacing a transaction generally means paying a higher total fee than the original transaction. The additional cost comes from the higher fee required for the replacement.

Does RBF work with every Bitcoin wallet?

No. Wallets differ in their support for fee bumping, transaction construction, and replacement policies.

RBF in One Example

Let’s reduce everything to one final example.

You send:

0.005 BTC

Your wallet uses:

0.010 BTC

The original transaction pays:

0.0048 BTC change

and:

0.0002 BTC fee

The transaction remains unconfirmed.

Your wallet decides that the fee needs to increase.

It constructs a replacement:

0.0040 BTC change

and:

0.0010 BTC fee

The recipient still receives:

0.005 BTC

The replacement spends the same original input.

If nodes accept the replacement under their policies and it eventually gets included in a block, that replacement becomes the confirmed transaction.

The original transaction does not also become confirmed using the same input.

That’s RBF.

The Big Picture

Bitcoin transactions don’t have a permanent fee attached to an input before confirmation.

The sender creates a specific transaction with specific inputs, outputs, and fee.

If that transaction remains unconfirmed, RBF can provide a way to create a different version.

The process is:

Original transaction

↓

Still unconfirmed

↓

Network conditions change

↓

Wallet constructs replacement

↓

Higher fee

↓

Replacement passes policy

↓

Replacement propagates

↓

Miner selects transaction

↓

Confirmation

RBF therefore gives Bitcoin users more flexibility when fee conditions change.

Final Thoughts

Bitcoin transactions can get stuck because the fee rate that looked reasonable when the transaction was created may no longer be competitive with the transactions waiting in the mempool.

Replace-by-Fee provides a solution.

Instead of waiting indefinitely, a sender can create a replacement transaction that spends the same inputs while offering a higher fee and satisfying the applicable replacement rules.

The practical workflow is usually simple:

Check the transaction → Increase the fee → Sign the replacement → Broadcast → Wait for confirmation

Behind that simple wallet button is a more sophisticated system involving:

UTXOs
Transaction fees
Change outputs
Mempool policy
Fee rates
Transaction conflicts
RBF rules
CPFP
Package and cluster behavior

The most important distinction is this:

RBF replaces an unconfirmed transaction.

CPFP adds a child transaction to improve the economics of the parent.

Neither method guarantees instant confirmation.

They simply give Bitcoin users tools for responding when transaction fees and network conditions change.

For everyday users, that means a transaction showing 0 confirmations doesn’t automatically mean something has gone wrong.

Check its fee rate, mempool status, wallet support, and whether a fee-bump option is available before taking further action.

Once you understand RBF, the next time you see “Bitcoin transaction pending”, you can understand what is actually happening instead of assuming your Bitcoin has disappeared.