Bitcoin Core 32.0 arrives at the end of a development cycle where the most visible changes are not necessarily the most interesting. The version candidate is now available and the developers are targeting 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 rather instructive sequence of tests: the first diagnosis had not yet told the whole story.
In brief
- Bitcoin Core 32.0 is nearing release after several months of development, with a release candidate now undergoing final contributor testing.
- Block validation evolves under the hood thanks to the parallel loading of certain data, especially useful to operators running their own nodes.
- Kimi K3 helped spot a weakness in the HTTP server, before a developer discovered that the scenario could affect more connections.
- The patch itself required several adjustments, as its first version protected memory while introducing annoying latency on certain persistent connections.
- For the ordinary user, the change will remain largely invisible, while developers and operators will mainly benefit from a better protected and more efficiently organized infrastructure.
Bitcoin Core 32.0 especially speeds up work under the hood
Bitcoin Core allows a computer to verify network transactions and blocks itself, without having to delegate this task to an external service. Version 32.0 therefore mainly affects node operators, developers and services built around this infrastructure.
The most significant performance change concerns block validation. To verify a transaction, the software must notably find the previous outputs that it spends, the famous prevouts. When they are on disk, reading them can slow down your work. The new version allows this data to be preloaded in parallel from the chainstate database.
Eight threads work by default, with a maximum set to sixteen. A more modest machine could reduce this number to zero and deactivate the mechanism.
The gain will not make the blockchain faster or reduce the interval between two blocks. It concerns the work performed locally by the node. A technical nuance, certainly discreet on screen, but rather concrete for those who maintain the infrastructure day after day.
Kimi K3 spots a flaw, developers dig deeper
The story begins with Matthew Zipkin, a contributor known as pinheadmz. While auditing the new HTTP server with Kimi K3, an artificial intelligence model also employed by the Bitcoin Red Team, he came across a memory exhaustion scenario.
The server could continue reading data sent by a client while it was already processing a request. A malicious client was thus able to keep this request busy and then send more and more data. These accumulated in memory.
Zipkin initially thought the attack required authentication. Then the code review changed the picture. Developer jeanpablojp tests the REST interface and finds that 16 connections without credentials can increase the node’s consumption from around 46 MB to almost 3 GB in a minute.
The AI had therefore spotted a problem. She had not closed the investigation. A human took the test further and discovered a larger vector. This is a man-machine collaboration that is much more interesting than a simple match to see which of the two finds the most bugs.
The first fix slowed down the server too much
Zipkin’s first response followed a fairly sober logic: when a request is already processed, there is no point in continuing to suck subsequent data into the application’s memory. They can wait on the system side until TCP pressure naturally slows down the sender.
The solution in this patch is to no longer even read the socket when we are busy processing a request.
Matthew Zipkin, GitHub PR #36123
However, the first patch had a flaw. On a persistent connection, jeanpablojp measures a median latency going from around 0.14 ms to 53 ms. The fix protected memory, but caused some queries to wait unnecessarily.
New copy, new tests. After revision, 16 unauthenticated REST connections now only add about 3MB in 90 seconds, down from 3.2GB. The ~50ms penalty also disappears.
Not everything is free, however. On an inactive node subject to continuous pipelining, a reviewer measures 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 the day, with a measured rather than hidden compromise.
In October, operators will especially find cleaning useful
The 32.0 version is not just about this memory story. Several less dramatic 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 has been rewritten to replace libevent. It applies stricter rules and limits the number of HTTP clients connected simultaneously to sixteen by default. Another appreciable saving: after reconstruction, the txindex transaction index will occupy less than half of its old disk space.
On the wallet side, exportwatchonlywallet will allow you to export the information necessary for an observation wallet without taking the private keys.
A fix also closes the walletnotify flaw. On non-Windows systems, an authenticated RPC user with the required rights could fabricate certain wallet names in order to cause commands to be executed. These names are now treated literally.
For the lightweight app user, none of this disrupts the day. For those who run the blockchain nodes, the details matter more.
To remember before October 10
- The release of Bitcoin Core 32.0 aims October 10, 2026a deadline that remains likely to change during the final tests of the candidate version.
- Validation will be able to preload certain data with eight threads by default and sixteen at most, without changing the block production rate.
- After the fix, 16 unauthenticated REST connections added approximately 3 MB of memory in 90 seconds, compared to 3.2 GB before the revision.
- Four wallet commands will adopt PSBT v2 by default, while applications will retain the ability to request the previous version.
- A completely rebuilt txindex will take up less than half the disk space, while the new HTTP server gets several additional guardrails.
The calendar also offers a nice crossover. While Bitcoin Core is targeting October, Ethereum is preparing Glamsterdam, the next major evolution of its blockchain. Sepolia is scheduled to host a test on October 6, if the bugs still present on the devnets are corrected. The mainnet remains expected in the fourth quarter, with December still possible. Two different projects, the same method: test, break sometimes, correct a lot, then only deliver.
Maximize your Tremplin.io experience with our ‘Read to Earn’ program! For every article you read, earn points and access exclusive rewards. Sign up now and start earning benefits.
