On September 14, the Bitcoin Core team released the first release candidate, v32.0rc1. The update will modify the fee estimation mechanism, speed up block validation when reading data from disk, and fix a walletnotify vulnerability. This issue affects only certain configurations and requires authenticated RPC access, according to the official schedule and the draft release notes.
The stable Bitcoin Core 32.0 is scheduled for release on October 10. The published release notes indicate no changes to Bitcoin’s consensus rules, focusing instead on client software updates.
Fee Estimation to Consider Mempool State
In Bitcoin Core 32.0, the team will modify the estimatesmartfee function, which helps determine the transaction fee for confirmation within a specified number of blocks. Currently, the block_policy estimator, based on confirmed transaction data, is used; the new version will add mempool_policy, which analyzes the current state of the mempool.
By default, the client will use both algorithms and return the lower estimate. This new mechanism can reduce the recommended fee after a load decrease but will not increase it beyond the block_policy result.
Users can explicitly choose one of the algorithms via the fee_rate_estimator parameter. If the new estimator lacks sufficient data, it will return an error. This can occur, for example, while the mempool is loading, after receiving an insufficient number of fresh blocks, or if its state is deemed unsuitable for reliable estimation.
Developers have also added parallel prefetching of transaction output data (prevouts) during block verification. By default, Bitcoin Core will use eight threads, with a maximum of 16. The parameter -prevoutfetchthreads=0 will disable the feature.
This change should speed up block validation, especially when necessary data must be read from disk. If the data is already in memory, the effect will be less significant.
Another change will affect partially signed Bitcoin transactions (PSBT). The commands createpsbt, walletcreatepsbt, converttopsbt, and psbtbumpfee will default to creating PSBT version 2. Users can select a different version via the psbt_version argument if needed.
Developers Address Vulnerability
Bitcoin Core 32.0 also fixes a vulnerability present since version 24.0. It affected non-Windows systems using the -walletnotify parameter with the %w placeholder. This setting allows a user-defined command to be automatically executed when a wallet-related transaction occurs.
An authenticated RPC user with wallet creation rights could set a specially crafted name. Upon subsequent transaction notification, characters within the name could disrupt shell escaping and, with an appropriate walletnotify template, execute an additional command under the Bitcoin Core process.
The issue arose because the ReplaceAll() function passed the escaped wallet name to std::regex_replace() as replacement text. Developers have modified the mechanism to treat the name literally.
The vulnerability could not be exploited through a standard P2P connection or without authorization. An attack required simultaneous 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 includes a fix for another security issue discovered during an audit of the new HTTP server using Kimi K3. If the server was already processing a request, a client could continue sending data without volume restriction. Under certain conditions, this allowed uncontrolled memory consumption by the process.
Developers have prohibited the server from reading new data from the socket while the previous request is still being processed. In this case, incoming flow is limited by TCP mechanisms. The most realistic exploitation scenario also required an authenticated client.
The new HTTP server has not been used in previous stable versions of Bitcoin Core. It will be included in the 32.0 release with the fix, so this issue did not affect nodes on earlier official client versions.
Additionally, version 32.0 will reduce the disk space required for the transaction index txindex by more than half after a complete rebuild. Existing indexes will remain compatible, but to achieve the savings, they will need to be recreated.
In October 2025, developers released Bitcoin Core v30. One of the key changes was increasing the default data limit in OP_RETURN outputs from 80 to 100,000 bytes.
