Bitcoin fees are market priced. A transaction that was acceptable at broadcast can become underpriced minutes later if the mempool fills and the clearing fee rate rises. Fee bumping is the set of techniques that changes the fee incentives after broadcast so miners have a reason to include the transaction sooner.
Two methods dominate modern wallets:
Replace-by-Fee (RBF) replaces the original unconfirmed transaction with a new version that pays more.
Child-Pays-For-Parent (CPFP) creates a new child transaction that spends an output from the stuck transaction and overpays so the combined package becomes attractive.
Both methods rely on the same miner incentive: miners prefer packages that maximize revenue per vbyte when selecting transactions. CPFP explicitly targets package feerate, which is the effective feerate of a parent plus its child,
RBF is an opt-in policy defined by BIP-125 that allows an unconfirmed transaction to be replaced by a new transaction that spends at least one of the same inputs and pays a higher fee.
Opt-in RBF is signaled through input sequence numbers, allowing the sender to indicate replaceability at creation time. If the original transaction does not signal replaceability, many nodes will not accept a replacement under standard policy.
BIP-125 defines multiple requirements, and the ones that usually matter operationally are:
A replacement typically needs both a higher feerate and a higher total fee, which can become relevant when the replacement transaction is larger than the original.
RBF keeps the transaction graph simple. The network sees one transaction that replaces another. It is usually the most fee efficient method for the sender because only one transaction ultimately gets mined.
RBF is also the best fit when:
The main operational limit is that RBF is a sender-driven method. A recipient cannot generally RBF-bump a transaction they did not create, because they do not control the inputs.
CPFP bumps fees by creating a child transaction that spends an output from the stuck transaction. The child pays a very high feerate so miners include both parent and child together. CPFP is a technique where the child’s feerate incentivizes miners to mine both transactions as a package.
CPFP can be initiated by whoever controls a spendable output from the parent. That is often the recipient, because the parent transaction creates an output paying them. If the recipient can spend that output, they can create the child transaction and use CPFP to pull the parent into a block.
This is one reason CPFP is operationally important even when RBF exists. A sender can forget to enable RBF or use a wallet that does not support it. CPFP gives the receiver a way to unblock funds without relying on the sender.
CPFP is rarely fee efficient in absolute terms. The child must overpay enough to raise the effective feerate of the package, and the miner must be paid for both transactions’ bytes. CPFP can increase the total fee significantly because the package must cover both parent and child.
CPFP is usually chosen because it is available, not because it is cheap.
The right method is usually determined by control and constraints.
If the sender controls the inputs and the transaction signals RBF, RBF is usually the first choice.
If the sender cannot or will not bump, and the recipient can spend an output from the parent, CPFP becomes the practical option.
Some transaction graphs can be effectively pinned, meaning the package cannot be fee-bumped easily because policy rules limit replacements or because the outputs needed for CPFP are not yet spendable in the needed way.
The relevant point for users is that fee bumping depends on transaction topology. Wallets that coordinate multiparty transactions, such as channel opens, escrow-like scripts, or batched payouts, need to design for bumpability.
RBF can be iterative. A wallet can replace multiple times until inclusion.
CPFP is often a one-shot decision: set the child’s feerate high enough to clear quickly because repeating CPFP usually creates larger chains of unconfirmed transactions.
Fee bumping often fails because the transaction was constructed in a way that removes flexibility.
Wallets often label the transaction as replaceable. If replaceability was not signaled, a replacement may not propagate widely under default node policy.
CPFP requires an output from the stuck transaction that the user can spend. If all outputs go to other parties or are time-locked in a way that prevents immediate spend, CPFP is not available.
If the transaction depends on other unconfirmed parents, the effective package feerate must cover the whole ancestor set. Ancestor feerate mining is part of miner package selection logic.
RBF requires the replacement to pay more in total and to satisfy policy about additional fees.
CPFP requires the child fee to raise the combined package feerate enough to compete for block space.
If the original transaction does not opt in, a replacement may be rejected by many nodes. This is why many wallets enable opt-in RBF by default.
A replacement can have a higher feerate but still fail policy if the absolute fee is not sufficiently higher relative to the transactions it replaces. BIP-125 includes an absolute fee rule.
If the child spends an output that later turns out to be needed for another workflow, CPFP can create operational conflicts. In some wallets, spending the change output versus the received output affects how future consolidation or accounting behaves.
If the child’s feerate is not high enough to raise the package above the current clearing level, the package can remain stuck, and the user may have to create a new child with even higher fees, increasing cost and complexity.
RBF and CPFP solve the same problem with different control assumptions. RBF replaces an unconfirmed transaction with a higher-fee version and is usually the sender’s cheapest path when opt-in signaling was enabled under BIP-125. CPFP creates a high-fee child that drags the parent into a block by improving the package’s effective feerate, which makes it particularly useful for recipients who cannot modify the parent.
The reliable decision rule is simple. Use RBF when the sender can replace and the transaction is replaceable. Use CPFP when the sender cannot or will not bump and there is a spendable output that can fund a high-fee child. In both cases, the best outcome depends on constructing transactions that remain bumpable under real mempool policy and real fee volatility.
The post RBF vs CPFP Explained: Choosing the Right Fee-Bump Method appeared first on Crypto Adventure.
