Fee Bumping

What Is Fee Bumping?

Fee bumping is the practice of increasing the effective fee on an unconfirmed Bitcoin transaction so that miners prioritize it for inclusion in a block. When the mempool is congested and a transaction's fee rate falls below what miners are willing to confirm, the transaction can remain stuck for hours or even days. Fee bumping provides a way to resolve this without waiting.

The concept matters because Bitcoin's fee market is dynamic: a fee rate that was sufficient at broadcast time can become inadequate minutes later if demand for block space surges. Rather than forcing users to predict future congestion perfectly, fee bumping allows them to adjust after the fact. This is especially critical for time-sensitive payments and protocol-level transactions like Lightning Network channel closures.

How It Works

There are two fundamentally different approaches to fee bumping, each suited to different situations. Both achieve the same goal (higher effective fee rate) but through different mechanisms.

Replace-by-Fee (RBF)

RBF allows the sender to replace an unconfirmed transaction in the mempool with a new version that pays a higher fee. The replacement spends the same inputs but includes a higher fee, and optionally different outputs.

Originally defined by BIP 125, opt-in RBF required transactions to signal replaceability by setting an input's nSequence number below 0xFFFFFFFE. Nodes would only accept a replacement if the original explicitly signaled this willingness.

BIP 125 defines five rules a replacement must satisfy: the original must signal replaceability, the replacement cannot introduce new unconfirmed inputs, it must pay a higher absolute fee than all transactions it replaces, it must pay for its own bandwidth at the node's minimum relay fee rate, and the total number of evicted transactions cannot exceed 100.

With full-RBF, these signaling requirements have been removed. Bitcoin Core 24.0 (November 2022) introduced a -mempoolfullrbf option that was off by default. Bitcoin Core 28.0 (October 2024) turned it on by default. Bitcoin Core 29.0 (April 2025) removed the option entirely, making full-RBF mandatory: every unconfirmed transaction is now replaceable regardless of nSequence signaling.

Child-Pays-for-Parent (CPFP)

CPFP takes a different approach. Instead of replacing the stuck transaction, a new "child" transaction spends one of its outputs with a fee high enough to incentivize miners to confirm both transactions together.

This works because Bitcoin Core's block template algorithm evaluates transactions by ancestor fee rate: the combined fees of a transaction and all its unconfirmed ancestors, divided by their combined size in virtual bytes.

ancestor_feerate = (fee_child + fee_parent) / (size_child + size_parent)

A high-fee child "pulls" its low-fee parent into the block. The child must pay enough fee to cover the deficit of the parent plus its own relay cost.

Unlike RBF, CPFP can be performed by the recipient of a stuck transaction, not just the sender. Any party who holds a spendable output from the unconfirmed transaction can create a CPFP child: the sender can spend their change output, or the recipient can spend the output they received.

RBF vs. CPFP

The two methods have distinct tradeoffs that determine when each is appropriate:

In general, RBF is preferred when the sender wants to adjust their own transaction because it is more block-space efficient. CPFP is essential when the recipient needs to accelerate confirmation or when the original transaction was created by another party.

Fee Bumping in Practice

Bitcoin Core provides the bumpfee RPC command (available since v0.14.0) for programmatic RBF fee bumping. It automatically creates a replacement transaction with a higher fee:

# Bump fee on an unconfirmed transaction
bitcoin-cli bumpfee <txid>

# Specify a target fee rate (sat/vB)
bitcoin-cli bumpfee <txid> '{"fee_rate": 25}'

For CPFP, users create a new transaction spending an output from the stuck transaction. Proper fee estimation is critical: the child's fee must compensate for the parent's shortfall relative to the current mempool minimum.

Most modern wallets provide fee bumping through their user interfaces. Bitcoin Core's GUI offers an "Increase transaction fee" option on unconfirmed transactions. Electrum, Sparrow, and BlueWallet all support RBF bumping and, in some cases, CPFP as well.

Package Relay

A longstanding limitation of CPFP has been relay failure: if a parent transaction's fee rate falls below a node's minimum relay fee, the node rejects the parent outright. Without the parent in its mempool, the node cannot validate the fee-bumping child, creating a catch-22.

Package relay (defined in BIP 331) solves this by allowing nodes to relay, validate, and accept groups of related transactions together. Bitcoin Core 28.0 introduced limited package relay support for one-parent-one-child (1p1c) packages, where a low-fee parent can be accepted into the mempool if accompanied by a fee-bumping child. Subsequent releases have hardened this mechanism against denial-of-service attacks.

For a deeper look at how package relay interacts with Lightning Network fee bumping, see the research article on v3 transactions and package relay.

Fee Bumping in Lightning

Fee bumping is particularly critical for the Lightning Network. Commitment transactions are pre-signed when a channel is opened but may not be broadcast until weeks or months later. The fee rate locked in at signing time can be completely inadequate by the time a force close occurs.

Anchor Outputs

Anchor outputs solve this problem at the protocol level. Each commitment transaction includes two small outputs (330 satoshis each), one for each channel party. All other outputs are encumbered with a one-block relative timelock, making only the anchor outputs immediately spendable after broadcast.

Either party can spend their anchor output in a child transaction with a high fee, using CPFP to bump the entire commitment transaction. This design, combined with the CPFP carve-out mempool policy, prevents transaction pinning attacks where an adversary could block legitimate fee bumping.

Ephemeral Anchors

The next generation of Lightning fee bumping uses ephemeral anchors with Pay-to-Anchor (P2A) outputs, defined in BIP 433. These are "keyless" outputs using the script OP_1 <0x4e73> that anyone can spend, eliminating the need for per-party anchor outputs. Combined with v3 transaction relay rules and the ephemeral dust policy introduced in Bitcoin Core 29.0, ephemeral anchors allow zero-fee commitment transactions where the entire fee is determined at broadcast time via CPFP.

For protocols like Spark that operate as a Bitcoin Layer 2, these improvements to on-chain fee bumping strengthen the safety guarantees of unilateral exits and other on-chain settlement paths.

Use Cases

• Unsticking delayed payments: when a payment to an exchange or merchant is stuck during a fee spike, RBF lets the sender increase the fee without creating a new transaction from scratch
• Recipient acceleration: merchants and exchanges use CPFP to accelerate incoming customer deposits without relying on the sender to take action
• Lightning force closes: anchor outputs ensure that commitment transactions can always confirm before HTLC timelocks expire, even when on-chain fees are unpredictable
• Transaction batching adjustments: services that batch withdrawals can use RBF to add more outputs or adjust fees on pending batch transactions
• UTXO consolidation during fee dips: users can broadcast low-fee consolidation transactions and bump them only if fees stay low, canceling via RBF if fees rise

Risks and Considerations

Double-Spend Perception

RBF fee bumping replaces one valid transaction with another, which means the original transaction's outputs may change. This has implications for merchants who accept unconfirmed transactions: with full-RBF now mandatory in Bitcoin Core 29.0, any unconfirmed transaction can be replaced. Services that previously relied on "zero-conf" acceptance must now wait for at least one block confirmation or use Layer 2 solutions for instant settlement.

Fee Overpayment

During rapid fee spikes, users may overshoot when bumping fees, paying significantly more than necessary. This is especially common with CPFP, where calculating the correct child fee requires accounting for the parent's size and fee deficit. Wallet software with good fee estimation algorithms mitigates this risk, but manual fee bumping remains error-prone.

CPFP Space Inefficiency

CPFP inherently consumes more block space than RBF because it adds a child transaction rather than replacing the original. In a congested mempool where block space is at a premium, this inefficiency means CPFP fee bumps cost more than equivalent RBF replacements. The overhead is typically 100 to 200 virtual bytes for the child transaction.

Transaction Pinning

In multi-party protocols, an adversary can exploit fee bumping rules to prevent legitimate fee bumps. By attaching a low-fee-rate, large child transaction to a shared transaction, they can make RBF replacement prohibitively expensive (since the replacement must pay a higher absolute fee than all evicted transactions). This transaction pinning attack motivated the development of anchor outputs, v3 transactions, and ephemeral anchors in the Lightning Network.

For more on how the Bitcoin fee market and mempool congestion interact with fee bumping strategies, see the research on Bitcoin fee market dynamics and the practical guide to RBF and CPFP.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.