Bitcoin Core 32.0 Targets October 10 Release as Final Testing Begins

Bitcoin Core 32.0 reaches the end of a development cycle where the most visible changes are not necessarily the most interesting. The release candidate is now available and the developers are aiming for October 10 for the final version. On the menu: better organized validation, revised HTTP server, and several security fixes. An AI-assisted audit also initiated a quite instructive test sequence: the initial diagnosis had not yet told the whole story.

Faster block validation without changing how Bitcoin works

Bitcoin Core allows a computer to verify transactions and network blocks itself, without having to delegate this task to an external service. Version 32.0 thus mainly affects node operators, developers, and services built around this infrastructure.

The most striking performance change concerns block validation. To verify a transaction, the software must retrieve the previous outputs it spends, the famous prevouts. When these are on disk, reading them can slow down the work. The new version allows preloading this data in parallel from the chainstate database.

Eight threads work by default, with a maximum set at sixteen. A more modest machine can reduce this number to zero and disable the mechanism.

This improvement will not make the blockchain faster and will not reduce the interval between blocks. It concerns the work done locally by the node. A technical nuance, certainly subtle on screen, but quite tangible for those who maintain the infrastructure day after day.

An AI-assisted audit finds a problem humans take further

The story begins with Matthew Zipkin, contributor known under the pseudonym pinheadmz. While auditing the new HTTP server with Kimi K3, an AI model also used by the Bitcoin Red Team, he stumbled upon a memory exhaustion scenario.

The server could continue reading data sent by a client while it was already processing a request. A malicious client could thus keep this request busy and send ever more data. This data accumulated in memory.

Zipkin first thought the attack required authentication. Then code review changed that picture. Developer jeanpablojp tested the REST interface and observed that 16 connections without credentials could increase the node’s consumption from about 46 MB to nearly 3 GB in one minute.

The AI had indeed spotted a problem. It had not closed the case. A human pushed the test further and found a wider vector. Here is a man-machine collaboration far more interesting than a simple match to see which one finds more bugs.

Fixing the memory issue created another headache

Zipkin’s first response followed a fairly sober logic: when a request is already being processed, there is no need to continue sucking the next data into the application’s memory. They can wait on the system side until TCP pressure naturally slows the sender.

The solution in this patch is to not even read the socket while we are busy processing a request.

Matthew Zipkin, GitHub PR #36123

However, the first patch had a flaw. On a persistent connection, jeanpablojp measured a median latency rising from about 0.14 ms to 53 ms. The fix protected memory but unnecessarily delayed some requests.

New version, new tests. After revision, 16 unauthenticated REST connections add only about 3 MB in 90 seconds, compared to 3.2 GB previously. The penalty of about 50 ms also disappears.

Not everything is free however. On an inactive node subjected to continuous pipelining, a reviewer measured a throughput dropping from 383 to 18.9 requests per second. A very specific case, which he says he does not find in any real client. Security therefore clearly wins, with a measured rather than hidden compromise.

What node operators can expect from the October release

Version 32.0 is not just about this memory story. Several less spectacular changes will come with it if the schedule holds. Four commands related to partially signed transactions will use PSBT v2 by default. Applications that need it will still be able to request the old version.

The HTTP server, meanwhile, has been rewritten to replace libevent. It applies stricter rules and by default limits to sixteen the number of HTTP clients connected simultaneously. Another appreciated saving: after rebuild, the txindex transaction index will take up less than half of its former disk space.

On the wallet side, exportwatchonlywallet will allow exporting the information necessary for a watch-only wallet without carrying private keys.

A fix also closes the walletnotify flaw. On non-Windows systems, an authenticated RPC user with the required rights could forge certain wallet names to cause command execution. These names are now treated literally.

For the user of a lightweight application, none of this will disrupt the day. For those running blockchain nodes, the details matter more.

To Remember Before October 10

• The release of Bitcoin Core 32.0 aims for October 10, 2026, a date that remains subject to change during the final testing of the release candidate.
• Validation will be able to preload certain data with eight threads by default and sixteen at maximum, without changing the block production rate.
• After correction, 16 unauthenticated REST connections added about 3 MB of memory in 90 seconds, versus 3.2 GB before revision.
• Four wallet commands will adopt PSBT v2 by default, while applications will retain the ability to request the previous version.
• A fully rebuilt txindex will take up less than half the disk space, while the new HTTP server receives several additional safeguards.

The schedule also offers a nice coincidence. While Bitcoin Core aims for October, Ethereum is preparing Glamsterdam, the next major evolution of its blockchain. Sepolia is expected to host a test on October 6, if the bugs still present on the devnets are fixed. The mainnet is still expected in the fourth quarter, with December still possible. Two different projects, the same method: test, sometimes break, fix a lot, then only deliver.