Bitcoin Core 32 begins final testing, with Oct. 10 release targeted

Release cycle enters public review

Bitcoin Core’s published schedule shows translations opened earlier in the cycle, with a soft freeze on translation changes beginning Aug. 6 and a feature freeze taking effect on Aug. 20. After that point, the version 32 branch accepted bug fixes but no new features ahead of release-candidate testing.

Release candidates are intended to give node operators, wallet developers and other users time to test the software across a range of hardware and operating environments. That review covers major areas including block validation, peer-to-peer networking, wallet behavior and remote procedure calls used by software connected to a node.

Performance update focuses on validation speed

Among the more notable changes in version 32 is support for parallel database reads during block checks. By allowing the software to fetch required data concurrently instead of handling every read in sequence, the update could reduce the time a node needs to validate blocks.

That improvement does not change Bitcoin’s block production schedule. Blocks are still created under Bitcoin’s proof-of-work rules, which aim for an average interval of about 10 minutes. The update affects how node software processes information locally, not the network’s issuance rate or consensus timing.

The distinction is important because Bitcoin Core is software that node operators choose whether to install. Version 32 does not introduce a new consensus rule, and it does not require a soft fork or coordinated activation across the network.

Wallet defaults shift toward PSBT v2

Version 32 also changes wallet behavior by making four commands create partially signed Bitcoin transactions, or PSBTs, in version 2 format by default. The older PSBT format is still available for users and applications that depend on it.

PSBTs are used to pass transaction details between wallets, devices or participants without exposing private keys. They are commonly used with hardware wallets, offline signing setups and multi-signature transactions. According to the reported changes, PSBT v2 reorganizes transaction data and allows parts of a transaction to be updated without first building a complete unsigned transaction.

Because the previous format remains supported, the change is aimed at reducing compatibility problems for wallets and services that have not yet switched their own systems to the newer default.

Security fixes address wallet names and memory use

The release candidate also includes a fix for unsafe custom wallet names that could cause commands to run on non-Windows nodes. The issue involved command execution behavior tied to specially crafted names, rather than any change to Bitcoin’s cryptographic rules.

Another patch targets memory growth triggered by unauthenticated HTTP activity. In one cited test, memory usage reportedly climbed to about 3.2 gigabytes before the fix, compared with roughly 3 megabytes after the change was applied.

That matters for operators who expose Bitcoin Core interfaces to other applications, since remote services rely on those communication paths. The article notes that authentication, firewalls and access settings remain separate parts of securing a node deployment.

What happens before release

For now, the next confirmed step is wider testing of v32.0rc1. If testers do not uncover major problems, developers could proceed with the planned 32.0 release on Oct. 10.

If issues appear during the candidate phase, additional release candidates may be needed before a stable version is tagged. Until then, node operators can test the new build, stay on an older version, or wait for the final release decision.