Bitcoin Core 32.0 Enters Final Testing Ahead of October Target

Bitcoin Core 32.0 is approaching stable release after moving into its final release-candidate testing cycle, with developers aiming to tag the finished version on October 10. According to the project’s official Bitcoin Core 32.0 release schedule, the 32.x branch was separated from master on September 14 and the latest available test build is RC3, published October 6. The October 10 date remains a target rather than a guaranteed release deadline.

The update is focused primarily on node operation, wallet tooling, networking and performance rather than introducing new Bitcoin consensus rules. Its draft release notes include changes to fee estimation, block validation, PSBT handling, HTTP infrastructure and wallet security. Bitcoin Core 32.0 is therefore a major software release without being a protocol activation or soft fork. That distinction mirrors earlier releases such as Bitcoin Core 30.0, where lower relay-fee defaults changed node policy without changing consensus.

New Fee Estimator Reacts to Current Mempool Conditions

One of the most significant wallet changes is a second fee-rate estimator based on the current mempool. Bitcoin Core previously relied principally on historical block-confirmation behavior when estimating what fee was needed for a target confirmation window. Version 32.0 combines that existing block-policy estimator with a new mempool-policy model. The new estimator can lower recommendations more quickly when current network conditions have become cheaper than recent blocks imply.

The implementation is deliberately conservative. The mempool estimator only produces a recommendation when recent blocks indicate that the mempool is healthy, and it falls back to relay or mempool minimums when transaction activity is too sparse. estimatesmartfee then returns the lower result from the two estimators in its default auto mode. Operators can still explicitly select the legacy block-policy model or query the mempool model independently. The change can reduce overpayment after congestion fades, but it does not guarantee a transaction will confirm at the resulting fee rate.

The feature builds on fee-policy changes introduced in Bitcoin Core 30.0, when the default minimum relay floor dropped to 0.1 sat/vB. Lower relay fees already expanded the range of transactions nodes could propagate, while the 32.0 estimator changes how wallets decide what to pay within that environment. Network conditions remain particularly relevant as Bitcoin transaction activity has periodically approached record levels. Relay policy and wallet fee estimation are related operational layers, but neither dictates a network-wide mandatory fee.

Block Validation Gains Parallel Database Reads

Bitcoin Core 32.0 also introduces parallel prefetching of transaction prevouts while nodes connect blocks. A new -prevoutfetchthreads setting allows the node to retrieve required chainstate data using multiple worker threads, with eight enabled by default and a maximum of 16. The optimization targets periods when block validation is waiting on disk reads, allowing storage access to occur concurrently rather than sequentially. Operators can disable the feature by setting the thread count to zero.

This should be described as a node-performance optimization rather than a throughput increase for Bitcoin itself. Faster local database access may improve synchronization and block-validation performance on suitable hardware, but it does not increase Bitcoin’s block size, transaction capacity or consensus throughput. The benefit depends on storage performance and whether disk access is actually the bottleneck for the node.

Another storage change reduces the disk footprint of the transaction index. A fully rebuilt -txindex takes less than half the previous space under the new format, although existing indexes must be rebuilt to obtain the saving. These changes reduce node resource requirements without modifying the data Bitcoin nodes ultimately validate.

PSBT v2 Becomes the Default

Bitcoin Core is also changing the default format produced by four PSBT-related RPCs. createpsbt, walletcreatefundedpsbt, converttopsbt and psbtbumpfee will now create PSBT version 2 by default, while a new psbt_version argument lets applications explicitly request another supported version.

PSBTs are coordination containers for transactions that still require signatures or additional metadata, making them important for hardware wallets, multisig systems and offline signing. The switch does not invalidate PSBT v0, but software that assumes Core will always generate the older format may need compatibility testing before upgrading. Bitcoin Core’s documentation continues to describe PSBT as an interchange format for cooperative transaction construction rather than a new transaction type on the Bitcoin network.

The release also fixes a wallet-notification security issue affecting non-Windows systems. When -walletnotify was configured, an authenticated RPC user with permission to create wallets could craft a wallet name containing replacement characters that were interpreted during command substitution. Version 32.0 now treats wallet names literally, closing a path that could otherwise allow commands to run with the privileges of the Bitcoin Core process.

Separately, Bitcoin Core 32.0 replaces libevent with a custom HTTP server and introduces -rpcmaxconnections, which defaults to 16 simultaneous HTTP clients. The new implementation also applies stricter header parsing and request handling. These HTTP changes are part of the 32.0 software architecture itself and should not be conflated with vulnerabilities in earlier production releases.

Bitcoin Core developers are still asking operators and integrators to test RC3 across supported platforms before the stable tag. The meaningful milestone is therefore not October 10 alone, but whether the current release candidate completes testing without issues significant enough to delay or alter the final build. The feature set is already largely frozen; what remains is validating that the operational improvements work reliably across the diverse environments in which Bitcoin Core nodes run.