Bitcoin Core 32.0 is moving closer to release, with developers entering the final release-candidate testing phase after tagging version 32.0rc1 on Sept. 14.
The update introduces several important changes, including smarter transaction fee estimation, faster block validation, improved wallet tools and security fixes.
Developers are currently targeting Oct. 10 for the final Bitcoin Core 32.0 release, although that date could still change if testing uncovers additional problems.
Bitcoin Core 32 enters final testing phase
Bitcoin Core developers entered feature freeze on Aug. 20, meaning new features were largely stopped while the team focused on fixing issues ahead of release.
On Sept. 14, developers separated the 32.x branch from the main development branch and began formal release-candidate testing.
The first release candidate is designed for node operators, wallet developers and other technical users who want to test the software before the final version is published.
Bitcoin Core opened a dedicated testing feedback thread on Sept. 15.
As of Sept. 16, no final Bitcoin Core 32.0 binary had been released.
Bitcoin Core also does not update automatically. Node operators decide when they want to install a newer version, so older releases can continue running even after Bitcoin Core 32 becomes available.
New fee estimator could lower Bitcoin transaction fees
One of the most noticeable changes in Bitcoin Core 32 involves transaction fee estimation.
Wallets and applications commonly use the estimatesmartfee RPC to calculate how much users should pay to get their transactions confirmed within a certain period.
Previously, Bitcoin Core’s main fee estimator relied mainly on historical data from transactions that had already been confirmed in blocks.
Version 32 adds another estimator that looks at transactions currently waiting in the mempool.
The mempool is the pool of unconfirmed Bitcoin transactions waiting to be included in future blocks.
By analyzing current mempool conditions, Bitcoin Core can react more quickly when network congestion decreases.
For example, historical block data may still reflect a period when transaction fees were unusually high. If the mempool has already become less crowded, the new estimator could recognize that change sooner.
When both the historical and mempool-based systems provide valid estimates, Bitcoin Core selects the lower recommendation.
This means the new system is designed to potentially reduce fee recommendations rather than increase them through the combined default mode.
Users and applications can also choose between block-history estimates, mempool estimates or the combined default behavior.
Bitcoin Core 32 speeds up block validation
The new release also introduces an important performance improvement for Bitcoin nodes.
Bitcoin Core 32 can now fetch previous transaction outputs, known as prevouts, using several worker threads while block validation is running.
Prevouts contain information about the Bitcoin being spent in a transaction.
Nodes must check this information to confirm that transaction inputs exist, have not already been spent and meet Bitcoin’s validation rules.
By default, Bitcoin Core 32 uses eight worker threads for this process.
Operators can increase the number to 16 or disable parallel prefetching entirely.
The goal is to reduce the amount of time nodes spend waiting for information to be read from storage.
The actual performance improvement will depend on factors such as storage hardware, cache configuration and the node’s overall setup.
For users running Bitcoin Core on hardware where disk access is a major bottleneck, this change could make block processing more efficient.
Security fix closes wallet command-execution flaw
Bitcoin Core 32 also fixes a wallet notification issue affecting non-Windows systems under specific conditions.
The vulnerability involved the -walletnotify configuration option.
An authenticated RPC user with permission to create wallets could potentially create a specially crafted wallet name containing replacement characters.
Under vulnerable configurations, this could cause commands to execute with the same privileges as the Bitcoin Core process.
Version 32 changes how wallet-notification placeholders are handled so wallet names are treated as literal text.
The update also strengthens wallet naming rules by rejecting certain path-related names that contain . or .. elements.
The issue required authenticated RPC access and a specific configuration, which limited the circumstances under which it could be exploited.
HTTP server memory issue fixed before stable release
Another important security issue was discovered during testing of Bitcoin Core’s rewritten HTTP server.
The new HTTP implementation is expected to replace libevent in version 32.
During security review, developers discovered that a connection could continue sending and queuing large amounts of data while the server was still processing another request.
This created a potential memory-exhaustion problem.
Initial analysis suggested the issue might mainly affect authenticated clients.
Further testing, however, showed that unauthenticated REST connections could also trigger the problem.
In one reported test, 16 unauthenticated REST connections pushed memory consumption from around 46 MB to roughly 3 GB in approximately one minute.
After developers applied the fix, the same test reportedly increased memory usage by only around 3 MB over 90 seconds.
The patch was merged on Sept. 5, before Bitcoin Core 32.0rc1 was tagged.
Because the rewritten HTTP server is new to version 32, developers were able to catch and fix the issue before it appeared in a stable Bitcoin Core release.
AI-assisted security review helped identify the issue
The HTTP memory problem was discovered after an audit using Moonshot AI’s Kimi K3 model identified a potential vulnerability.
The finding was then investigated and verified by human developers.
AI-assisted code review has become more visible across Bitcoin-related open-source development.
However, AI-generated findings still require human verification because automated security tools can produce false positives or misunderstand how code behaves in real-world conditions.
The Bitcoin Core case demonstrates how AI tools can help identify areas worth investigating while experienced developers remain responsible for confirming and fixing actual vulnerabilities.
PSBT version 2 becomes the new default
Bitcoin Core 32 also changes the default format for several commands related to Partially Signed Bitcoin Transactions.
Four RPC commands will now create PSBT version 2 by default:
createpsbtwalletcreatepsbtconverttopsbtpsbtbumpfee
PSBTs allow multiple wallets, hardware devices or applications to exchange transaction information before a Bitcoin transaction is fully signed and broadcast.
Applications that rely on the older PSBT format may need additional testing after upgrading to Bitcoin Core 32.
Developers have added a psbt_version option so applications can explicitly request another supported format if necessary.
This means the older format has not been removed.
New wallet tools improve offline and watch-only setups
Bitcoin Core 32 includes several additional wallet improvements.
A new exportwatchonlywallet RPC allows users to create a descriptor wallet file that contains public information without private keys.
The exported file can include public descriptors, address-book data and transaction history.
This can be useful for setups where users want an online watch-only wallet while keeping private keys on an offline device.
Bitcoin Core’s offline-signing documentation now uses this feature as part of its recommended workflow.
Another command, derivehdkey, allows wallets to derive extended public or private keys through paths containing hardened derivation steps.
The new addhdkey command also allows BIP32 extended keys to be added to a wallet without immediately using them to generate output scripts.
PrivateBroadcast continues to receive improvements
Bitcoin Core 32 also includes further updates to PrivateBroadcast.
PrivateBroadcast is designed to improve transaction privacy by reducing the chance that an observer can identify the originating node of a Bitcoin transaction.
Earlier releases addressed a network condition that could expose the sender’s IP address in certain situations.
Version 32 includes additional RPC and transaction-relay changes related to the feature.
These updates form part of Bitcoin Core’s broader effort to improve privacy and transaction propagation without changing Bitcoin’s underlying consensus rules.
Bitcoin Core 32 does not change Bitcoin consensus
Despite the number of improvements included in version 32, the update does not introduce a change to Bitcoin’s consensus rules.
That means Bitcoin Core 32 does not redefine which transactions or blocks the network considers valid.
Instead, the release focuses primarily on node performance, wallet functionality, fee estimation, networking, security and developer tools.
This distinction is important because Bitcoin Core software updates can improve how nodes operate without changing the fundamental rules followed by the Bitcoin network.
What Bitcoin Core 32 means for users
Bitcoin Core 32 is shaping up to be a significant operational update for node operators, wallet developers and businesses building around Bitcoin.
The new fee estimator could help wallets respond more quickly to changing network conditions and potentially avoid unnecessarily high transaction fees.
Parallel prevout fetching could improve block-validation performance, particularly for nodes where storage access creates delays.
Meanwhile, the security fixes address vulnerabilities discovered before the new HTTP server reaches a stable Bitcoin Core release.
The move to PSBT version 2 and new wallet RPC commands also give developers more tools for advanced signing and watch-only wallet setups.
Developers are still targeting Oct. 10 for the final Bitcoin Core 32.0 release, but release-candidate testing remains ongoing.
Until that process is complete, additional fixes could still be introduced before the final version is tagged.
