On September 14, the Bitcoin Core team announced the release of the first candidate for version 32.0, labeled v32.0rc1. This update will modify the fee estimation mechanism, enhance block validation speed when reading data from disk, and address a vulnerability related to walletnotify. This vulnerability affects only specific configurations and requires authenticated RPC access, as detailed in the official roadmap and the draft release notes.
The stable release of Bitcoin Core 32.0 is expected on October 10. The release notes do not indicate any changes to Bitcoin's consensus rules, focusing instead on client software updates.
Fee Estimation Will Factor in Mempool Status
In Bitcoin Core 32.0, the team will revise the operation of estimatesmartfee, which helps determine the fee required for transaction confirmation over a specified number of blocks. Currently, the block_policy estimator relies on data from already confirmed transactions; the new version will introduce mempool_policy, which analyzes the current state of the mempool.
By default, the client will use both algorithms and return the lower of the two estimates. This new mechanism aims to lower the recommended fee after a decrease in network load, but it will not raise it beyond the block_policy result.
Users will have the option to explicitly select one of the algorithms using the fee_rate_estimator parameter. If the new estimator lacks sufficient data, it will return an error. This may occur, for example, while the mempool is loading or if there are not enough recent blocks available, or if the mempool's state is deemed unsuitable for reliable estimation.
The developers have also implemented parallel pre-fetching of data about used transaction outputs (prevouts) during block validation. By default, Bitcoin Core will utilize eight threads, with a maximum of 16. The parameter -prevoutfetchthreads=0 will disable this feature.
This change is expected to speed up block validation, particularly when necessary data must be read from disk. The effect will be less pronounced if the data is already in RAM.
Another modification will affect partially signed Bitcoin transactions (PSBT). The commands createpsbt, walletcreatepsbt, converttopsbt, and psbtbumpfee will now default to creating PSBT version 2. Users can select a different version if needed via the psbt_version argument.
Developers Addressed Vulnerability
Bitcoin Core 32.0 also fixes a vulnerability that was present in the client since version 24.0. This issue affected non-Windows systems when using the -walletnotify parameter with the %w placeholder. This setting allows the operator to automatically execute a specified command upon the occurrence of a wallet-related transaction.
An authenticated RPC user with wallet creation privileges could set a specially crafted name. Upon subsequent transaction notifications, characters within the name could disrupt shell escaping, allowing for additional commands to be executed on behalf of the Bitcoin Core process under the right walletnotify template.
The problem arose because the ReplaceAll() function passed the escaped wallet name to std::regex_replace() as replacement text. Developers have modified the mechanism to ensure the name is processed literally.
This vulnerability could not be exploited through a standard P2P connection or without authorization. An attack required RPC access with wallet creation rights, a configured walletnotify with %w, and a non-Windows operating system.
Issue with New HTTP Server
The 32.0 branch also includes a fix for another security issue identified during an audit of the new HTTP server by Kimi K3. If the server was already processing a request, a client could continue sending data without limits on its volume. Under certain conditions, this could lead to uncontrolled memory consumption by the process.
Developers have restricted the server from reading new data from the socket while the previous request is still being processed. In this scenario, the incoming stream is limited by TCP mechanisms. For the most realistic exploitation scenario, an authenticated client was also required.
The new HTTP server had not been used in previous stable versions of Bitcoin Core. It will be included in release 32.0 with the fix, meaning this issue did not affect nodes running older official versions of the client.
Additionally, version 32.0 will reduce the disk space used by the transaction index (txindex) by over half after a complete rebuild. Existing indexes will remain compatible, but to achieve the space savings, they will need to be recreated.
As a reminder, in October 2025, developers released Bitcoin Core v30, which included a significant change by raising the default data limit in OP_RETURN outputs from 80 to 100,000 bytes.