Bitcoin’s software backbone is getting its biggest tune-up in months, and this time the focus is squarely on speed and safety. The latest Bitcoin Core update, version 32.0, has moved into release-candidate testing after developers tagged v32.0rc1 on September 14, 2026, with the finished software expected around October 10, 2026. For the thousands of node operators, wallet developers, and exchanges that rely on Bitcoin Core to verify transactions independently, this release brings faster block checking, a smarter fee estimator, and two security patches that had quietly been sitting in the software’s newer components.
Key takeaways
- Bitcoin Core 32.0 entered release-candidate testing after developers tagged v32.0rc1 on September 14, 2026, with a final release targeted for October 10, 2026.
- The update speeds up block verification by reading database information across eight parallel worker threads by default, without changing how fast Bitcoin produces blocks.
- Four wallet commands now default to the newer PSBT version 2 format for partially signed transactions, while older formats remain available on request.
- Developers patched a wallet-naming flaw that could trigger unwanted commands on non-Windows nodes, plus a memory-exhaustion bug in the new HTTP server merged on September 5, 2026.
- The fix cut unauthenticated memory growth from roughly 3.2 GB down to about 3 MB over a 90-second test window.
Bitcoin Core 32.0 Enters Release-Candidate Testing
Bitcoin Core 32.0 is now in its final testing window before a scheduled stable release. Developers tagged the first release candidate, v32.0rc1, on September 14, 2026, and the project’s release schedule still points to October 10, 2026, as the target date for the finished version, though that timeline could shift depending on what testers find. This particular Bitcoin Core update does not touch Bitcoin’s consensus rules, meaning it changes how the software behaves without altering which transactions or blocks the network treats as valid.
Bitcoin Core is the software that lets a computer check Bitcoin transactions and blocks against the network’s rules on its own, rather than trusting another party’s word for it. Developers entered a feature freeze in late August, limiting changes to fixes needed before release, then split the 32.x branch from the main development line once the release candidate went out. The project also opened a dedicated feedback thread for testers the day after the candidate was tagged, asking node operators, wallet developers, and other users to flag problems before the software locks in for a stable release.
Performance Improvements in Block Verification
The headline performance change in this release is a parallel way of pulling data from disk while a node checks blocks. Bitcoin Core 32 can now fetch previous transaction outputs, called prevouts, from its chainstate database using multiple worker threads at once instead of one at a time. The default is eight threads, though operators can push that up to 16 or turn parallel fetching off entirely through a new setting.
Nodes need those prevouts to confirm that the coins being spent actually exist and haven’t already been used elsewhere. By spreading that database work across several threads, the update cuts down the time a node spends waiting on disk reads, which matters most for machines still catching up with the blockchain or running on slower storage. Crucially, this change speeds up how quickly a node verifies blocks already in existence without touching how fast new blocks get produced in the first place.
Version 32 also reworks how Bitcoin Core estimates transaction fees. Until now, the software’s main estimator has leaned almost entirely on the fees attached to transactions that made it into recent blocks. The update adds a second estimator that looks instead at what’s currently sitting in the mempool, the pool of unconfirmed transactions waiting to be included in a block. When both methods produce valid numbers, the software defaults to recommending the lower of the two, which should let fee estimates drop faster once network congestion clears rather than lagging behind on pricier historical data. Applications that prefer the old approach can still request it directly through a new configuration option.
Wallet Functionality Updates
PSBT Version 2 Becomes the New Default
Four wallet-related commands, createpsbt, walletcreatepsbt, converttopsbt, and psbtbumpfee, will now produce the newer PSBT version 2 format by default. Partially Signed Bitcoin Transactions, or PSBTs, are how wallets, applications, and hardware signing devices pass transaction data back and forth before a payment gets broadcast to the network. Moving these four commands to the newer standard is meant to modernize how that handoff works across the ecosystem.
Backward compatibility hasn’t disappeared, though. Applications that still expect the older PSBT format can explicitly request it through an added version parameter, giving developers time to test their systems against version 2 without breaking existing setups overnight. The release also adds a few smaller wallet tools, including a command that exports a watch-only wallet file containing public data and transaction history without exposing private keys.
Critical Security Fixes in Bitcoin Core 32.0
Two security patches stand out in this release, and both were caught before they could cause real-world damage. Together they reflect the kind of quiet, ongoing hardening work that keeps Bitcoin node vulnerabilities from turning into bigger problems once software ships broadly.
Wallet Name Exploit Patched on Non-Windows Systems
Non-Windows systems running Bitcoin Core have carried this particular flaw since version 24.0 was released. When granted wallet-creation rights, an authenticated user was able to assign a specially crafted name that included special replacement characters. If the node was also configured with the walletnotify feature, which automatically runs a chosen command whenever a wallet transaction occurs, that crafted name could trigger unwanted commands to execute on the computer hosting the node. Bitcoin Core 32 closes the gap by treating wallet names strictly as literal text and by rejecting wallet names that contain certain relative-path elements. This is a meaningful piece of Bitcoin wallet security hardening, even though the attack required a fairly specific configuration to work in the first place.
Memory Exhaustion Bug Fixed in New HTTP Server
The second, more involved fix targets Bitcoin Core’s rewritten HTTP server, the component that handles requests from other applications connecting to a node and which is replacing the older libevent-based server in version 32. Contributor Matthew Zipkin, posting as pinheadmz, submitted the patch after auditing the new server with Moonshot AI’s Kimi K3 model, the same AI tool used by the Bitcoin Red Team to hunt for vulnerabilities across Bitcoin software. The audit found that the server could keep accepting data from a single connection while still processing an earlier request, letting memory pile up faster than the server could clear it.
Zipkin’s initial assessment limited the risk to authenticated clients capable of keeping a request active. But during review of the patch, GitHub user jeanpablojp discovered that unauthenticated requests through Bitcoin Core’s REST interface could trigger the same memory growth, meaning no login credentials were required to exploit it. One test showed 16 unauthenticated REST connections driving a node’s memory use from 46 MB to roughly 3 GB in about a minute. After the revised fix, a 90-second version of the same test increased memory use by only about 3 MB, compared with 3.2 GB before the patch existed.
The fix was merged on September 5, 2026, ahead of the release-candidate tag, which meant this particular flaw never actually appeared in a stable Bitcoin Core release. That timing matters: because the rewritten HTTP server hadn’t shipped yet, the bug was caught during internal review rather than after it reached production nodes.
Context: Related Security Patches in the Bitcoin Ecosystem
Bitcoin Core’s fixes arrive alongside a broader pattern of security patches Bitcoin Core and adjacent software have needed in recent weeks. Bitcoin’s software layer is a patchwork of independently maintained projects, and vulnerabilities in one piece can matter just as much to users as flaws in the core validation software itself.
Hardware Wallets and Lightning Software Face Their Own Fixes
Hardware-wallet maker BitBox patched two severe firmware vulnerabilities in August, and the company reported no evidence that either flaw had actually been exploited before the fix went out. Separately, developers behind the Lightning payment software Core Lightning confirmed security vulnerabilities of their own after reviewing AI-generated bug reports, and warned node operators to upgrade or switch to offline mode while fixes were prepared. Together with the Bitcoin Core patches, these cases point to AI-assisted auditing tools becoming a more routine part of how Bitcoin’s software ecosystem checks itself for weaknesses before problems reach live networks.
FAQ
When is the final release of Bitcoin Core 32.0 expected?
Developers aim to release Bitcoin Core 32.0 around October 10, 2026, though the timeline could change depending on testing.
What improvements does Bitcoin Core 32.0 bring to block verification?
It speeds up block verification by reading database information in parallel across multiple worker threads without affecting block production speed.
What security issues are addressed in Bitcoin Core 32.0?
The update fixes a vulnerability where crafted wallet names could trigger commands on non-Windows nodes and patches a memory exhaustion bug in the new HTTP server that affected authenticated and unauthenticated clients.
What changes were made to wallet commands in Bitcoin Core 32.0?
Four wallet commands now default to the newer PSBT version 2 format for partially signed transactions while maintaining backward compatibility, allowing older versions when requested.
Article produced with the assistance of artificial intelligence and reviewed by the editorial team.