Bitcoin Fees, the Mempool, RBF & CPFP

How a Bitcoin Fee Works

A Bitcoin transaction has no fee field. The fee is whatever is left over: the Bitcoin whitepaper says that if a transaction's output value is less than its input value, the difference is a transaction fee added to the incentive of the block that contains it. Block space is limited and measured in virtual bytes (vB), a unit defined in BIP-141 that counts witness data, where SegWit signatures sit, at a discount, so the fee per vB (sat/vB, where a satoshi is one hundred-millionth of a bitcoin) matters, not the amount sent. For example, a 200 vB transaction paying 1 sat/vB pays 200 satoshis, however much it moves.

The Mempool: A Waiting Room

Before a transaction is confirmed in a block, nodes hold it in their mempool, a local waiting list of unconfirmed transactions. There is no single shared mempool: Bitcoin Core's documentation notes that operators set their own policies and nodes may receive transactions in different orders. When a mempool is full, the lowest-paying transactions are evicted and the minimum feerate rises. As of October 2026, BIP-141 caps a block at 4,000,000 weight units, or 1,000,000 vB. On 26 October 2026, the mempool.space API listed 47,127 unconfirmed transactions totalling 22,648,587 vB and recommended 1 sat/vB for every tier; 22,394,984 vB of that queue paid under 1 sat/vB. That is a single dated snapshot, not a typical state.

Stuck Transactions and the Two Fixes

A transaction paying well below the going rate can wait unconfirmed. Two fixes exist. Replace-by-fee (RBF) means broadcasting a new version of the same payment, spending the same coins, with a higher fee; BIP-125 describes how nodes may accept it. Child-pays-for-parent (CPFP) means spending an output of the stuck transaction in a new, high-fee transaction, so a miner who wants the child's fee must include the parent too. Both depend on nodes and miners applying them, so neither is assured. A confirmation means inclusion in a block.

1. Find the transaction on a block explorer and read its feerate in sat/vB.
2. Check whether it already has a confirmation or is still in the mempool.
3. Compare it with the explorer's recommended tiers; a lower rate is the usual reason for a wait.
4. If it is waiting, the sender can try a replacement (RBF) and the recipient a child (CPFP).

Sizing Transactions and Estimating Fees

BIP-141 defines transaction weight as the stripped size times three plus the total size, and virtual size as weight divided by four, rounded up. To choose a rate, a wallet needs an estimate. As of October 2026, the Bitcoin Core 31.0.0 RPC reference says that estimatesmartfee accepts a confirmation target of 1 to 1008 blocks and returns a fee rate per kilobyte for confirming within it. Its default economical mode uses a shorter time horizon and so reacts faster to falling fees, whereas the conservative mode uses a longer history. Bitcoin Core 31.0, published on 19 April 2026, lowered the estimator's minimum fee-rate bucket from 1 sat/vB to 0.1 sat/vB.

Mempool Limits, Minimums and Replacement Rules

Nodes apply policy on top of consensus. A dynamic mempool minimum feerate, set by the transactions evicted when the pool is full, is separate from the static minimum relay feerate. Bitcoin Core 30.0, published on 10 October 2025, changed the default minimum relay and incremental relay feerates to 0.1 sat/vB, and its notes add that transactions created with lower rates are not assured to propagate or confirm unless the lower defaults are widely adopted. The same notes leave the dust feerate unchanged.

BIP-125 specified opt-in replacement: a transaction signals it with an input sequence number below 0xffffffff minus 1, and a replacement must pay at least the absolute fees of the originals plus enough to cover its own bandwidth, with no more than 100 transactions evicted (as written in the BIP, read in October 2026); the current Bitcoin Core policy notes instead limit the number of distinct clusters of conflicting transactions to 100. As read in October 2026, Bitcoin Core's policy notes record that full replace-by-fee became the default in version 28.0 and that signalling is no longer required, and BIP-431 noted when it was written that Core's RBF policy was slightly different from BIP-125. Since Bitcoin Core 31.0 in April 2026, a replacement must also strictly improve the mempool's feerate diagram.

CPFP, Packages and TRUC

Bitcoin Core's package documentation defines a package as an ordered list of related transactions, and a package feerate as the total modified fees divided by the total virtual size. Its example, as read in October 2026, has a mempool minimum of 5 sat/vB and a 1 sat/vB parent that can be accepted if it arrives together with a high-feerate child. As of October 2026, submitted packages must be child-with-parents, with limits of 25 transactions and 404,000 weight units. TRUC transactions, defined in BIP-431 (status Draft as read in October 2026), set transaction version 3 and allow at most one unconfirmed ancestor and one unconfirmed descendant, which limits the pinning tactics described later.

Fees and the Security Budget

The whitepaper notes that once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees. Two consecutive blocks around the halving, compared, show the size of the gap on one day. Block 839,999, mined on 20 April 2024 (UTC), paid 104,455,386 satoshis in fees beside a subsidy of 625,000,000 and had a median feerate of 90 sat/vB, according to mempool.space data read in October 2026. Block 840,000, mined minutes later on 20 April 2024, paid 3,762,561,499 satoshis in fees beside a subsidy of 312,500,000, with a median of 200 sat/vB. The subsidy figures are the block reward minus fees, so that block's fees were about twelve times its subsidy.

Pinning and the Fee-Bumping Toolkit

BIP-431 explains how replacement rules can be turned against a user. Because a replacement must pay more absolute fee than everything it replaces, a counterparty can attach low-feerate descendants to raise the cost, or attach enough descendants to reach the limit of 100 transactions (BIP-431, read in October 2026). BIP-431 adds that cluster mempool does not resolve either form. This matters for contracts such as Lightning channels, where time-sensitive transactions must confirm. Those commitment transactions have relied on the CPFP carve-out, which Bitcoin Core 31.0 removed in April 2026, pointing instead to TRUC transactions with sibling eviction. Bitcoin Core 28.0, published on 2 October 2024, added the Pay To Anchor output type and opportunistic relay of 1-parent-1-child packages.

Policy at the Data Edge

Defaults also decide what data can travel in a transaction. Bitcoin Core 30.0, published on 10 October 2025, raised the default -datacarriersize to 100,000, which its notes call effectively uncapped, and permitted multiple OP_RETURN outputs per transaction. The notes name 83 as the limit enforced in earlier versions, and an operator can restore it with -datacarriersize=83. Since this is a relay default and not a consensus rule, network behaviour depends on how many nodes keep which setting.

Cluster Mempool and What Remains Open

Bitcoin Core 31.0, published on 19 April 2026, replaced ancestor and descendant limits with cluster limits of 64 transactions and 101 kB, orders transactions by the feerate of their chunk for block templates, eviction and relay, and extended 1-parent-1-child relay to non-TRUC parents even at zero fee. Release notes record what software does by default, not how many nodes or miners run it, so network-wide adoption of each rule is a separate question that the notes themselves flag for the lower relay-fee defaults.