Bitcoin Core v32 entered feature freeze on August 20, 2026, locking 79 completed milestone items and leaving 17 open for bug-fix-only resolution before a target final release on October 10. The release introduces the first mempool-aware fee estimator in Bitcoin Core's history, a descriptor-wallet...
"A Node can get a fee estimate by generating a block template from mempool transactions, using the fee rate of the transaction at the 50th percentile of the generated block weight as the fee rate estimate." — Abubakar Sadiq Ismail, Bitcoin Core contributor and author of PR #34075
Bitcoin Core v32 entered feature freeze on August 20, 2026, locking 79 completed milestone items and leaving 17 open for bug-fix-only resolution before a target final release on October 10. The release introduces the first mempool-aware fee estimator in Bitcoin Core's history, a descriptor-wallet compatibility fix addressing upgrade failures, and a proposal to reject unencrypted peer-to-peer connections — a step toward completing the BIP-324 encrypted transport rollout.
The freeze marks a transition point for the software that runs on approximately 98.5% of publicly reachable Bitcoin nodes. With Bitcoin Knots now claiming 19% of the network and a contested policy landscape around OP_RETURN limits, the v32 release cycle is unfolding against a backdrop of the most significant client-diversity debate in Bitcoin's 17-year history. Maintainer fanquake opened the release schedule issue on April 20, 2026, targeting a branch split on September 10 and a release candidate (rc1) on the same date.
The v32.0 release follows a phased progression established by maintainer fanquake in GitHub Issue #35122:
| Date | Milestone | |------|-----------| | August 6, 2026 | Transifex translations opened; soft translation freeze | | August 20, 2026 | Feature freeze; translation string freeze | | September 10, 2026 | Branch-off of 32.x from master; RC1 release | | October 10, 2026 | Target date for v32.0 final release |
As of August 17, the v32 milestone stood at 82% completion: 79 items closed, 17 open. By August 22, GitHub showed 85.86% completion. The 17 remaining open items span features, bugs, build work, testing, and release administration. Two open pull requests — PR #30951 (unencrypted connection rejection) and PR #35730 (HTTP client limits) — carry "Needs rebase" labels, meaning the patches no longer apply cleanly to the current codebase and require developer intervention before merge.
The prior release, Bitcoin Core v31.1, shipped with privacy patches for PrivateBroadcast address leakage, improved proxy handling, MuSig2 validation hardening, and blockchain database efficiency improvements. V32 builds on that foundation with more substantial architectural changes.
The single most consequential technical change in v32 is PR #34075, authored by Abubakar Sadiq Ismail (ismaelsadeeq). It merged the morning after the feature freeze on August 20, 2026, introducing mempool-based fee estimation to Bitcoin Core for the first time.
The Problem. Bitcoin Core's existing fee estimator, CBlockPolicyEstimator, relies exclusively on historical block data. It does not examine unconfirmed transactions in the mempool. When miners clear a congestion backlog, the estimator continues recommending fees based on stale historical patterns, causing systematic overpayment. It also fails to react quickly to sudden congestion spikes, causing underpayment and missed confirmation targets.
The Solution. PR #34075 implements a "one-way ratchet" mechanism. The system constructs a block template from current mempool transactions, extracts a percentile fee rate (75th percentile for economical mode, 50th for conservative), and uses this value exclusively to lower existing CBlockPolicyEstimator recommendations. It never raises them. This design choice prevents a hostile actor from flooding the mempool with high-fee junk transactions to artificially inflate fee recommendations for all users.
Empirical Results. Ismail's testing across 19,154 fee estimates (blocks 832,330 through 834,362, February 28 to March 12, 2024) demonstrated:
The system includes safety checks: it refuses to operate unless the last six blocks show removed mempool transaction weight exceeding 75% of block weight above baseline, ensuring the node's mempool view aligns with what miners are actually selecting. Estimates are cached at most every seven seconds when the chain tip remains stable.
The design treats underestimation as the preferable failure mode. Modern Bitcoin supports post-broadcast fee adjustment through Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP), making underpayment recoverable but overpayment permanent.
PR #30951 proposes allowing node operators to reject unencrypted v1 outbound clearnet connections. This represents a further step in the multi-year rollout of BIP-324, the encrypted transport protocol that uses ChaCha20-Poly1305 encryption with session keys and forward secrecy.
BIP-324 encrypts all peer-to-peer metadata, making it harder for third parties to track transaction broadcasts, peer discovery, or connection patterns. Message padding standardizes packet sizes to prevent traffic analysis from exposing user behavior.
The PR carries a "Needs rebase" label as of the freeze date, placing its inclusion in v32 in question. If it misses the cut, it would likely roll into the v33 cycle. Bitcoin Core v31 had already patched a related PrivateBroadcast issue where a user's IP address could be inadvertently disclosed when connecting to the network.
PR #35445 addresses an upgrade-related failure in descriptor wallets — the modern wallet format that replaced legacy wallets in recent Core versions. The fix preserves access to older Miniscript-based wallets when a recomputed descriptor identifier does not match the stored record.
The issue was documented in a real-world case where upgrading from v29.2 to v31.1 caused wallet load failures. Without this fix, users upgrading across multiple major versions risk losing access to funds in wallets using complex spending conditions defined through Miniscript.
This is a targeted fix rather than a broad wallet architecture change, but it reflects a recurring challenge in Bitcoin Core development: maintaining backward compatibility across a software stack that now spans 17 years of incremental changes.
PR #35680 addresses a memory management issue in Bitcoin Core's transaction rebroadcast system. Without the fix, rebroadcast-related state can grow without bound, consuming increasing amounts of node memory over time.
A related test for v1 retry behavior (Issue #35508) remains in the milestone with a failing test, indicating the rebroadcast subsystem requires additional work before the September 10 branch split.
Additionally, PR #35730 proposes capping simultaneous HTTP clients to prevent resource exhaustion on nodes that serve RPC requests. Like the unencrypted connection rejection PR, it carries a "Needs rebase" label.
The v32 release cycle unfolds during the most significant client-diversity debate in Bitcoin's history. Bitcoin Knots, a fork maintained by developer Luke Dashjr, has climbed to 19% of active nodes, according to network crawlers. Both clients use identical user agent strings (/Satoshi:XX.X.X/), making precise attribution difficult, though Knots-specific versions are distinguishable.
The underlying dispute centers on Core's removal of the 80-byte OP_RETURN data limit, which was implemented in v30 (October 2025). Knots retains the limit, effectively rejecting transactions that embed data exceeding that threshold. If policy divergence between Core and Knots widens, it raises theoretical chain-split concerns, though both clients share identical consensus rules at the protocol level.
Analysis of community responses to Core's v29.1 release showed 129 replies taking a negative stance toward the announcement, including criticism of the release, promotion of Knots as an alternative, and refusal to upgrade. This level of organized dissent is unusual in Bitcoin Core's release history.
V32 does not introduce new OP_RETURN-related policy changes, but the client diversity trend provides important context for the release's adoption trajectory.
Bitcoin's reachable node count varies significantly depending on measurement methodology and timing:
Approximately 98.5% of publicly visible nodes run Bitcoin Core or its derivatives. The three most widely used client versions as of mid-2026 were /Satoshi:29.0.0/, /Satoshi:28.1.0/, and the Knots variant /Satoshi:28.1.0/Knots:20250305/.
V32 adoption will depend on operator upgrade cycles, which historically span months. Many node operators run versions two or more major releases behind the latest.
Bitcoin Core development relies on a distributed grant funding model rather than corporate sponsorship or product revenue. The primary funding organizations:
This funding model sustains a contributor base that produced 96 planned milestone items for v32 across wallet improvements, network privacy, fee estimation, and rebroadcast handling.
Bitcoin Core v32 is an infrastructure release, not a protocol-level change. It touches no consensus rules. Its value lies in operational improvements: smarter fee estimation that reduces user overpayment, privacy hardening through encrypted connection enforcement, and compatibility fixes that prevent fund-access failures during upgrades.
The mempool-aware fee estimator is the most technically significant addition. For years, third-party fee estimation services filled the gap left by Core's backward-looking block-based estimator. PR #34075 narrows that gap with a design that prioritizes safety over responsiveness — underestimation is recoverable via RBF; overpayment is not.
The October 10 target date places the final release approximately seven weeks away. Between now and then, the 17 remaining open items must be resolved, rebased, or deferred. The rebroadcast subsystem's failing test (Issue #35508) and the two "Needs rebase" PRs represent the primary risks to the timeline. Whether v32 ships on schedule or slips will depend on contributor availability during the September branch-off window — a period that coincides with the start of academic and conference seasons in the Northern Hemisphere.