Bitcoin Core 32 Approaches Release as Final Tests Focus on Speed and Security

Bitcoin Core 32.0 is in the final stages of testing, with developers preparing the node software for a planned Oct. 10 release. The update introduces changes to fee estimation and block validation, along with wallet and security fixes.

The first release candidate was tagged on Sept. 14, marking the beginning of the final testing cycle outlined in the project’s release schedule.

Bitcoin Core allows computers running Bitcoin nodes to independently verify transactions and blocks using the network’s existing rules. The upcoming release does not modify Bitcoin’s consensus rules.

Transaction Fee Estimates Get an Update

Bitcoin Core 32 will use an additional source of data when calculating recommended transaction fees.

The current fee estimator mainly studies fees paid by transactions that were already included in previous blocks. The new estimator instead examines transactions that remain in the queue awaiting confirmation.

Bitcoin Core can compare the two calculations and choose the lower estimate when network conditions make that appropriate. According to the draft release notes, the change should allow recommended fees to decline faster after congestion decreases, rather than remaining elevated because of expensive transactions from earlier blocks.

The update also targets the time nodes spend retrieving transaction data during block validation. Bitcoin Core can now use multiple processing threads to access transaction information from its databases while validating blocks, with eight threads enabled by default.

This is intended to reduce delays caused by disk access, particularly when a node is catching up with the blockchain.

Long-Standing Wallet Issue Resolved

Version 32 also fixes a vulnerability that had been present since Bitcoin Core 24.0 on non-Windows systems.

An authenticated user who could create wallets could potentially construct a malicious wallet name that caused commands to execute on the host computer under certain conditions.

The exploit required walletnotify to be enabled. The feature automatically launches a specified command whenever a wallet transaction takes place.

The fix makes Bitcoin Core interpret wallet names strictly as literal text, preventing portions of a name from being processed as commands.

Partially Signed Transactions Move to PSBT v2

Four Bitcoin Core commands used to create partially signed transactions will begin using PSBT version 2 as their default format.

PSBTs allow transaction data to be passed between wallets and signing devices before a bitcoin transfer is finalized. The older format remains available when explicitly requested, but applications built directly around the affected Core commands will need to support PSBT v2.

New Web Server Tested for Memory Vulnerability

Bitcoin Core 32 is also introducing a replacement for the existing web server responsible for handling requests from applications that communicate with a node.

During an audit using Moonshot AI’s Kimi K3 model, researchers identified a memory-exhaustion issue in the new server. It could continue accepting data from a client while another request was still being processed, allowing information to accumulate in memory faster than the server could release it.

If left unresolved, the behavior could cause a node’s memory consumption to keep increasing until available resources were exhausted.

The issue was detected before the replacement server reached a stable Bitcoin Core release. Developers subsequently fixed the problem.

Tests also showed that the unauthenticated REST interface could trigger the same condition. One test involving 16 REST connections pushed memory usage from 46 MB to approximately 3 GB in about one minute.

In another 90-second test, memory consumption reached 3.2 GB before the fix but remained around 3 MB after the correction.

Bitcoin Core 32 is therefore approaching its October release with a combination of performance improvements, updated transaction handling and security fixes, while leaving Bitcoin’s underlying consensus rules unchanged.