RBF and CPFP: The Complete Guide to Bumping Stuck Bitcoin Transactions

You broadcast a Bitcoin transaction, and it sits in the mempool for hours. Maybe days. The fee you attached was too low for the current demand on block space, and miners are picking higher-paying transactions first. This is when you need fee bumping: the ability to increase a transaction's priority after it has already been broadcast.

Bitcoin offers two mechanisms for this: Replace-by-Fee (RBF), where you replace the original transaction entirely, and Child Pays for Parent (CPFP), where you create a new transaction that incentivizes miners to confirm both. Each technique works differently, applies in different situations, and carries different risks. This guide covers both in depth.

Why Transactions Get Stuck

Every Bitcoin transaction competes for inclusion in the next block. Miners prioritize transactions by fee rate: the fee paid per unit of transaction weight, measured in satoshis per virtual byte (sat/vB). When network demand spikes, the minimum fee rate required for timely confirmation rises. A transaction broadcast at 5 sat/vB during a quiet period may sit unconfirmed for days if the fee market shifts and miners are filling blocks with transactions paying 50 sat/vB or more.

An unconfirmed transaction is not lost. It remains in the mempool of nodes that have received it, waiting for a miner to include it in a block. But mempools have size limits (300 MB by default in Bitcoin Core), and during extreme congestion, the lowest-fee transactions get evicted entirely. If your transaction is evicted from all mempools, you would need to rebroadcast it, ideally with a higher fee.

Replace-by-Fee: Replacing the Original Transaction

RBF lets a sender create a new version of an unconfirmed transaction with a higher fee. The replacement transaction spends the same inputs as the original, effectively invalidating it. Nodes that accept the replacement drop the original from their mempools, and miners see only the higher-fee version.

How RBF Signaling Works

Historically, a transaction had to explicitly signal that it was replaceable. Under BIP 125, introduced in Bitcoin Core 0.12.0 (February 2016), a transaction opts into replaceability by setting any input's nSequence value to less than 0xFFFFFFFE. Most wallets that support RBF set nSequence to 0xFFFFFFFD (MAX-2) by default, which signals replaceability while still allowing locktime enforcement.

This opt-in mechanism is now vestigial. Bitcoin Core 28.0 (October 2024) changed the default value of the mempoolfullrbf configuration option from 0 to 1, enabling full RBF by default. Bitcoin Core 29.0 (April 2025) went further by removing the mempoolfullrbf option entirely, making full RBF the unconditional standard behavior. Every unconfirmed transaction is now treated as replaceable regardless of its nSequence value.

Full RBF and zero-conf: Full RBF means that merchants accepting unconfirmed (zero-conf) Bitcoin payments can no longer rely on the absence of an RBF signal as an indicator that a transaction won't be replaced. Any unconfirmed transaction can now be replaced with a higher-fee version, making zero-conf acceptance riskier for on-chain payments.

The Five Rules of Transaction Replacement

A replacement transaction must satisfy all five rules defined in BIP 125. While the signaling requirement (Rule 1) is now moot under full RBF, Rules 2 through 5 still govern replacement policy:

1. The original transaction signals replaceability (under full RBF, this rule is effectively satisfied for all transactions)
2. The replacement may only include unconfirmed inputs if those inputs were present in the original transaction being replaced
3. The replacement must pay an absolute fee equal to or greater than the sum of fees paid by all transactions it replaces (including their descendants)
4. The replacement must pay for its own bandwidth at or above the node's minimum relay fee rate (the incremental relay fee, currently 1 sat/vB by default)
5. The total number of original transactions being replaced, plus their descendants that will be evicted, must not exceed 100

Rules 3 and 4 are the ones that matter most in practice. Rule 3 means the replacement must pay more in total than everything it displaces. Rule 4 means it must also cover the cost of relaying the new transaction across the network. Together, they prevent attackers from spamming the network with unlimited free replacements.

Step-by-Step: Bumping a Transaction with RBF

1. Identify the stuck transaction in your wallet and note the inputs it spends
2. Create a new transaction spending the same inputs with a higher fee rate (most wallets automate this with a "bump fee" button)
3. Ensure the new fee exceeds the total fee of the original plus any descendants, and covers the incremental relay fee for the replacement's size
4. Sign and broadcast the replacement transaction
5. The original is dropped from mempools and only the replacement can confirm

Child Pays for Parent: Incentivizing Confirmation from the Output Side

CPFP takes a different approach. Instead of replacing the stuck transaction, you create a new "child" transaction that spends one of its unconfirmed outputs. The child carries a high enough fee that miners are incentivized to confirm both transactions together, because the combined fee rate of the parent-child package makes it profitable to include the pair.

How Ancestor Fee Rate Mining Works

Since Bitcoin Core 0.13.0 (August 2016), the mining transaction selection algorithm evaluates transactions by their ancestor fee rate: the total fees divided by the total virtual size of a transaction and all of its unconfirmed ancestors. When a miner considers including a child transaction, it calculates the aggregate fee rate across the entire ancestry chain. If that combined rate is competitive, the miner includes the parent(s) and the child together.

For example: a parent transaction of 200 vB paying 1,000 sats (5 sat/vB) is stuck. You create a child of 150 vB paying 9,000 sats. The ancestor fee rate is (1,000 + 9,000) / (200 + 150) = 28.6 sat/vB. If the current block inclusion threshold is 20 sat/vB, a miner will include both transactions to capture the combined 10,000 sats.

Step-by-Step: Bumping a Transaction with CPFP

1. Identify an unconfirmed output from the stuck transaction that you control (typically the change output if you are the sender, or the payment output if you are the receiver)
2. Create a new transaction spending that output with a fee high enough that the combined ancestor fee rate meets or exceeds the current confirmation target
3. Calculate the required child fee: (target rate x total package vbytes) minus the parent's existing fee
4. Sign and broadcast the child transaction
5. Miners evaluate the package together and include both when it is profitable

Who can use CPFP: Unlike RBF, which requires access to the original transaction's inputs (making it sender-only), CPFP can be performed by anyone who controls an output of the stuck transaction. This makes it the go-to tool for receivers who need to accelerate an incoming payment they did not originate.

When to Use RBF vs. CPFP

The choice between RBF and CPFP depends on your role in the transaction and the specific constraints you face.

A Simple Decision Tree

Start by asking: did I create the stuck transaction?

• If yes, and you still have access to the wallet that signed it: use RBF. It is more fee-efficient because you are not paying for additional transaction weight.
• If no, or if the transaction was pre-signed (like a Lightning commitment): use CPFP on an output you control.
• If you cannot spend any output of the stuck transaction: you cannot fee-bump it. You must wait for confirmation or mempool eviction.

RBF and CPFP Compared

Anchor Outputs and CPFP in Layer 2 Protocols

CPFP plays a critical role in Layer 2 protocols like the Lightning Network. When a Lightning channel is force-closed, the commitment transaction is broadcast on-chain. But this transaction was pre-signed at an earlier time, with a fee rate that may no longer be sufficient. RBF is not an option because neither party can unilaterally re-sign the commitment transaction.

Anchor outputs solve this by adding two small outputs (330 satoshis each, one per channel participant) to the commitment transaction. These outputs exist solely as attachment points for CPFP: either party can spend their anchor output with a high-fee child transaction to bump the entire commitment transaction into confirmation. Other outputs in the commitment are encumbered by a 1-block relative timelock (OP_CHECKSEQUENCEVERIFY), preventing them from being spent until the commitment confirms and blocking pinning attacks through those outputs.

Pay-to-Anchor (P2A) and TRUC Transactions

Bitcoin Core 28.0 and 29.0 introduced a stack of policy improvements that make CPFP more reliable for Layer 2 fee bumping:

• TRUC (Topologically Restricted Until Confirmation) transactions, defined in BIP 431, restrict a transaction to either a standalone of up to 10 kvB or a child of exactly one TRUC parent capped at 1 kvB. This limits the attack surface for transaction pinning. Standardized in Bitcoin Core 28.0.
• One-parent-one-child (1P1C) package relay allows a parent transaction to enter the mempool even if its fee rate is below the dynamic minimum, as long as a child transaction provides sufficient CPFP. Introduced in Bitcoin Core 28.0.
• Pay-to-Anchor (P2A), defined in BIP 433, is a keyless anchor output type (script: OP_1 0x4e73) that requires no witness data to spend, reducing the cost of CPFP fee bumping. Standard spending in Bitcoin Core 28.0.
• Ephemeral dust (Bitcoin Core 29.0) allows a single dust-value output in a zero-fee transaction, provided the dust is spent in the same package. This enables truly zero-value anchor outputs for protocols like Lightning.

Together, the TRUC + 1P1C + P2A + ephemeral dust stack represents a cohesive system for reliable L2 fee bumping. The Lightning specification has already adopted this stack: BOLTs PR #1228 specifies zero-fee commitment transactions using a single P2A anchor output, replacing the older two-anchor design and eliminating the problematic update_fee message entirely.

Transaction Pinning: When Fee Bumping Fails

Transaction pinning is an attack where a malicious party deliberately makes it expensive or impossible to fee-bump a shared transaction. This is particularly dangerous in multi-party protocols like Lightning, where both channel participants can create descendants of the commitment transaction.

RBF Pinning

BIP 125 Rule 3 requires a replacement to pay a higher absolute fee than the original plus all its descendants. An attacker can exploit this by attaching a large, low-fee-rate child transaction to the original. The child might be 100 kvB paying only 1 sat/vB (100,000 sats total). Now any replacement must pay at least 100,000 sats more than the original, regardless of what fee rate the replacement achieves. The attacker has made fee bumping prohibitively expensive.

CPFP Pinning

Bitcoin Core historically limited each transaction to 25 descendants in the mempool. If an attacker attaches 24 low-fee descendants to a shared transaction, the other party cannot add a high-fee child because the descendant limit is exhausted. The CPFP carve-out rule (introduced in Bitcoin Core 0.19, November 2019) partially addressed this by allowing one additional child beyond the limit, but it only worked for two-party protocols.

TRUC transactions resolve both pinning vectors by strictly limiting the topology: at most one unconfirmed parent and one child, with the child capped at 1 kvB. This makes pinning attacks infeasible because there is no room to attach large or numerous descendants.

Cluster mempool and replacement: Bitcoin Core 31.0 (April 2026) shipped cluster mempool, which replaces the old ancestor/descendant limits with cluster-based evaluation. Replacement transactions are now validated using feerate diagrams: a replacement is accepted only if the resulting mempool's feerate diagram is strictly better than before, eliminating all known cases where replacements could make the mempool worse off.

Common Pitfalls and Mistakes

Accidentally Double-Spending Change

If you have already spent the change output from the original transaction in a subsequent transaction, creating an RBF replacement will invalidate that subsequent transaction too. Any chain of unconfirmed transactions built on the original's outputs collapses when the original is replaced. Bitcoin Core's bumpfee command explicitly blocks this: it refuses to operate if any output has been spent by a descendant in the wallet or mempool. Before using RBF, check whether any of the original's outputs have been spent in other pending transactions.

Fee Estimation Errors

The most common reason transactions get stuck in the first place is poor fee estimation. During mempool congestion spikes, fee rates can change dramatically within minutes. A fee rate that was adequate when you created the transaction may be far below the threshold by the time it propagates across the network.

When bumping fees, the same estimation challenge applies: you need to set a fee rate that will be competitive when a miner next builds a block template, not just when you broadcast. Conservative fee bumping (adding a small increment) can result in needing to bump again. Some wallets allow multiple successive RBF bumps, but each one must pay the incremental relay fee on top of the previous total.

Transactions That Cannot Be Bumped

Certain situations make fee bumping impossible or impractical:

• The transaction has already confirmed (even with one confirmation, it is permanent)
• You do not control any inputs (cannot RBF) or any outputs (cannot CPFP) of the stuck transaction
• The transaction has been evicted from all mempools (you would need to rebroadcast, possibly with modifications)
• Descendant or ancestor limits have been reached, preventing CPFP
• The change output is below the dust threshold (around 546 sats for P2PKH, 294 sats for P2WSH), making it unspendable for CPFP
• In multisig setups, RBF requires re-signing with all required keys, which may not be immediately available

Bumping and Privacy

RBF replacements can leak privacy. If a replacement changes the output amounts or adds/removes outputs, blockchain observers can link the original and replacement transactions and infer the change output. CPFP is slightly better for privacy because the original transaction remains unmodified, but the child still reveals which output the bumper controls.

Wallet Support for Fee Bumping

Most modern Bitcoin wallets support both RBF and CPFP, though the interface varies significantly:

If your wallet does not support fee bumping natively, you can still construct a replacement or child transaction manually using tools like PSBTs or raw transaction RPCs, though this requires careful handling of inputs, outputs, and fees.

Recent and Upcoming Improvements

Cluster Mempool

The cluster mempool project, developed by Suhas Daftuar and Pieter Wuille, fundamentally restructures how Bitcoin Core organizes pending transactions. Instead of tracking individual ancestor and descendant relationships, the cluster mempool groups related unconfirmed transactions into "clusters" subdivided into "chunks" sorted by fee rate. Mining selects the highest-fee-rate chunks first, eviction removes the lowest, and the symmetry eliminates edge cases where the old system produced suboptimal results. The implementation was merged in November 2025 and shipped in Bitcoin Core 31.0 (April 2026).

Package Relay Beyond 1P1C

The 1P1C package relay in Bitcoin Core 28.0 handles the most common CPFP case, but more complex package topologies (e.g., a transaction with multiple unconfirmed ancestors) still face relay challenges. BIP 331 (Ancestor Package Relay), authored by Gloria Zhao, proposes a more general peer-to-peer protocol for requesting and relaying unconfirmed ancestor packages in batches. Full implementation would make CPFP reliable for arbitrary transaction topologies, not just simple parent-child pairs. BIP 331 remains in draft status as of June 2026.

Fee Bumping and Bitcoin Layer 2s

Fee bumping is inherently an L1 concern. Every technique discussed in this article applies to transactions competing for space in Bitcoin blocks. For users of Layer 2 protocols, the relevance of fee bumping depends on how often they interact with the base layer.

On the Lightning Network, fee bumping matters during channel opens, cooperative closes, and especially force-closes. Commitment transactions use anchor outputs precisely because the fee rate at signing time may not match the fee market at broadcast time. Lightning node operators need to understand CPFP and maintain a reserve of confirmed UTXOs for emergency fee bumps.

Spark takes a different approach. Because Spark transfers happen off-chain via statechain-style key rotations, users do not broadcast transactions during normal operation. There is no mempool contention, no fee estimation, and no waiting for confirmations. Transfers settle instantly with deterministic cost. Users only encounter L1 fees when depositing Bitcoin into Spark or withdrawing back to the base layer, and even these interactions can be batched to reduce cost.

For those exploring Spark-based wallets, General Bread provides an example of how a Spark-powered wallet abstracts away L1 fee management entirely. And for developers building on Bitcoin, the Spark SDK documentation covers how to integrate deposits and withdrawals with appropriate fee handling.

For a deeper look at how transactions move through the Bitcoin network before reaching a miner, see our guide on the Bitcoin transaction lifecycle. And for more on how the fee market shapes the economics of block space, see Bitcoin fee market dynamics.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.