Bitcoin Core 32 Nears October Release With Parallel Block Validation and a Smarter Fee Estimator
Bitcoin Core, the reference implementation that powers the majority of Bitcoin nodes worldwide, has entered the final stretch toward its next major release. Developers tagged version 32.0rc1 on September 14, kicking off the release-candidate testing cycle that is expected to conclude with a stable release on October 10, provided no critical issues surface during testing.
The release candidate, built at commit d0231bb and signed with a verified maintainer signature at 12:58 UTC on the tagging date, represents months of focused engineering work. Crucially, the draft release notes confirm that version 32 does not change any of Bitcoin’s consensus rules, meaning the update redefines nothing about which transactions or blocks the network considers valid. Instead, the release concentrates on node performance, wallet interfaces, fee calculation and networking, the plumbing that determines how smoothly the network runs day to day.
From feature freeze to release candidate
Development discipline around the release has been strict. Engineers entered feature freeze on August 20, after which only fixes deemed necessary for the release were permitted. On September 14 the 32.x branch was split from the main development line, freezing the codebase for candidate testing while work on version 33 continued separately.
A dedicated testing feedback issue opened on GitHub one day after the RC1 tag, inviting node operators, wallet developers and service providers to run the candidate against a published testing guide. No final v32.0 binary has been published as of September 16, and the October 10 target remains subject to further fixes.
The manual upgrade model that Bitcoin Core follows adds weight to the testing cycle. Nodes do not auto-update, so older releases can remain active in production long after newer software ships. That reality has mattered before: the project disclosed CVE-2024-52911 in May only after the vulnerable 28.x branch reached end of life, with the fix having already landed in version 29.0.
A fee estimator that reads the mempool
Among the most user-visible changes in version 32 is a reworked estimatesmartfee, the RPC call that wallets and applications rely on to calculate transaction fees. Historically, the primary estimator drew its conclusions from confirmation behavior observed in past blocks, a backward-looking approach that can lag real conditions.
Version 32 introduces a second estimator based on transactions currently sitting in the node’s mempool. The new method produces both economical and conservative estimates from pending conditions, and it checks recent block activity before trusting its own output, rejecting the estimate entirely when the mempool looks too sparse or unhealthy.
When both estimators return valid results, estimatesmartfee returns the lower of the two figures. The design means the mempool estimator can only pull fee recommendations downward, never push them higher, and it allows the system to respond quickly when an expensive period of block-space competition ends and waiting-room conditions have already eased. Applications that prefer the old behavior can select it explicitly through a new fee_rate_estimator option offering block_policy, mempool_policy or the combined default. Statistics from the mempool estimator persist in a separate data file so they survive node restarts.
Parallel prefetching for block validation
The release also reshapes how nodes retrieve transaction data while connecting new blocks. Bitcoin Core 32 can now prefetch previous transaction outputs, known as prevouts, from the chainstate database across multiple worker threads while validation proceeds in parallel. The default configuration uses eight prefetch threads, and operators can raise that number to 16 or disable the feature entirely by setting it to zero through the new prevoutfetchthreads option.
Prevouts identify the coins being spent by transaction inputs, and nodes need them to verify that inputs exist, have not already been spent and satisfy the applicable validation rules. Because that data often lives on disk rather than in faster memory caches, disk waits have long been a bottleneck during block connection. The parallel prefetching feature is designed to cut that idle time, though the actual benefit will vary with storage hardware, cache behavior and node configuration.
Separate RPC improvements give operators better visibility during AssumeUTXO background validation, with getblockchaininfo gaining additional reporting once a snapshot-based node reaches the chain tip.
Security fixes accompany the performance work
Two security-relevant findings addressed in this cycle underline why regular upgrades matter. Testing determined that a modest number of unauthenticated REST connections, on the order of sixteen, could drive memory use toward three gigabytes in a short period, a potential denial-of-service vector for exposed nodes. In addition, a wallet notification flaw could allow authenticated users to execute commands on affected non-Windows systems, a privilege-escalation risk in multi-user deployments.
Neither issue touches consensus, but both illustrate the ongoing maintenance burden carried by the volunteer developers who keep the reference client hardened against a hostile internet.
What it means for the network
For node operators, version 32 promises faster initial block download and validation on storage-constrained hardware, more accurate fee guidance for wallet users, and a cleaner set of diagnostics for advanced deployments. For the broader ecosystem, the release continues a pattern of steady, conservative engineering: no protocol fireworks, no contentious changes, just measurable improvements to the software that secures hundreds of billions of dollars in value.
The October 10 target now depends on the feedback that arrives through the testing channel. If the candidate holds up, the network’s operators will have one more reason to schedule an upgrade before the end of the year, and the long process of shipping version 33 will already be underway on the development branch.
parallel block validation finally landing in core is huge for IBD times. no consensus changes makes the upgrade painless too
@segfault_sam_ rc1 built at d0231bb and maintainer signed same day. verify your downloads people, dont trust random binaries
Good point on signatures. The number of people grabbing rc1 from a random mirror without checking the maintainer sig is definitely nonzero.
initial sync is exactly where this shows up, did a fresh node last month and the validation stall on every block was painful. oct 10 cant come soon enough
Feature freeze August 20, rc1 September 14, stable October 10. That schedule discipline is why Bitcoin ships boring and reliable.
smarter fee estimator is the sleeper feature here. anyone who paid 40 sats/vbyte on a weekend for no reason knows the pain
paying rush hour fees at 3am on a sunday is such a core rite of passage lol. 40 sats for what should have been 6
40 sats/vbyte on a quiet sunday still haunts me. if the new estimator fixes weekend overpayment alone, the oct 10 upgrade is worth it
40 sats on a dead sunday is criminal. pretty sure the blended mempool plus block history approach is aimed squarely at that case
@sats4bytes same, 40 sats/vbyte on a dead sunday while my tx was 140 bytes. estimator fixes are unglamorous but they pay for themselves instantly
same here, a 140 byte tx paying like it was an ordinals rush. if the estimator blends quiet block history properly the sunday penalty finally dies, unsung upgrade
the old estimator treating a quiet sunday mempool like a priority rush is exactly why i stopped trusting default fees. blending block history in should fix that
no consensus changes means i can actually upgrade my node on release day without holding my breath. parallel block validation alone should cut initial block download times nicely
october 10 assumes no critical bugs turn up in rc testing. give it two more rc tags before anyone gets excited imo
two more rc tags is the normal path though. v29 went through several before final iirc, a slip past oct 10 would be the exception not the rule
v25 went through like five rcs if i remember right. oct 10 holds unless someone finds something ugly in the parallel validation paths, thats where the fresh bugs will hide
@testnet_terje five rcs for v25 was mostly the libevent stuff iirc, this one has fewer moving parts. still waiting for rc2 before touching prod though
fresh bugs hide in the parallel validation paths exactly. would bet on at least one more rc tag before oct 10 holds
Initial block download is the metric i care about. ran a full sync last month and validation was the bottleneck the entire way, parallel validation should cut that hard
validation being the ibd bottleneck matches my last sync too. parallel paths should eat that, curious whether pruned nodes see the same gain or just full cpu relief
wonder if parallel validation changes the prune mode calculus. pruned nodes still validate every block, faster validation means less disk thrash on my setup
curious about this too. faster validation on a pruned box mostly means less time pinned at full cpu during ibd, doubt it changes what you keep on disk
smarter fee estimator is underrated. been overpaying on consolidate transactions for months because the old estimator panics whenever the mempool gets spicy
same, paid 3x what i needed last week. hoping this ships without slipping past october 10
true, consolidation txs get the worst of it. if the estimator blends block history like the notes say, the quiet sunday overpayment penalty finally dies
no consensus changes is the headline tbh. means i can update my node the week after release without re reading every BIP discussion first
zero consensus changes is the detail that matters. node software getting faster without touching validation rules is the quiet kind of upgrade bitcoin does better than anyone
parallel validation plus a fee estimator that blends block history. the 40 sats on a dead sunday tax finally dies, that alone is worth the upgrade