← Topics
Perth BitDevs — March 2026

Bitcoin Core v31
Feature Freeze

From fanquake (Michael Ford), who is originally from WA: "We've past feature freeze for Bitcoin Core v31, which should be released in early April." The headline feature: Cluster Mempool — years in the making and now merged.

5
Headline Features
v31
Next Release
Apr '26
Expected Release

What This Means for Users

Cluster Mempool Improved block template creation, tx eviction, and mempool behavior
Embedded ASMap Protections against eclipse attacks, out of the box
Private Broadcast Improvements to transacting privately
IPC Mining Interface Better interfacing for Stratum V2 mining
libbitcoinkernel Further modularization of the consensus engine library
Framing via @bitschmidty
Headline Feature
CM
Cluster Mempool
Complete redesign of mempool data structures using transaction clusters and optimal linearization
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.
AS
Embedded ASMap
Groundwork toward shipping AS (Autonomous System) mappings in the binary for better peer diversity
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.
PB
Private Transaction Broadcast
Broadcast your own transactions via short-lived Tor/I2P connections to prevent IP linkage
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.
IPC
IPC Mining Interface Improvements
Better inter-process communication for the mining interface, enabling external mining software to use libbitcoinkernel
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.
LBK
More Bitcoin Kernel Progress
Continued extraction of consensus logic into libbitcoinkernel — a standalone, reusable consensus engine
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.