Bitcoin Core, the primary software used to operate Bitcoin nodes, has advanced its next major version into final testing. Developers tagged the first release candidate for version 32.0 on September 14, initiating the last phase of checks before a planned stable release on October 10.

The update focuses on node performance, fee calculation, wallet interfaces and security without altering Bitcoin’s consensus rules. Node operators and developers who rely on the software for verification, wallets and related services are the primary users affected.

Fee Estimation Combines Mempool and Historical Data

Bitcoin Core currently calculates recommended transaction fees mainly from confirmation patterns observed in past blocks. Version 32 introduces a second estimator that examines transactions waiting in the node’s mempool.

When both estimators return valid results, the software selects the lower fee recommendation. This approach allows estimates to adjust more rapidly once network congestion eases, rather than continuing to incorporate higher fees from earlier blocks. Applications can still request the previous block-based method through a new option, and the combined default remains the standard for wallet fee calculations.

The mempool estimator stores its statistics separately so they persist across restarts. Higher verbosity levels also expose health data about the mempool for applications that require additional detail.

Parallel Prefetching Speeds Block Validation

Nodes validating blocks must retrieve previous transaction outputs, known as prevouts, to confirm that inputs exist, remain unspent and meet validation rules. Version 32 enables parallel prefetching of this data from the chainstate database across multiple worker threads while validation continues.

The default setting uses eight threads. Operators may increase the number to 16 or disable the feature. The change aims to reduce waiting time for disk reads when required data is not already held in faster caches. Performance gains depend on storage hardware, cache state and configuration.

Additional RPC updates improve visibility into AssumeUTXO background validation. After a snapshot-based node reaches the chain tip, getblockchaininfo can report progress on the ongoing historical chain check.

Security Fixes Address Wallet and Server Issues

Developers resolved a wallet-notification vulnerability present since version 24.0 on non-Windows systems. An authenticated RPC user permitted to create wallets could supply a specially crafted name containing replacement characters. When the -walletnotify feature was enabled, the name could trigger arbitrary commands with the privileges of the Bitcoin Core process.

Version 32 treats wallet names as literal text during notification handling. It also rejects certain relative-path names that include path elements such as “.” or “..”.

A separate issue involved the rewritten HTTP server that replaces libevent in this release. An audit identified a path that allowed continued reading and queuing of data from a client while an earlier request remained active, without an effective size limit. This created a memory-exhaustion condition.

Initial analysis pointed to authenticated clients, yet further testing showed unauthenticated REST connections produced the same effect. Sixteen such connections raised memory use from 46 MB to roughly 3 GB in about one minute on a test process. After the revised patch, the same test produced only about 3 MB of growth over 90 seconds. The fix was merged on September 5, before the release candidate was tagged.

PSBT Version 2 Becomes Default for Key Commands

Four commands used to create or convert Partially Signed Bitcoin Transactions—createpsbt, walletcreatepsbt, converttopsbt and psbtbumpfee—now default to PSBT version 2. An optional argument allows applications to request another supported version.

PSBTs enable multiple wallets, applications or hardware devices to exchange transaction data before final broadcast. Services built around the previous default format will need to confirm compatibility, though the older version remains available on request.

Additional wallet tooling includes a new exportwatchonlywallet RPC that produces a descriptor wallet file containing public descriptors, transaction history and address-book data without private keys. Further commands support derivation of extended keys along paths that include hardened steps and the addition of BIP32 extended keys without immediate script generation.

Testing Timeline and Upgrade Process

Feature freeze occurred on August 20. Developers then branched version 32.x and opened a dedicated testing-feedback issue on September 15. Testers are directed to follow the release-candidate guide and file separate reports for any defects.

Bitcoin Core does not update automatically. Operators decide when to install new versions, so older releases can continue running after newer software becomes available. The October 10 target for the final tag remains subject to the outcome of ongoing testing.

Version 32 continues maintenance of existing features such as PrivateBroadcast while introducing the performance, fee and security changes described above. Node operators and developers are encouraged to evaluate the release candidate in their environments before the stable version is issued.