Bitcoin Core 32.0 has entered its final release-candidate testing cycle after developers tagged v32.0rc1 on Sept. 14, bringing fee estimation, block-validation performance and security fixes
Bitcoin Core 32.0 has entered its final release-candidate testing cycle after developers tagged v32.0rc1 on Sept. 14, bringing fee estimation, block-validation performance and security fixes closer to a planned Oct. 10 release.
SummaryThe Bitcoin Core project’s official GitHub release shows v32.0rc1 at commit d0231bb, signed with a verified maintainer signature on Sept. 14 at 12:58 UTC. The project’s release schedule still targets Oct. 10 for the final v32.0 tag, although the date remains subject to testing and further fixes.
Version 32 focuses on node software behavior, wallet interfaces, fee calculation, networking and performance. The draft release notes do not list a change to Bitcoin’s consensus rules, meaning the update does not redefine which transactions or blocks the network considers valid.
Bitcoin Core 32.0 Enters Final Testing With Fee and Security Updates #BitcoinCore#Bitcoin#BTC#BlockchainSecurity#CryptoNewshttps://t.co/eSLjroVhp9
— Bitcoin World News (@BitcoinWorldN) September 16, 2026
You might also like: Bitcoin price targets $72.5K as Aroon favors sellers
Developers entered feature freeze on Aug. 20, limiting work to fixes needed before release. On Sept. 14, they split the 32.x branch from the main development branch and started the release-candidate cycle while development work for version 33 resumed separately.
The first candidate is intended for node operators, wallet developers and other users to test before developers decide whether the code is ready for a stable release. Bitcoin Core opened a dedicated 32.0 release-candidate testing feedback issue on Sept. 15, one day after RC1 was tagged.
The project asks testers to use the testing guide for RC-specific checks and report software problems through separate GitHub issues. No final v32.0 binary has been released as of Sept. 16.
Bitcoin Core does not update automatically. Operators choose when to install new versions, meaning older releases can remain active after newer software becomes available.
That manual upgrade model has mattered in previous security disclosures. As crypto.news previously reported, Bitcoin Core disclosed CVE-2024-52911 in May after the vulnerable 28.x branch reached end of life. The bug had already been fixed in Bitcoin Core 29.0 before technical details became public.
One of Bitcoin Core 32’s more visible user-facing changes affects estimatesmartfee, the RPC used by wallets and applications to calculate transaction fees.
Until now, Bitcoin Core’s main estimator has relied on observed confirmation behavior from transactions included in past blocks. Version 32 adds a separate estimator based on transactions currently waiting inside the node’s mempool.
The new mempool estimator produces both economical and conservative estimates from current pending transaction conditions. Bitcoin Core checks recent block activity before using it and can reject the estimate when the mempool appears too sparse or unhealthy.
When both systems produce valid results, estimatesmartfee returns the lower fee estimate. The new method therefore cannot push the existing block-policy recommendation higher through the combined default mode; its role is to lower the recommendation when current mempool conditions support doing so.
That design can respond more quickly after a period of expensive block space ends. A block-history estimator may continue incorporating recently confirmed high-fee transactions, while the mempool may already show fewer transactions competing for confirmation.
The software preserves a way for applications to use the previous method. An added fee_rate_estimator option lets users request block_policy, mempool_policy or the combined default behavior. Bitcoin Core stores the new mempool estimator’s statistics in a separate data file so they can be reloaded after restart.
Wallet fee calculations will use the combined default estimator. The response can identify which estimator produced the selected fee, while higher verbosity levels expose mempool-health statistics for applications that need more detail.
Bitcoin Core 32 changes how nodes retrieve transaction data while connecting blocks, particularly when the needed information must be read from storage.
The software can now prefetch previous transaction outputs, known as prevouts, from the chainstate database across several worker threads while block validation continues. The default is eight prefetch threads, with operators able to raise the setting to 16 or disable parallel fetching by setting it to zero.
Prevouts identify the coins being spent by transaction inputs. Nodes need that information to check whether inputs exist, have not already been spent and satisfy the applicable validation rules.
The improvement is intended to cut time spent waiting for disk reads when a node processes blocks containing inputs not already available in faster memory caches. The effect will vary with storage hardware, cache behavior and node configuration.
Bitcoin Core 32 exposes the setting through -prevoutfetchthreads=<n>, giving operators control over how many threads take part. The draft notes describe the feature specifically as a block-validation performance improvement.
Separate RPC changes give operators more information during AssumeUTXO background validation. After a snapshot-based node reaches the chain tip, getblockchaininfo can now report the progress of the historical chain validation still running behind the active node state.
Bitcoin Core 32 fixes a wallet notification flaw affecting non-Windows systems under a narrow set of conditions.
The draft notes state that an authenticated RPC user with permission to create wallets could craft a wallet name containing special replacement characters when the node was configured with -walletnotify. Under those conditions, the name could cause arbitrary commands to execute with the privileges of the Bitcoin Core process.
Version 32 changes wallet-notification placeholder replacement so wallet names are treated as literal text. The release tightens wallet naming as well by rejecting certain relative-path names containing . or .. path elements.
A second issue emerged during review of Bitcoin Core’s rewritten HTTP server, which is replacing libevent in version 32.
Developer Matthew Zipkin submitted pull request #36123 after an audit using Moonshot AI’s Kimi K3 model identified a memory-exhaustion path. While the server handled one request, it could continue reading and queuing data sent by the same connection without an effective size limit.
The first analysis suggested the condition mainly required an authenticated client capable of keeping a request busy. Further testing found that REST traffic created a similar problem without authentication.
A reviewer reported that 16 unauthenticated REST connections pushed one test process from 46 MB of memory to roughly 3 GB in around one minute. After the revised fix, the same test increased memory use by roughly 3 MB over 90 seconds, compared with 3.2 GB before the patch.
The patch was merged Sept. 5, before v32.0rc1 was tagged. Because the rewritten HTTP server is new to version 32, the specific flaw was caught before the server appeared in a stable Bitcoin Core release.
The use of Kimi K3 fits a recent pattern of AI-assisted security review across Bitcoin software. As crypto.news reported in August, Bitcoin Red Team had logged 7,958 potential findings after scanning hundreds of Bitcoin-related open-source projects, though many required human verification before they could be treated as confirmed vulnerabilities.
Resource-exhaustion problems have appeared in other Bitcoin software this year. In related coverage, crypto.news reported that Core Lightning confirmed security flaws after reviewing AI-generated reports and warned operators to upgrade or temporarily use offline mode.
Bitcoin Core 32 changes the default format created by four commands used with Partially Signed Bitcoin Transactions.
createpsbt, walletcreatepsbt, converttopsbt and psbtbumpfee will produce PSBT version 2 by default. Developers added an optional psbt_version argument so applications can explicitly request another supported version when necessary.
PSBTs let several wallets, applications or hardware signing devices exchange transaction information before the completed Bitcoin transaction is broadcast. Moving the default to version 2 may require testing by software that assumes Core’s RPC output will use the older format.
The update does not remove the ability to request the previous version. Applications built around the affected RPC commands can set the format explicitly while they test version 2 compatibility.
Wallet tooling receives other changes in the same release. A new exportwatchonlywallet RPC creates a descriptor-wallet file containing public descriptors, transaction history and address-book data without private keys. Bitcoin Core’s offline-signing tutorial now uses that command for creating an online watch-only wallet.
Another new command, derivehdkey, lets a wallet derive an extended public or private key through a path containing at least one hardened step, while addhdkey lets a BIP32 extended key be added without immediately using it to generate output scripts.
PrivateBroadcast receives continued maintenance as well. Crypto.news reported in June that Bitcoin Core 31.1rc1 fixed a network condition that could expose an originating IP address when PrivateBroadcast was used. Version 32 contains further PrivateBroadcast RPC and transaction-relay changes documented in its draft release notes.
The current Bitcoin Core schedule still lists Oct. 10 as the target for tagging v32.0. The RC testing feedback thread opened Sept. 15 remains active, with developers directing testers who find actual Bitcoin Core defects to file separate issues before the final release.
Read more: Ethereum price recovery hinges on $2,526 breakout
