A Bitcoin transaction can remain unconfirmed for hours—or longer—when its fee rate is too low for current mempool demand. The coins are not automatically lost. In many cases the sender can replace the transaction with a higher-fee version, or the owner of one of its outputs can create a child transaction that makes the package more attractive to miners.
Quick answer: use Replace-by-Fee (RBF) when the sending wallet can create a valid higher-fee replacement. Use Child-Pays-for-Parent (CPFP) when you can spend an output from the unconfirmed transaction and pay enough for both transactions as a package. Do not improvise with private keys or “recovery agents.” Follow the wallet’s documented fee-bump feature.
Why Bitcoin transactions get stuck
Bitcoin block space is limited. Wallets normally choose a fee in satoshis per virtual byte (sat/vB), and miners select transactions according to fee revenue and policy. When demand rises, a fee rate that looked reasonable at broadcast time may fall below the range being confirmed.
Common causes include:
- a wallet used a slow or stale fee estimate;
- mempool demand increased after broadcast;
- the transaction is large because it spends many UTXOs;
- an unconfirmed parent transaction also has a low fee;
- the sender manually selected a fee below current relay or mining preferences; or
- a service delayed broadcasting or batching a withdrawal.
A block explorer can show the transaction ID, confirmation status, virtual size, fee rate, and unconfirmed ancestors. Use more than one reputable explorer if the status is unclear, because individual services can have different mempool views.
What Replace-by-Fee does
RBF creates a new transaction that conflicts with the original by spending at least one of the same inputs. The replacement pays a higher absolute fee and fee rate under applicable relay rules. If miners confirm the replacement, the original can no longer confirm because its inputs have already been spent.
In a consumer wallet, the feature may be labelled Speed up, Bump fee, or Increase fee. The wallet usually reduces the change output or adds another input to fund the higher fee. It then signs and broadcasts the replacement.
When RBF is the better option
- You created the original transaction.
- Your wallet retained the transaction data and supports fee bumping.
- The transaction is replaceable under the wallet and network policy in use.
- You still control enough change or additional inputs to pay the increase.
Before approving, verify every recipient and amount. A legitimate fee bump normally preserves the intended payment and changes only the fee funding or change. If a tool asks for a seed phrase, stop: fee bumping does not require giving a recovery phrase to a website or support agent.
What Child-Pays-for-Parent does
CPFP takes a spendable output from the unconfirmed parent and creates a child transaction with a high fee. A miner that wants the child must confirm the parent first, so the miner evaluates the combined package.
The relevant number is the package fee rate:
Package fee rate = (parent fee + child fee) ÷ (parent vsize + child vsize)
Imagine a 200-vB parent paid 400 satoshis, or 2 sat/vB. A 150-vB child pays 6,600 satoshis. Together they pay 7,000 satoshis across 350 vB, producing an effective package rate of 20 sat/vB. Whether that is enough depends on current conditions and node policy.
Who can use CPFP?
The recipient may be able to spend the incoming unconfirmed output. The sender may also be able to spend an unconfirmed change output. The wallet must support spending unconfirmed funds and build the child correctly. Some custodial services do not expose this control.
CPFP can be inefficient if the parent has several ancestors or the child is large. Package relay and mining policies also impose limits. Use a wallet’s native feature rather than trying to calculate a raw transaction unless you understand UTXOs, signing, change, and fee policy.
RBF vs CPFP
| Question | RBF | CPFP |
|---|---|---|
| Who usually initiates it? | Original sender | Recipient or sender controlling an output |
| What changes? | Original transaction is replaced | A new child is added |
| Fee target | Replacement must satisfy relay fee rules | Parent and child need a competitive package rate |
| Common wallet label | Speed up / bump fee | CPFP / spend unconfirmed output |
| Main limitation | Wallet or transaction may not support replacement | You must control a suitable output and pay for both sizes |
A safe troubleshooting sequence
- Confirm the transaction exists. Copy the transaction ID from the wallet and inspect it in reputable explorers.
- Check for confirmation. Never create a competing manual payment just because one app has not refreshed.
- Confirm the destination. A fee bump cannot correct a payment already sent to the wrong address.
- Review current fee estimates. Compare the proposed replacement or package rate with your desired confirmation horizon.
- Use the wallet’s built-in RBF option first if you are the sender and it is available.
- Consider CPFP only if a suitable output is under your control and your wallet supports it.
- Contact a custodial platform when it created the withdrawal. Only the platform may be able to replace or accelerate its transaction.
- Wait when no safe bump is available. Mempool demand may fall, or nodes may eventually evict the transaction. Wallet behavior after eviction varies, so follow its documentation before re-spending.
Mistakes to avoid
- Do not share a seed phrase or private key with a block explorer, “miner,” or recovery service.
- Do not send a second independent payment to the recipient unless both parties understand that both payments could confirm.
- Do not assume repeated rebroadcasting raises priority; it does not increase the fee.
- Do not calculate only the child’s fee rate for CPFP; miners care about the package economics.
- Do not treat an unconfirmed transaction as final for high-value delivery without an appropriate risk policy.
For background on how Bitcoin transactions are created, see our guide to paying with Bitcoin. To understand why miners choose fee-paying transactions, read how Bitcoin mining works.
Frequently asked questions
Can a Bitcoin transaction stay unconfirmed forever?
There is no universal mempool shared by every node. Nodes may keep, rebroadcast, or evict transactions according to local policy. An evicted transaction can also reappear if rebroadcast. Check your wallet before attempting any new spend.
Does one confirmation mean the payment cannot change?
Confirmation sharply reduces replacement risk, but finality is probabilistic. The appropriate confirmation count depends on value, threat model, and the recipient’s policy.
Can the recipient perform RBF?
Normally the sender creates the replacement because the sender controls the inputs. A recipient who controls an output may instead use CPFP.
This is educational information, not a substitute for wallet-specific support. Verify all addresses, amounts, and fee estimates before signing.