RBF vs CPFP: Bitcoin Fee Bumping Methods Compared

Overview

When a Bitcoin transaction gets stuck in the mempool because its fee is too low, there are two standard methods to accelerate confirmation: Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP). Both achieve the same goal of getting a transaction mined faster, but they work in fundamentally different ways and are available to different parties in a transaction.

RBF replaces the original transaction with a new version that pays a higher fee. CPFP creates a new child transaction that spends an output from the stuck parent, paying a fee high enough to incentivize miners to confirm both. The right choice depends on whether you are the sender or receiver, which wallet you use, and how much you are willing to pay in overhead fees.

How Replace-By-Fee Works

RBF allows a transaction's sender to broadcast a replacement version with a higher fee. The replacement transaction spends the same inputs but with updated fee parameters. Nodes that support RBF policy evict the original from their mempool and relay the replacement instead.

Opt-in RBF was defined in BIP125 and implemented in Bitcoin Core 0.12.0 (February 2016). Under BIP125, a transaction signals replaceability by setting any input's nSequence value to less than 0xfffffffe. To successfully replace a transaction, five rules must be satisfied:

1. The original transaction must signal replaceability (or descend from one that does)
2. The replacement may only include unconfirmed inputs that were present in the originals
3. The replacement must pay an absolute fee at least equal to the sum of fees of all transactions being replaced
4. The replacement must pay for its own bandwidth at the minimum relay feerate (at least 1 sat/vB for its own size)
5. The number of original transactions plus their in-mempool descendants must not exceed 100

Full RBF

BIP125 originally required the sender to opt in by setting nSequence values. This changed over three Bitcoin Core releases. Version 24.0 (November 2022) introduced the -mempoolfullrbf option, defaulting to off. Version 28.0 (October 2024) changed the default to on. Version 29.0 (April 2025) removed the option entirely, making full RBF standard, non-configurable behavior.

With full RBF, any unconfirmed transaction can be replaced regardless of nSequence signaling. This has important implications: it effectively eliminates the reliability of zero-confirmation transactions and simplifies wallet implementations since signaling is no longer necessary. You can check whether a specific transaction has been replaced using an RBF detector.

How Child-Pays-For-Parent Works

CPFP takes a different approach. Instead of replacing the stuck transaction, a new child transaction is created that spends one of the parent's outputs. The child pays a fee high enough that the combined "ancestor feerate" of both transactions meets the target for inclusion in the next block.

Since Bitcoin Core 0.13.0 (August 2016), the block template construction algorithm selects transactions based on ancestor feerate rather than individual feerate. The ancestor feerate is calculated by summing the fees of a transaction and all its unconfirmed ancestors, then dividing by the sum of their virtual sizes. For example: if a parent has a fee of 1,000 sats at 250 vB, and a child has a fee of 3,000 sats at 150 vB, the package feerate is (1,000 + 3,000) / (250 + 150) = 10 sat/vB.

Bitcoin Core enforces ancestor and descendant limits to prevent mempool abuse: a maximum of 25 ancestor or descendant transactions (including the transaction itself) and 101 kvB of cumulative virtual size. These limits are being replaced by cluster limits (64 transactions per cluster, 101 kvB per cluster) in the upcoming cluster mempool redesign.

Cost Comparison

RBF is more fee-efficient than CPFP in nearly every scenario. With RBF, you pay the difference between the new fee and the original fee, plus a small relay bandwidth cost. No additional block space is consumed because the replacement evicts the original from mempools.

CPFP requires a new child transaction that adds block space. A minimal P2WPKH child (one input, one output) is roughly 141 vB. The child must pay a fee that covers the feerate deficit of the parent plus its own weight. At 50 sat/vB, the overhead for the child transaction alone is approximately 7,050 sats (~$0.07 at $100k/BTC) before accounting for the parent's fee shortfall.

Use the fee estimator to check current mempool conditions before deciding on a fee-bumping strategy. For guidance on managing fees across multiple UTXOs, see the Bitcoin fee market dynamics research article.

Wallet Support

Wallet support for fee bumping varies. Most modern Bitcoin wallets support RBF, but CPFP support is less consistent since any wallet that allows spending unconfirmed UTXOs with a custom fee technically enables CPFP, even without a dedicated interface.

Privacy Implications

Both fee-bumping methods leak information that chain analysis firms can exploit. Understanding these tradeoffs is important for privacy-conscious users.

RBF exposes the change output. When a sender bumps fees via RBF, the higher fee is typically deducted from the change output. An adversary monitoring the mempool sees both the original and replacement transactions and can identify the output whose value decreased as the change output. This is a well-documented heuristic for de-anonymizing transactions.

CPFP creates an explicit parent-child link on-chain. If the receiver performs CPFP, it reveals that the receiving address in the parent is controlled by the same entity that controls the input in the child. If the sender performs CPFP by spending the change output, it confirms which output was change. For a deeper analysis of transaction privacy, see the Lightning Network privacy analysis.

Full RBF actually helps privacy in one respect: since all transactions are now replaceable by default, RBF signaling (via nSequence values) is no longer a distinguishing trait that chain analysis firms can use for wallet fingerprinting.

Lightning Network and Anchor Outputs

CPFP plays a critical role in anchor outputs, the mechanism that Lightning Network implementations use to ensure commitment transactions can be fee-bumped after broadcast. Each commitment transaction includes two anchor outputs (one per channel party), each worth 330 satoshis. Channel parties use CPFP on their respective anchor to set the final feerate at broadcast time rather than when the commitment transaction was created.

The next generation of Lightning fee bumping uses TRUC (Topologically Restricted Until Confirmation) transactions, introduced in Bitcoin Core 28.0. Combined with Pay-to-Anchor (P2A) outputs and ephemeral dust policy (Bitcoin Core 29.0), the new design replaces two anchors with a single keyless anchor. Commitment transactions pay zero fee, with all fee responsibility shifted to the CPFP child. This eliminates the update_fee message and related channel reserve complications.

Package Relay and Recent Developments

Package relay allows nodes to evaluate groups of related transactions together rather than individually. This directly improves CPFP reliability: without package relay, a low-fee parent might be rejected by nodes before the fee-paying child can be evaluated alongside it.

Bitcoin Core 26.0 (December 2023) added the submitpackage RPC for local package submission with CPFP evaluation, but without P2P relay. Bitcoin Core 28.0 (October 2024) introduced 1-parent-1-child (1p1c) P2P package relay, allowing low-feerate parents to be relayed when paired with a fee-paying child. This version also standardized TRUC transactions, which enforce topology restrictions (a single parent up to 10 kvB, or a child of exactly one TRUC parent capped at 1 kvB) to prevent transaction pinning attacks.

When to Use RBF vs CPFP

The decision framework is straightforward in most cases:

• Use RBF if you are the sender and your wallet supports it: it is cheaper, simpler, and leaves a smaller on-chain footprint
• Use CPFP if you are the receiver waiting for an incoming payment: you cannot replace a transaction you did not create, but you can spend its output with a high-fee child
• Use CPFP if the original transaction was created by a protocol (such as a Lightning commitment transaction) that cannot be re-signed for RBF
• Use RBF to cancel a transaction entirely: create a replacement that sends all funds back to your own address
• Use CPFP when the sender's wallet does not support RBF and you have access to the change output

For fee estimation before bumping, check current mempool conditions. Overpaying wastes sats; underpaying means the bump itself gets stuck. Layer 2 solutions like Spark avoid on-chain fee pressure entirely by settling transactions off-chain, which is particularly valuable during periods of high mempool congestion.

Frequently Asked Questions

What is the difference between RBF and CPFP?

RBF (Replace-By-Fee) replaces a stuck transaction with a new version that pays a higher fee. Only the sender can perform RBF because it requires re-signing the transaction inputs. CPFP (Child-Pays-For-Parent) creates a new child transaction that spends an output from the stuck parent, paying enough fees to incentivize miners to confirm both. Either the sender (via the change output) or the receiver (via the payment output) can perform CPFP.

Can I use RBF if my original transaction did not signal it?

Yes. Since Bitcoin Core 29.0 (April 2025), full RBF is the default and only behavior. The -mempoolfullrbf option has been removed entirely. Any unconfirmed transaction can be replaced regardless of its nSequence signaling. Older nodes running pre-29.0 software may still enforce BIP125 opt-in rules, but the vast majority of miners and nodes now accept full RBF replacements.

Is RBF cheaper than CPFP?

Yes. RBF replaces the original transaction in-place, consuming no additional block space. You only pay the fee difference plus a small relay cost. CPFP requires an entirely new transaction (typically 141+ vB for a simple P2WPKH spend), and the child must pay fees covering both its own weight and the parent's feerate deficit. For a target feerate of 50 sat/vB, the CPFP child adds at least ~7,000 sats in overhead before accounting for the parent's shortfall.

Can a receiver speed up an incoming Bitcoin transaction?

Yes, using CPFP. If you are waiting for a payment and the sender's transaction is stuck, you can create a new transaction that spends the unconfirmed output you received. By setting a high enough fee on the child, miners are incentivized to include both the parent and child in the next block. Wallets like Sparrow, Electrum, and Trezor Suite provide explicit CPFP interfaces for this.

What is transaction pinning and how does it relate to RBF?

Transaction pinning is an attack where a malicious party creates conditions that prevent a counterparty from fee-bumping a transaction. Under BIP125 Rule #3, a replacement must pay an absolute fee at least equal to the sum of all replaced transactions. An attacker can exploit this by attaching a large, low-feerate descendant that inflates the absolute fee threshold. TRUC (v3) transactions, standardized in Bitcoin Core 28.0, mitigate pinning by enforcing strict topology limits on transaction chains. This is particularly important for Lightning Network commitment transactions, where pinning could delay force-close resolution.

Do all Bitcoin wallets support RBF?

Most modern Bitcoin wallets support RBF, including Bitcoin Core, Electrum, Sparrow, BlueWallet, Trezor Suite, Ledger Live, and Nunchuk. Some wallets enable RBF signaling by default (Electrum, Trezor Suite), while others require manual activation. With full RBF now standard across the network, signaling is no longer strictly necessary, but wallet interfaces may still present it as an option.

How does CPFP work with Lightning Network anchor outputs?

Lightning commitment transactions include anchor outputs specifically designed for CPFP fee bumping. Each party has a 330-satoshi anchor they can spend with a high-fee child to set the effective feerate at broadcast time. The next-generation design uses TRUC transactions with a single keyless Pay-to-Anchor output, allowing zero-fee commitment transactions where all fee responsibility falls on the CPFP child. This is covered in detail in our Lightning scalability limits research.

This tool is for informational purposes only and does not constitute financial advice. Technical details reflect Bitcoin Core behavior as of version 29.0 (April 2025). Node software, wallet features, and network policies change over time. Always verify current behavior before relying on fee-bumping strategies for time-sensitive transactions.