A Bitcoin payment can remain unconfirmed when its fee is too low for current demand. Replace-by-Fee, usually shortened to RBF, lets a spender issue a conflicting version of that pending transaction with a stronger fee. It is not a recall button. It works only before confirmation, and the replacement must spend at least one of the same inputs.
Start with control, not the explorer label
The first question is whether you control the keys for the original inputs. If your wallet built the transaction and offers a fee-bump command, RBF is often the simplest option. A recipient normally cannot replace the sender’s transaction because the recipient does not control those inputs. An exchange withdrawal is also outside the customer’s direct control, so the practical choices are to contact the sender or wait.
Do not rely on a single wallet badge that labels a transaction replaceable or non-replaceable. Bitcoin Core’s current policy no longer makes the old opt-in signal the sole test. Wallet support still matters, however: a node may accept a valid replacement even when an app has no interface for creating one.
What a valid replacement must accomplish
A replacement needs more than a token fee increase. Bitcoin Core’s policy requires it to pay at least the total fee of the transactions it replaces and enough extra to cover relay bandwidth at the node’s incremental relay rate. Under Bitcoin Core 31.0, replacement validation also uses the cluster mempool’s fee-rate diagram. For a transaction that sits alone in its cluster, the release notes say the replacement needs both a higher absolute fee and a higher fee rate.
These are relay-policy conditions, not a promise of quick confirmation. A wallet should use a current fee estimate and show the revised recipient amount, change and total fee before signing. Check those fields carefully, especially with a hardware wallet. A proper replacement conflicts with the first transaction; sending an unrelated second payment can allow both to confirm.
When CPFP is the better tool
Child Pays for Parent, or CPFP, solves a different control problem. If you can spend an output from the unconfirmed transaction, you can create a child with a high enough fee that the parent-and-child package becomes attractive to miners. This can help a recipient who cannot replace the parent, or a sender who controls an unconfirmed change output. The child fee has to compensate for the whole package, so its own fee rate may need to be much higher than the target package rate.
A cautious recovery sequence
- Confirm that the payment is still unconfirmed. Compare your own node or wallet with more than one reputable explorer if the status is unclear.
- Record the transaction ID, outputs, total fee and approximate virtual size. Verify who controls the original inputs and any spendable outputs.
- Use the wallet’s native RBF or CPFP workflow. Review every output before signing; never share a seed phrase with a fee-acceleration service.
- Broadcast once, then check whether peers or explorers recognize the replacement or package. Different mempools can update at different times.
- Stop after either version confirms. RBF cannot alter a confirmed transaction, and creating another payment risks paying twice.
The practical distinction is simple: RBF is generally a sender-side replacement, while CPFP uses control of an unconfirmed output. Neither method removes the need to verify the transaction state and inspect the new fee before signing.
Adapted from Bitcoin RBF Explained: How to Speed Up a Stuck Transaction.