BTC Security

Bitcoin Core 32 Hits Final Testing: Faster Blocks, Smarter Fees, and a Nasty Wallet Bug Fixed

2026-09-16

Bitcoin Core—the reference implementation that keeps the network honest—just entered its final testing phase this week with release candidate one. Target date: October 10. If you run a node or build on top of Core, this matters.

Version 32 isn't a protocol overhaul. No changes to consensus rules, no drama on that front. Older nodes carry on validating transactions exactly as they always have. What you're getting instead is a collection of practical improvements that make running a node less miserable and using Bitcoin more sensible.

Start with block processing. Bitcoin Core 32 lets nodes fetch transaction data in parallel using multiple threads instead of grinding through everything sequentially. Eight concurrent threads by default. The upshot? Block validation could speed up by three times in certain scenarios. It's addressing a real bottleneck that's plagued participants with varying hardware for ages—some people are waiting forever just for disk access to catch up.

Fee estimation gets a meaningful overhaul too. The software now runs two estimators at once: one tracking recent confirmed transactions, the other watching the mempool of unconfirmed data. Compare the two, and nodes can spot when the network uncongests and recommend lower fees far more quickly. Before, fee estimates would just linger at inflated rates even after congestion vanished. Small thing. Massive quality-of-life improvement.

The wallet side shifts to PSBT version 2 as the default for four Core commands. PSBT stands for partially signed transaction—the usual dance between wallet software and signing devices before your money actually moves. The old version had annoying constraints: you couldn't add inputs or outputs after the transaction was already started. Version 2 fixes that. Apps built around those Core commands need to support version 2 now, though they can still request the older format if they're stubborn.

Then there are the security fixes, and these warrant genuine attention.

On non-Windows systems, an authenticated user with wallet-creation permissions could potentially execute arbitrary commands if they named a wallet with special characters under the right conditions. The exploit required the node operator to have walletnotify enabled—a feature that runs a custom command whenever wallet transactions happen. Version 32 treats wallet names as literal text instead of parsing them for command components. Attack vector closed.

The second vulnerability lurked in Core's new web server. An unauthenticated attacker could trigger a memory exhaustion attack by accumulating client data faster than the server cleared it. Tests showed sixteen REST connections could consume 3.2 gigabytes in ninety seconds before the fix. After patching? Three megabytes. Catastrophic difference.

The project has given itself four weeks before the October 10 target. Node operators and application developers need time to test compatibility and raise hell if something's broken. History shows previous releases sometimes spawned additional release candidates if critical bugs surfaced during testing. Bitcoin Core maintains the discipline to delay if necessary.

Until release day, only bug fixes and security patches get merged. No new features creep in. The testing window is real.

Source & further reading:

Sources