Bitcoin Core v31 Feature Freeze

Headline Feature

Cluster Mempool is the most significant mempool overhaul in Bitcoin Core's history. The existing mempool tracks individual transactions with ancestor/descendant limits, which leads to suboptimal fee-rate ordering, makes RBF (Replace-By-Fee) reasoning fragile, and limits the ability to construct optimal block templates.

The new approach organizes the mempool into clusters — connected components of transactions related by parent-child dependencies. Each cluster is then linearized: its transactions are ordered so that parents always come before children, and the resulting sequence is split into chunks of decreasing feerate. This chunked linearization allows the node to quickly identify the most profitable set of transactions for block building, reason precisely about eviction, and handle RBF correctly.

How Chunks Work

Chunk 1

50 sat/vB

Chunk 2

30 sat/vB

Chunk 3

12 sat/vB

Chunks are topologically-valid groups, sorted by decreasing feerate.
Block building simply takes chunks from the top until the block is full.

Interactive Worked Example: One Cluster, Three Approaches →

Spanning-Forest Linearization (SFL)

The algorithm that makes cluster mempool practical. SFL computes a near-optimal linearization by constructing a spanning forest of the transaction dependency graph. Instead of trying every possible ordering (exponential), SFL exploits the tree structure to find high-feerate topological orderings efficiently.

Cluster
Graph

→

Spanning
Forest

→

Optimal
Ordering

→

Feerate
Chunks

              Developed by sipa (Pieter Wuille) — one of Bitcoin Core's most prolific contributors
            

#32545

Replace Cluster Linearization Algorithm with SFL

Implements spanning-forest linearization, replacing the previous LIMO algorithm. SFL produces better linearizations and is conceptually simpler, building on tree-structure properties of dependency graphs.

github.com/bitcoin/bitcoin/pull/32545

#34259

Find Minimal Chunks in SFL

Enables splitting chunks into smaller equal-feerate parts, giving the block-building algorithm more flexibility for bin-packing optimization. Without this, some wasted block space is inevitable when large chunks don't quite fit.

github.com/bitcoin/bitcoin/pull/34259

#34023

Optimized SFL Cluster Linearization

Significant performance improvement to the SFL implementation, making it practical for the real-time demands of mempool processing and block template construction.

github.com/bitcoin/bitcoin/pull/34023

Why It Took Years

2021-2022

Initial research into cluster-based mempool organization by sipa and others. Core insight: grouping related transactions and linearizing them solves multiple longstanding problems simultaneously.

2023

Formal specification of cluster linearization algorithms. Extensive discussion on Delving Bitcoin. The LIMO algorithm was the first candidate.

2024

Groundwork PRs merged: cluster data structures, linearization framework. Spanning-Forest Linearization (SFL) proposed as a superior replacement for LIMO.

2025-2026

Merged for v31. SFL algorithm, minimal chunk finding, and optimized implementation all land. The complete cluster mempool is now part of Bitcoin Core.

What It Fixes

Ancestor/descendant limits that artificially constrained mempool packages. CPFP fee-bumping now works naturally across whole clusters.

Block Building

Near-optimal block templates with correct feerate ordering. Miners extract more fees, users get fairer fee markets.

RBF Improvement

Replacement transactions can now be evaluated against the entire cluster's linearization, not just direct ancestors.

Eviction Logic

When the mempool is full, lowest-feerate chunks are evicted — a principled approach replacing the old ancestor-score heuristic.

ASMap is a mapping from IP address ranges to Autonomous System Numbers (ASNs). An Autonomous System is a network operated by a single entity — think ISPs, cloud providers, hosting companies. Bitcoin Core uses this data to ensure it connects to peers across diverse network operators, making eclipse attacks (where an attacker surrounds your node with their own peers) significantly harder.

Previously, users had to manually download and configure ASMap files. v31 includes groundwork toward embedding a curated ASMap directly in the Bitcoin Core binary (PRs #33770, #28792), so that in a future release every node will benefit from AS-aware peer selection without any extra setup.

Eclipse Attack Defense

Ensures your node connects to peers across multiple ASNs, not just different IPs that might all be on the same network.

Zero Configuration

Previously required manual ASMap download and -asmap= flag. Now works by default for all users.

Continuing the work we discussed at Perth BitDevs in February. When your node broadcasts a transaction you created, network observers can use timing analysis to link that transaction to your IP address. The fix: broadcast locally-submitted transactions only via short-lived, disposable Tor or I2P connections.

Each transaction broadcast creates a fresh anonymous connection, sends the transaction, and tears it down immediately. No persistent channel to fingerprint. This is a 12-year-old problem (GitHub issue #3828, filed in 2014) that is finally being addressed with concrete code.

How It Works

Fresh Tor/I2P circuit per transaction. Connect, broadcast, disconnect. No reuse, no fingerprinting surface.

Feb 2026 Connection

We covered PR #29415 in the February meetup. The v31 inclusion represents the culmination of that work.

The IPC (Inter-Process Communication) mining interface allows external processes to interact with Bitcoin Core's block template construction and validation logic. This is a key piece of the libbitcoinkernel project: as consensus-critical code gets extracted into a standalone library, the IPC layer provides a clean boundary between the kernel and the rest of the node.

Improvements in v31 make the mining interface more robust and feature-complete, providing a path for future Stratum V2 integration (not yet implemented). External mining software can communicate with the kernel process without being tightly coupled to Bitcoin Core's internal architecture. This separation also improves security: the mining interface runs with minimal privileges, reducing attack surface.

For Mining Software

External mining software can request block templates and submit blocks via a stable IPC interface.

For Kernel Separation

Clean process boundary enables the kernel to run isolated from networking, wallet, and GUI code.

libbitcoinkernel is an ongoing, multi-year effort to extract Bitcoin Core's consensus-critical code into a standalone C++ library. The goal: any software can validate Bitcoin blocks and transactions by linking against this library, without needing to embed all of Bitcoin Core. This benefits alternative node implementations, testing infrastructure, and research projects.

v31 continues this work with further decoupling of consensus code from Bitcoin Core's networking, wallet, and RPC layers. TheCharlatan (Sebastian Kung, added as Core maintainer in January 2026) has been a key driver of this effort. The kernel library is becoming increasingly usable as a standalone component.

Why It Matters

Alternative implementations can share consensus code instead of reimplementing it, reducing the risk of consensus bugs.

Who's Driving It

TheCharlatan (new Core maintainer) and others. Funded by Spiral and MIT DCI.

What This Means for Users

How Chunks Work

Spanning-Forest Linearization (SFL)

Why It Took Years