Bitcoin Core 32 Enters Final Testing Before an October Release

Bitcoin Core tagged the first release candidate for version 32.0 on 14 September, which opens the testing window ahead of a release set for 10 October. Consensus rules are untouched. What changes is how a node validates blocks, how it guesses fees, and two bugs that gave an attacker more room than they should have had. Block validation now pulls from disk on eight threads at once. Neither security bug reached a shipped release before it was closed.

Eight threads aimed at the slowest part of the job

Validating a block means fetching every output its transactions spend, and fetching is disk work, so the processor spends much of the time waiting. Version 32 prefetches those lookups in parallel. All five accounts read for this article give the same default of eight worker threads. crypto.news and Cryptonomist add that the number is configurable up to 16, and the other three say nothing about a ceiling. Cryptonomist alone says the parallel reads leave block production unaffected. Crypto Briefing is the only outlet to attach a speed figure, claiming initial sync improved up to threefold in testing, and no other account gives any multiple at all. Take that one lightly.

The fee estimator gets a second opinion

Core has estimated fees from the history of confirmed blocks, which is a backward-looking measure and slow to notice when a queue clears. Version 32 adds a second estimator that reads the mempool, the pool of transactions waiting to be confirmed. When both produce a valid answer, the software returns the lower one. crypto.news, Bitcoin Magazine and Cryptonomist all state that rule; CoinDesk describes the new estimator without it. For a wallet, the practical effect shows up on the days after congestion drops, which is when the block history is still expensive and the queue is already empty. Fee spikes have been a fact of the year, and the backlog that made the mempool the busiest since February 2025 is the shape of week this is meant to read faster.

Two fixes, and four different memory figures

The first bug is old. On non-Windows systems, going back to version 24.0, an authenticated user could craft a wallet name that executed commands when the walletnotify hook fired. Version 32 treats the name as literal text. All five accounts carry it the same way, and Cryptonomist adds alone that relative-path elements are now rejected too. The second bug is new, found in the HTTP server that version 32 introduces, where unauthenticated REST connections could pile up data in memory faster than the server cleared it. Here the numbers scatter. CoinDesk says 16 connections took memory to 3 GB within a minute, against roughly 3 MB after the fix. crypto.news gives the same minute and the same 3 GB but starts the clock at 46 MB. Bitcoin Magazine and Cryptonomist both say 3.2 GB over 90 seconds. Two accounts say a minute and two say 90 seconds; the release notes could not be read to settle it. Bitcoin Magazine alone says the bug surfaced during testing with AI models, an echo of Core Lightning's machine-found bugs and their 14-day embargo in June.

What has to hold until 10 October

One change lands on other people's code. Four wallet commands, createpsbt, walletcreatepsbt, converttopsbt and psbtbumpfee, now produce version 2 of the partially signed bitcoin transaction format by default, with the older version still available on request. Crypto Briefing calls that a breaking change for wallet developers, exchanges and custody providers, and is the only outlet to frame it that way. A release candidate is not a release. bitcoincore.org listed no 32.0 entry of any kind at the time of writing, with 31.1 still the newest version on the page. Between now and October the candidate has to survive the people running it.