Bitcoin RBF and CPFP: how to raise a stuck fee

An unconfirmed Bitcoin transaction does not become faster because someone sends a second payment or adds an arbitrary fee. The useful question is who controls the relevant inputs or outputs, which mempool policy the receiving nodes enforce, and what feerate miners currently require. Bitcoin RBF and CPFP are the two standard fee-bumping approaches: Replace-by-Fee replaces a transaction, while Child Pays for Parent adds a high-fee child that makes the whole package attractive.

This guide assumes the transaction is valid, still unconfirmed, and delayed because its fee is too low. Start by checking its txid, total fee, virtual size, feerate, inputs and outputs with your wallet, node, or an independent explorer. Our Bitcoin fee guide explains why sat/vB and block space matter, not the amount of bitcoin being transferred.

Bitcoin RBF and CPFP: the essential difference

RBF creates a new transaction that spends at least one of the same inputs as the original and pays a sufficiently higher fee. The two transactions conflict. A node that accepts the replacement removes the original from its mempool and relays the new one. The replacement has a new txid, and its outputs or change may differ. It does not edit the bytes of the old transaction.

CPFP leaves the parent untouched. Someone who controls one of its unconfirmed outputs spends that output in a new, high-fee child. A miner cannot confirm the child without first confirming the parent, so it can assess the combined reward. CPFP is often available to the recipient, or to the sender when the parent created a change output that the sender controls.

Opt-in RBF, full RBF, and the nSequence field

RBF is a mempool and relay policy, not a Bitcoin consensus rule. Under opt-in RBF as documented in BIP125, a transaction explicitly signals replaceability when at least one input has an nSequence value below 0xfffffffe. A value below 0xffffffff also permits nLockTime to take effect; particular sequence values can encode BIP68 relative locktimes. Users should not alter them manually without understanding those interactions.

Opt-in does not make an unflagged transaction immune to double-spending. It tells nodes following that policy to consider a compliant replacement. With full RBF, a node may do so without a signal. Support and relay behavior depend on software, version, and configuration, so peers can hold different mempool views.

The replacement fee rules that matter

A replacement is not accepted merely because its displayed sat/vB is higher. Policies derived from BIP125 impose anti-spam and anti-DoS conditions. In practical terms, the candidate must conflict with a transaction in that node’s mempool; it must pay at least the total absolute fees of the transactions it causes to be evicted; and it must add enough fee to pay for relaying its own bytes at the node’s incremental relay fee. A tiny feerate increase can therefore fail when the replacement is larger or when descendants are evicted.

The classic rules restrict new unconfirmed inputs and cap evictions, commonly at 100 transactions including descendants. Implementations may apply newer variations; Bitcoin Optech’s RBF topic tracks them. Policy is local: one peer’s acceptance does not bind other nodes or miners.

How CPFP package feerate is calculated

CPFP exploits transaction dependency. The child spends an unconfirmed parent output, so a miner must include both in topological order. For a simple parent-child pair, the economic package feerate is (parent fee + child fee) / (parent vsize + child vsize). It is not the arithmetic average of their two feerates.

Assume a 200-vB parent pays 1,000 sat, or 5 sat/vB. You want a 30 sat/vB package and estimate a 110-vB child. The total target fee is 30 × 310 = 9,300 sat. Since the parent already contributes 1,000 sat, the child must pay about 8,300 sat—more than 75 sat/vB. Giving the child 30 sat/vB would not compensate for the parent’s shortfall.

With other unconfirmed ancestors, include everything the miner must confirm. The child must meet relay requirements and chain policy. Historically common Bitcoin Core limits are 25 transactions and 101,000 virtual bytes, but versions and settings differ. Package relay helps some cases; see Bitcoin Optech’s CPFP documentation.

Sender control, recipient control, and change

The sender can use RBF only when the wallet controls the original inputs, recognizes the pending transaction, and can construct a valid replacement. A custodial exchange withdrawal gives the customer no such control; only the exchange can replace its transaction. Importing or watching a txid in another wallet does not import private keys.

The recipient can use CPFP only if the wallet allows the received unconfirmed output to be spent. Some wallets hide unconfirmed coins, lack coin control, or deliberately block this workflow. The sender may instead CPFP a change output, provided the parent created change, the wallet recognizes it as owned, and its value can fund the fee without producing an uneconomic or dust output.

This explains two common dead ends. A recipient cannot RBF somebody else’s payment merely because they own one output. A sender cannot CPFP when there is no change and the recipient’s output is not theirs. Read the Bitcoin UTXO explainer if the distinction among inputs, destination outputs, and change is unclear.

Decision table: RBF, CPFP, or wait

When both methods work, RBF is usually cheaper because it adds no child. CPFP helps when the recipient controls the useful output or replacement is unavailable. Waiting remains rational, although a transaction below minimum relay fee may disappear.

A practical scenario with exact numbers

Alice sends 0.01 BTC to Bob. The transaction is 180 vB, pays 1,800 sat (10 sat/vB), and signals opt-in RBF. Demand then rises and transactions around 35 sat/vB are being selected. Alice needs urgency. Her wallet proposes a 185-vB replacement at 40 sat/vB, for a total fee of 7,400 sat. She verifies Bob’s output, amount, change, and fee before signing. The replacement spends a conflicting input and receives a new txid.

If Alice does nothing, Bob could spend his output with a 120-vB child. Parent plus child occupy 300 vB. A 40 sat/vB package needs 12,000 sat in total; subtracting the parent’s 1,800 sat means the child should pay about 10,200 sat. Bob needs an output large enough to fund that fee and a wallet that can spend unconfirmed funds.

The arithmetic changes if the parent has additional low-fee ancestors. It also changes if Alice already spent her change: those descendants may be evicted by RBF and raise the fee threshold. Both users should check propagation across independent sources. Seeing a transaction only in the wallet provider’s explorer proves that provider knows it, not that miners broadly accept it.

A safe wallet workflow for fee bumping

1. Confirm the transaction is still unconfirmed and identify the correct txid. Neither method changes a confirmed transaction.
2. Inspect total fee, vsize, feerate, inputs, outputs, and any ancestors or descendants. Do not confuse payment amount with miner fee.
3. Choose a target feerate matching the urgency, preferably from your node and more than one estimator. A next-block target is intentionally expensive.
4. For RBF, use the wallet’s native “bump fee” feature or a supported RPC such as Bitcoin Core bumpfee. Do not create a separate duplicate payment.
5. On the signing device verify destination, amount, change, absolute fee, and feerate. A replacement often funds the increase by reducing change.
6. For CPFP, select the parent output explicitly with coin control. Compute the package fee and leave a sensible, non-dust final output.
7. After broadcast, verify the replacement or parent-child pair through independent peers or explorers. Save both txids for accounting and support.

A hardware wallet may display only the new transaction, not the relationship to the old one. Compare every output instead of trusting the “fee bump” label. The safe crypto sending checklist provides a separate address and network review.

Constraints and risks hidden by wallet interfaces

The first risk is economic: an aggressive estimator may cause a large overpayment. The second is operational: changing outputs or txid can break accounting systems, payment requests, and services that monitor only the original identifier. Recipients must treat zero-conf expectations as provisional until the required confirmations arrive.

Competing replacements can propagate to different parts of the network. The original may still confirm first if it reaches a miner that never received or accepted the replacement. CPFP can fail because a miner does not evaluate the expected package, an ancestor is missing, chain limits are exceeded, or the child itself does not relay.

Pinning and griefing matter in multi-party protocols: a counterparty may create structures that make replacement expensive or policy-incompatible. New relay policies reduce some attacks but guarantee nothing. High-value transactions deserve an advanced wallet and, ideally, your own node.

Common mistakes to avoid

• Sending the payment again: two independent transactions can both confirm. A real RBF transaction conflicts on inputs.
• Looking only at the child’s sat/vB: CPFP depends on the aggregate feerate of all required ancestors.
• Treating non-RBF as final: full RBF and other double-spend paths exist before confirmation.
• Adding the smallest possible fee: absolute-fee, incremental-relay, conflict, and eviction rules all matter.
• Spending change unknowingly: pending descendants can complicate replacement and may disappear from mempools.
• Giving an accelerator a seed phrase: no legitimate rebroadcast or mining service needs private keys.
• Confusing rebroadcast with bumping: relaying identical bytes does not change fee or economic priority.

Final checklist and conclusion

• Is the transaction definitely unconfirmed?
• Do you control the inputs for RBF or an output for CPFP?
• Does it signal opt-in RBF, and have you considered full-RBF policy?
• Did you calculate absolute fee, vsize, and feerate?
• For CPFP, did you include every ancestor the miner needs?
• Does the replacement clear incremental fee and mempool limits?
• Did you verify destination, amount, change, and the new txid?
• Does the urgency justify the cost, or is waiting better?

Bitcoin RBF and CPFP solve the same delay from opposite sides. RBF is usually the sender’s tool and replaces the pending transaction. CPFP belongs to whoever controls a spendable output and pays for the package. The right decision follows from key control, UTXO structure, node policy, and complete fee arithmetic. If one of those facts is unknown, diagnosis and patience are safer than signing blindly.

Official technical sources

• BIP125 — Opt-in Full Replace-by-Fee Signaling
• Bitcoin Core — bumpfee RPC
• Bitcoin Optech — Replace-by-Fee
• Bitcoin Optech — Child Pays for Parent