Ancestor Feerate

What Is Ancestor Feerate?

Ancestor feerate is a metric used by Bitcoin Core to evaluate how profitable it is for a miner to include a transaction in a block, taking into account all of that transaction's unconfirmed parent transactions. Because Bitcoin enforces transaction ordering (a child transaction cannot appear in a block without its parent), miners cannot simply pick the highest-fee transactions individually. They must consider entire chains of dependent transactions together.

Rather than evaluating each transaction in isolation by its individual fee rate, ancestor feerate computes the effective fee rate of the full package: the transaction itself plus every unconfirmed transaction it depends on. This gives miners an accurate picture of the revenue per virtual byte they would earn by including the entire ancestor set.

The concept was introduced in Bitcoin Core via PR #7600, merged in June 2016. Before this change, Bitcoin Core's block assembly only considered individual transaction fee rates, which meant low-fee parents could block high-fee children from being mined efficiently.

How It Works

When a new transaction enters the mempool, Bitcoin Core identifies all of its unconfirmed ancestors: the parent transaction whose output it spends, that parent's parent, and so on up the chain. The node then calculates and caches three aggregate values for the transaction:

• Cumulative virtual size of the transaction and all unconfirmed ancestors
• Cumulative modified fees of the transaction and all unconfirmed ancestors
• Cumulative signature operation count across the ancestor set

The Calculation

The formula for ancestor feerate is straightforward:

Ancestor Feerate = (Fee_tx + Fee_parent + Fee_grandparent + ...)
                        / (VSize_tx + VSize_parent + VSize_grandparent + ...)

For example, consider a parent transaction of 200 vbytes paying 400 sats (2 sat/vB), and a child transaction of 150 vbytes paying 2,100 sats (14 sat/vB). The child's ancestor feerate would be:

Ancestor Feerate = (2,100 + 400) / (150 + 200)
                       = 2,500 / 350
                       ≈ 7.14 sat/vB

Bitcoin Core uses "modified fees" rather than base fees in this calculation. Modified fees account for any manual priority adjustments applied via the prioritisetransaction RPC, which miners can use to boost or penalize specific transactions.

Bitcoin Core also computes an "ancestor score," defined as the minimum of a transaction's individual fee rate and its ancestor feerate. If a transaction has a high individual fee rate but low-fee ancestors dragging down the package, the ancestor score reflects the lower value, since those ancestors must be included first.

Block Template Construction

The BlockAssembler in Bitcoin Core (used by the getblocktemplate RPC) selects transactions for inclusion using ancestor feerate as follows:

1. Sort all mempool transactions by ancestor score (the minimum of individual fee rate and ancestor feerate)
2. Select the transaction with the highest ancestor score
3. Add that transaction and all its unconfirmed ancestors to the block template
4. Update the cached ancestor feerate values of remaining transactions, since ancestors now "in the block" no longer count
5. Repeat until the block weight limit (4,000,000 WU) or sigop limit is reached

To avoid floating-point division, the algorithm compares two candidates using cross-multiplication: it checks whether fees_A * size_B > fees_B * size_A to determine which candidate offers a better fee rate.

Historical Ancestor and Descendant Limits

Prior to cluster mempool, Bitcoin Core enforced per-transaction chain limits to bound the computational cost of tracking ancestor sets:

A special "CPFP carve-out" exception allowed one additional child beyond the descendant limit if it had exactly one unconfirmed ancestor and was no larger than 10 kvB. This exception was specifically designed for Lightning Network commitment transactions, where both channel parties need the ability to fee-bump a shared transaction.

Why It Matters

Ancestor feerate is the mechanism that makes CPFP fee bumping possible. Without it, a low-fee transaction stuck in the mempool during a fee spike could only be accelerated via replace-by-fee (RBF), which requires the sender's cooperation. CPFP lets the recipient create a high-fee child transaction that raises the ancestor feerate of the entire package above the prevailing market rate.

This is especially important for protocols where one party broadcasts a pre-signed transaction they cannot modify. In Lightning channels, for instance, a force-close broadcasts a commitment transaction with a fee rate that may have been set days or weeks ago. The closing party can use anchor outputs to attach a CPFP child, boosting the ancestor feerate so the commitment transaction confirms promptly.

For a deeper comparison of fee bumping strategies, see the research article on Bitcoin fee estimation algorithm comparison and the RBF and CPFP fee bumping guide.

Use Cases

• CPFP fee bumping: a recipient spends an unconfirmed output with a high fee, raising the ancestor feerate of the parent transaction so miners prioritize the entire package. This is the most common application of ancestor feerate in practice.
• Lightning channel closes: when a force-close broadcasts a pre-signed commitment transaction, anchor outputs allow either party to attach a CPFP child. The miner evaluates the ancestor feerate of the child to determine whether the commitment transaction is worth including.
• Fee estimation: wallets and fee estimation algorithms consider ancestor feerate when predicting confirmation times, since a transaction with low-fee ancestors will confirm slower than its individual fee rate suggests.
• Package relay: package relay (introduced in Bitcoin Core 28.0) allows a 1-parent-1-child package to be submitted together, enabling a low-fee parent to enter the mempool if its child pays enough to bring the ancestor feerate above the minimum relay fee.

Risks and Considerations

Mining and Eviction Asymmetry

Prior to cluster mempool, Bitcoin Core used different metrics for block construction and mempool eviction. Block construction sorted by highest ancestor feerate, while mempool eviction (when the mempool exceeded its size limit) sorted by lowest descendant feerate. These two heuristics are not perfectly complementary, leading to edge cases where the mempool could evict transactions that miners would want to include, or retain transactions that would never be mined.

Transaction Pinning

Ancestor and descendant limits created opportunities for transaction pinning attacks. An adversary could attach many low-fee descendants to a shared transaction, exhausting the descendant limit and preventing the counterparty from adding a CPFP child. This was a significant concern for Lightning Network and other contracting protocols that rely on timely confirmation. V3 transactions (BIP 431) addressed this by enforcing a strict 1-parent-1-child topology, ensuring ancestor feerate accurately reflects incentive compatibility.

Greedy Approximation

Ancestor feerate mining is a greedy heuristic: it picks the best-looking package at each step without considering the global optimum. In rare cases, this greedy approach can miss a more profitable set of transactions. For example, including a mediocre-feerate ancestor package early might consume block space that could have been better used by a group of smaller, higher-feerate independent transactions.

Cluster Mempool: The Evolution Beyond Ancestor Feerate

Bitcoin Core v31.0 introduced cluster mempool, a fundamental redesign that replaces ancestor feerate as the primary ordering metric. Under cluster mempool:

• Transactions are grouped into clusters: connected components of all related transactions (ancestors, descendants, siblings, and all transitive relatives) in the mempool
• Each cluster is linearized into an optimal ordering of "chunks," where each chunk is a group of transactions that should be included or excluded as a unit
• Chunk feerate replaces ancestor feerate as the primary metric for both block construction and mempool eviction, eliminating the mining/eviction asymmetry
• The old ancestor and descendant count/size limits are removed entirely, replaced by cluster limits of 64 transactions and 101 kvB per cluster

Chunk feerate is computed similarly to ancestor feerate but over an optimally determined grouping within the linearized cluster, rather than a simple ancestor chain. This enables more accurate transaction selection and makes RBF policy more principled: replacements must strictly improve the mempool's overall feerate diagram.

For a detailed explanation of how cluster mempool works, see the research article on Bitcoin cluster mempool explained.

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.