Bitcoin Core developers have moved version 32.0 into release-candidate testing, with the stable software scheduled for a possible Oct. 10 release after weeks of public checks.
Summary
- Bitcoin Core 32 entered release-candidate testing on Sep. 14 following an August feature freeze.
- Parallel database reads could reduce block-validation times without changing Bitcoin’s block production rate.
- Four wallet commands will use PSBT version 2 by default while retaining the older format.
- Security fixes address unsafe wallet names and unauthenticated HTTP requests that caused heavy memory use.
Bitcoin Core 32 targets an Oct. 10 release
Bitcoin Core’s official release schedule shows that developers created the version 32 branch and started the release-candidate cycle on Sep. 14. The first candidate, known as v32.0rc1, is now available for testing before developers decide whether to tag the stable release.
The project set Oct. 10 as the intended date for version 32.0, though the schedule describes it as a target rather than a confirmed deadline. Problems found during candidate testing could require additional releases and delay the final version.
Preparations began months earlier. Developers opened translations and introduced a soft freeze on translation changes on Aug. 6, followed by a feature freeze on Aug. 20. From that date, the version 32 branch accepted bug fixes but no new features ahead of final testing.
When the branch separated from the main codebase on Sep. 14, development of Bitcoin Core 33 also began on the main branch. The split allows contributors to test and repair the upcoming release without stopping work on the next version.
Release candidates give node operators, wallet developers and other users time to find bugs under different hardware and software conditions. Bitcoin Core’s testing process covers functions including block validation, peer-to-peer communication, wallet operations and remote procedure calls used by applications connected to a node.
Parallel database reads speed up block checks
One of the main performance changes allows Bitcoin Core to read data from its database in parallel while checking blocks. The method can shorten validation time because the software no longer has to complete every relevant database read one after another.
Faster validation does not mean Bitcoin will produce blocks more quickly. Miners still compete to add blocks under Bitcoin’s proof-of-work rules, which target an average interval of roughly 10 minutes. Version 32 changes how a node processes required information rather than the network’s issuance schedule or block timing.
The distinction matters because Bitcoin Core is node software, not a centrally managed update to the Bitcoin network. Operators decide which version to install, and the release does not automatically replace the software running on every node.
Version 32 also does not introduce a new consensus rule or require a soft fork. Its release process differs from protocol changes that need coordination among miners, node operators, and other network participants.
As previously reported by crypto.news, LayerTwo Labs CEO Paul Sztorc said every proposed Bitcoin soft fork since Taproot has failed to activate. BIP-110, a disputed proposal linked to transaction-relay policy, received 2.53% miner support before its enforcing branch stalled after two blocks.
Bitcoin Core 32 can therefore improve software performance without depending on the activation process required for a consensus change. Node operators remain free to test the candidate, continue using an older release, or install the stable version after publication.
Wallet commands adopt the newer PSBT format
Wallet functions account for another set of changes in version 32. Four commands will create partially signed Bitcoin transactions using PSBT version 2 by default, according to details shared by Bitcoin News.
A PSBT lets separate wallets, devices, or participants exchange the information needed to build and sign a Bitcoin transaction without exposing private keys. The format is commonly used with hardware wallets, offline signing setups, and transactions that require more than one signature.
PSBT version 2 changes how transaction information is organized and permits participants to update parts of a transaction without first creating a complete unsigned transaction. The older PSBT format will remain available when users or connected applications require it.
Keeping both versions reduces the chance of abruptly breaking wallets and services that have not adopted the newer format. Developers integrating Bitcoin Core with other software will still need to check whether their systems expect the previous default.
For individual holders, the change does not alter Bitcoin balances, private keys or the rules governing valid transactions. Its practical effect falls on wallet workflows and applications that call the affected commands.
Security fixes reduce command and memory risks
Version 32 also includes a patch for custom wallet names that could cause commands to run on non-Windows nodes. The issue concerned how specially constructed names interacted with command execution, rather than a change to Bitcoin’s underlying cryptography.
A separate fix addresses memory growth caused by unauthenticated HTTP activity. In one test cited by Bitcoin News, memory use reached about 3.2 gigabytes before the patch, compared with roughly 3 megabytes after developers applied the change.
Remote interfaces allow other programs to communicate with Bitcoin Core, making memory controls relevant to operators who expose node services to connected applications. Access settings, firewalls and authentication remain separate parts of securing a deployment.
For U.S. users, the candidate is most relevant to node operators, wallet providers, exchanges, miners and infrastructure companies that run Bitcoin Core in their systems. The release does not change the SEC’s treatment of spot Bitcoin exchange-traded products, investor tax rules or the legal status of BTC.
American financial firms have also increased their support for Bitcoin’s open-source security work. In July, Anchorage Digital, ARK Invest, BlackRock, Block, Blockstream, Coinbase, Fidelity Digital Assets, Galaxy and Strategy formed the Bitcoin Security Consortium with $15 million in pledges over three years.
According to the consortium’s announcement, each member will direct its funding independently rather than placing the money in a shared pool. The group said it will not control Bitcoin development, take positions on specific protocol proposals or speak for the project’s contributors.
Mike Schmidt, executive director of Bitcoin developer-funding nonprofit Brink, coordinates the consortium’s daily work in a volunteer role. Its initial focus is research into long-term security issues, including protections against future quantum-computing risks.
