Stuck transaction? How to fix it
How RBF and CPFP actually work
By mordom
You send a transaction. The wallet says “sent.”
Then you wait.
After an hour it’s still unconfirmed. After a few hours you start to worry.
The exchange doesn’t credit, the payment doesn’t arrive, the recipient messages you.
At that point, it feels like there’s nothing you can do.
In reality, you can do something — but only if you understand what’s actually happening.
Why a transaction gets stuck
A transaction doesn’t go straight into a block. First, it enters the mempool: a public queue where transactions wait.
Miners choose which transactions to include based on one thing: how much they pay in fees relative to the space they take.
This is the fee market.
Paying a fee doesn’t mean getting confirmed quickly. It just means you’re participating in the competition.
If your fee is too low for current conditions:
- you get outbid by other transactions
- you stay in the queue
- you can remain stuck for hours or days
RBF: you’re not increasing the fee, you’re replacing the transaction
RBF (Replace-By-Fee) is often described as “increasing the fee.”
That’s not accurate.
When you use RBF, you create a new transaction that:
- uses the same inputs
- pays a higher fee
- replaces the previous one in the mempool
You are not modifying the original transaction. You are replacing it.
RBF today: less predictable than before
In the past, there was a clear rule:
a transaction could only be replaced if it was explicitly marked as RBF at the time of sending (Opt-in RBF, BIP 125).
If you didn’t do that, you were stuck. Today, it’s no longer that simple.
With the introduction of Full-RBF (now default in Bitcoin Core 28.0), many nodes accept replacements even without explicit opt-in.
This has sparked intense debate among developers.
Figures like John Carvalho of Synonym have strongly criticized this change, arguing that it undermines the reliability of “zero-conf” transactions (accepted without confirmations).
If every transaction is replaceable by default, a merchant who hands you a coffee before the first confirmation risks you broadcasting a replacement transaction to yourself seconds later.
For you as a user, this means one thing: RBF is now an intrinsic property of the network.
What happens to UTXOs with RBF
From a technical perspective, RBF is a full replacement.
You are reusing the same inputs (the same UTXOs) and redefining the outputs.
The higher fee usually comes from reducing the change output.
This detail matters.
If the change is too small, you may not have enough margin to increase the fee as much as needed.
In that case, even RBF becomes limited.
CPFP: when you can’t replace, you can “pull it through”
If you can’t use RBF — or it’s not enough — there’s another option: CPFP (Child Pays For Parent).
Here you don’t touch the original transaction.
Instead, you create a new one that spends one of its unconfirmed outputs.
This is the key point: you must be able to spend an output of the stuck transaction.
In practice, this is usually the change.
But it’s not the only case.
The recipient can do it too. And this is a real scenario, especially with exchanges or custodial services.
If they receive a transaction with low fees and want it confirmed quickly, they can create a new transaction (the “child”) spending those funds — paying a much higher fee.
Why it actually works
At first glance, it seems odd: why would a miner include a low-fee transaction?
Because miners don’t look at transactions in isolation — they look at the overall result.
When a child depends on a parent, the two form a package.
And the miner evaluates whether that package is profitable.
In practice, the calculation is simple:
“This transaction pays very little.”
“But to include the next one, I must include this one too.”
“Overall, how much do I earn?”
If the answer is “enough,” both get included.
Concrete example:
The parent pays 5 sat/vB. The child pays 800 sat/vB. The average for the package is still high.
Result: both are included in the same block.
The parent didn’t become cheaper — it was simply pulled in by a more profitable transaction.
The real limitation
CPFP only works if you have access to a spendable output.
If the transaction has no change — for example, because you sent everything to a single recipient — you can’t do anything from the sender side.
In that case, only the recipient can act.
Even when change exists, it might not be enough.
If it’s too small, you can’t build a child transaction with a fee high enough to compensate for the parent.
Example: If you send 0.5 BTC starting from a 0.50001 BTC UTXO, your change will be tiny (so-called dust). If the transaction gets stuck, you won’t have enough satoshis in that change to pay a CPFP fee that makes a difference.
This is where many people get stuck: they think they have an option, but in reality they don’t have enough “leverage” to use it.
What’s really happening (UTXO, not balance)
The problem isn’t “the transaction is slow.”
The problem is how you built it.
Bitcoin doesn’t use balances. It uses UTXOs.
Every transaction:
- consumes existing UTXOs
- creates new UTXOs
If the transaction isn’t confirmed, the new UTXOs exist — but they’re locked in a dependency.
With RBF, you’re rewriting that structure.
With CPFP, you’re building on top of that structure.
In both cases, you’re working with the same building blocks: UTXOs.
Check out our article about UTXOs and balances to learn more about that.
Real mistakes that lead to this
Most problems start before the transaction is even sent.
The first is delegating everything to the wallet.
Automatic fee estimation works most of the time, but not always. When it fails, you notice after the fact.
Another common mistake is ignoring transaction structure.
A transaction without change is clean, but leaves you with no options if something goes wrong.
Then there’s the case of change that’s too small: it exists, but isn’t usable in practice.
Finally, once you start chaining unconfirmed transactions, you create dependencies.
At that point, every new operation becomes more fragile.
How to avoid getting stuck
The difference isn’t knowing how to use RBF or CPFP — it’s how you build the transaction in the first place.
Understanding the context before sending means not blindly trusting the wallet’s fee estimate.
If the payment is important or time-sensitive, it makes sense to check the current fee level manually.
The wallet you use also matters. You need a tool that shows what’s going on, not just a button to click “send.”
Today, RBF is less something you explicitly enable and more something that can happen.
But understanding how it works allows you to use it consciously when needed.
Finally, change is not a technical detail to ignore — it’s what gives you flexibility after sending.
The key point
When a transaction gets stuck, it’s not a system failure.
It’s the result of three things:
- a competitive fee market
- a UTXO-based model
- the choices made at the time of sending
RBF and CPFP are not shortcuts.
They are tools that only work if you understand what you built.
If it’s already happened to you, now you know why. If it hasn’t yet, it will.
The difference is knowing, in that moment, that you’re not stuck by chance — but because of how you constructed the transaction.
If you want a setup where transactions behave predictably — even under pressure — you can explore how BitVault approaches this differently: https://www.bitvault.sv