Bitcoin Core 32 Enters Final Testing With Faster Validation and a Smarter Fee Estimator
Bitcoin Core 32.0 has entered its final release-candidate testing cycle after developers tagged v32.0rc1 on September 14, moving the reference implementation of the Bitcoin network one step closer to its planned October 10 release. The update does not touch consensus rules, but it brings meaningful changes to fee estimation, block-validation performance and node security that ordinary users, wallet developers and node operators will notice once the final binaries ship.
According to the Bitcoin Core project’s official GitHub release page, v32.0rc1 sits at commit d0231bb and was signed with a verified maintainer signature on September 14 at 12:58 UTC. The release schedule still targets October 10 for the final tag, although that date remains subject to testing and further fixes. No final v32.0 binary has been released as of September 16, and the project reminds users that Bitcoin Core never updates automatically — operators choose when to install new versions, which is why release-candidate testing matters for catching problems early.
A fee estimator that blends mempool and block history
The most visible user-facing change affects estimatesmartfee, the remote procedure call that wallets and applications rely on to calculate transaction fees. Until now, Bitcoin Core’s primary estimator leaned on observed confirmation behavior from transactions included in past blocks. Version 32 adds a second estimator based on transactions currently waiting in the node’s mempool.
The new mempool estimator produces both economical and conservative estimates from pending transaction conditions. Bitcoin Core checks recent block activity before using it and can reject the estimate when the mempool appears too sparse or unhealthy. When both systems return valid results, estimatesmartfee returns the lower of the two figures. In its combined default mode, the new method therefore cannot push the existing block-policy recommendation higher — its role is to lower the recommendation when current mempool conditions support doing so.
The design has a practical consequence: it can respond more quickly after a period of expensive block space ends. A block-history estimator may keep incorporating recently confirmed high-fee transactions, while the mempool may already show fewer transactions competing for confirmation. Applications that prefer the previous behavior can still get it through a new fee_rate_estimator option, which preserves access to the older estimation method.
Faster block validation with prefetching across eight threads
Performance work in version 32 targets one of the node software’s core jobs: validating new blocks. The update changes how the software prefetches previous transaction outputs during validation, spreading that work across eight worker threads by default instead of leaving the process to wait on disk reads. For nodes validating blocks on hardware where disk latency is a bottleneck, the change should shorten the time between receiving a block and finishing validation.
The improvement matters most immediately after a new block is found, when every node on the network is simultaneously pulling the referenced outputs from disk. Reducing those waits helps the network propagate and validate blocks more smoothly, a behind-the-scenes upgrade that users will experience as a slightly faster, more responsive node rather than a headline feature.
Security fixes for wallet notifications and REST memory use
The release candidate also carries security-relevant fixes. Draft release notes flag a wallet notification flaw that could allow an authenticated user to execute commands on affected non-Windows node systems. Separately, testing found that sixteen unauthenticated REST connections could push memory use to roughly three gigabytes quickly, a denial-of-service vector the new version addresses.
That manual upgrade model has mattered in previous security disclosures. Bitcoin Core disclosed CVE-2024-52911 in May only after the vulnerable 28.x branch reached end of life — the bug had already been fixed in Bitcoin Core 29.0 before technical details became public. The episode underlines why node operators are encouraged to test release candidates and move to stable releases promptly.
A disciplined release process, not a protocol change
Developers entered feature freeze on August 20, limiting work to fixes needed before release. On September 14 they split the 32.x branch from the main development branch and started the release-candidate cycle, while work on version 33 resumed separately. Bitcoin Core opened a dedicated 32.0 release-candidate testing feedback issue on September 15, one day after RC1 was tagged, asking testers to follow the RC testing guide and report problems through separate GitHub issues.
It is worth repeating what version 32 is not: the draft release notes list no change to Bitcoin’s consensus rules. The update does not redefine which transactions or blocks the network considers valid. Instead, it concentrates on node software behavior, wallet interfaces, fee calculation, networking and performance — the unglamorous engineering layer that keeps hundreds of thousands of nodes around the world running the same rules efficiently.
For wallet developers, the new dual estimator is the change most worth testing, since fee recommendations directly shape user costs. For node operators, the prefetching change and the REST memory fix are the headline items. And for everyone holding bitcoin at current prices near 75,780 USD, the release is a reminder that the network’s most important software continues to ship steady, careful improvements on a predictable cadence — no hype required.
rc1 tagged sept 14 with zero consensus changes, first core release i will install on day one instead of waiting a month for other people to find bugs
a smarter fee estimator alone is worth the upgrade, been overpaying on saturday congestion for years. rc1 tagged sept 14 so oct 10 looks realistic
its the validation speedup that matters more imo. full nodes on cheap hardware are what keep the network honest, fees are second order
both matter honestly. faster validation means more people can run full nodes and a sane fee estimator keeps the mempool from overcharging everyone during spam. upgrade reads well on both fronts
validation speedup compounds with pruning though. cheaper sync means more archival nodes survive, and those matter for the network just as much as fees
cheaper validation actually pushes the other way tho, more people run full nodes but fewer bother with archival. bandwidth costs dont care about cpu gains
fair but lower fee estimates compound hard for anyone batching withdrawals. both matter, validation just gets the headlines
No consensus changes means no drama this cycle. My old laptop running a pruned node will appreciate the faster block validation
pruned node on a 2015 thinkpad squad checking in. oct 10 still holding on the schedule page, quiet upgrade for exactly us
running rc1 on testnet and fee quotes are noticeably saner during weekend congestion. zero consensus changes means oct 10 might actually be boring, best case scenario
A mempool based fee estimator is honestly overdue. Block based estimates had me overpaying plenty of times during spam waves.
same, the old estimator during the runes spam was useless, kept quoting me like the mempool was empty
runes spam week quoting fees like the mempool was empty was pure pain. economic vs conservative gap was 5x at one point
that 5x gap during runes week is exactly why returning the lower estimate is the right default. wallets overriding it are volunteering to overpay
that 5x gap during runes week is exactly why mempool history matters. block only estimators kept quoting the past while the mempool was on fire
that 5x gap during runes week cost me real sats on a batch of utxo sweeps, never trusting block-only quotes again
monotone downward estimator plus parallel validation, first core release in ages i would call a straight upgrade for node ops
rc1 at commit d0231bb, if nothing ugly surfaces by oct 10 both my nodes update day one. the validation gains alone are worth it
october 10 with zero consensus changes is the quietest release cycle in years. node operators deserve a boring upgrade after the last few
still running an older node like a boomer but glad validation keeps getting faster, sync times on new hardware drop every single release
returning the lower of the two estimates is the detail everyone misses. the mempool estimator can only push fees down, never up. quietly saves sats
lower of the two is such an elegant default. wallets that override it with conservative mode leave sats on the table
wallets overriding conservative mode is exactly how fee spirals start again. ship the default, the devs argued over it longer than any of us
monotone downward estimates also stop the panic bidding spiral during spam. small design choice with second order effects most wallets never notice
a fee estimator that learned from the runes week mess and zero consensus changes. boring releases like this are what keep the network running