Bitcoin full-node computer processing parallel transaction blocks in a yellow-orange studio scene

Bitcoin Core 32 Enters Final Testing With Faster Validation and Security Fixes

By Isaac • September 16, 2026 7:09 pm • Comments

Bitcoin Core 32 has entered its final testing stretch, putting a faster block-validation path, updated fee estimates and several security fixes in front of node operators before the planned October release.

The release candidate matters because Bitcoin Core is the software many operators use to independently verify the Bitcoin network. It does not make Bitcoin produce blocks faster or change the network’s consensus rules.

Instead, it aims to make the work performed by individual nodes more efficient and resilient.

Trending: 25-Cent Deposit Let an Attacker Mint 46.1 Billion Fake Bitcoin Tokens

Decrypt reports that Bitcoin Core 32.0 entered release-candidate testing this week, with developers targeting October 10 for the finished version while acknowledging that testing could move the date. Its review of the draft release notes identifies parallel database reads for block checks, a newer Partially Signed Bitcoin Transaction format for four wallet commands, a fix for crafted wallet names interacting with walletnotify, and a separate patch for excessive memory use in the new HTTP server.

The report also traces the HTTP issue from an authenticated-client concern to a broader REST-interface finding: a reviewer found that unauthenticated connections could cause memory growth when REST was enabled, and the revised patch reduced reported growth from gigabytes to only a few megabytes in the cited test. Together, those details make this more than a routine version bump; they show why the release-candidate window exists and what node operators should try to break before the stable build ships.

The most visible performance change is parallel fetching of transaction outputs needed during block validation. When a node checks a new block, it must look up the earlier outputs being spent by the block’s transactions.

Those disk reads previously happened one after another when the data was not already cached.

The merged Bitcoin Core pull request explains that version 32 can start those reads across a pool of worker threads while block connection continues. Eight fetching threads are enabled by default, with operators able to change or disable the setting.

The underlying validation rules stay the same; the practical improvement is about reducing time lost waiting on storage.

The update also closes a wallet-notification flaw that could allow crafted wallet names to trigger commands under a narrow configuration. The affected setup required an authenticated user to create wallets on a non-Windows node where walletnotify was configured to execute commands.

The fix is especially relevant to operators who expose authenticated wallet services and use notification hooks.

A separate fix addresses excessive memory consumption in Bitcoin Core’s newer HTTP server. Testing found that unauthenticated connections could drive memory growth when the REST interface was enabled.

The revised patch sharply reduced that growth in the reported test case.

Bitcoin Core 32 also moves four wallet commands to Partially Signed Bitcoin Transaction version 2 by default. PSBTs let wallets and signing devices coordinate a transaction without exposing private keys.

Applications that still need the older format can request it explicitly.

The release candidate also changes how the wallet estimates transaction fees. Rather than relying only on historical confirmation behavior, the newer estimator can use the current mempool as another signal.

That should help recommendations reflect the transaction backlog operators can see now, while still avoiding the false precision of treating any fee estimate as a guarantee.

The broader Bitcoin market entered the testing period with stronger spot demand and exchange-traded fund flows, according to a late-August market update shared by Bitcoin Magazine. More capital moving through Bitcoin gives exchanges, wallets and node operators another reason to test infrastructure changes carefully.

The sensible next step is testing, not assuming the release candidate is already the final release. Operators who can safely run a non-production test node can compare synchronization, block connection, wallet behavior and application compatibility on their own hardware.

Any defect should be reported through the project’s issue process rather than worked around silently.

The 32.0rc1 preparation record shows that the version-bump work opened and merged on September 14 after maintainer review, build checks and a formatting correction. The change generated the release files, updated the version to 32.0rc1, pointed users to the draft release notes and incorporated a small build-header fix after continuous integration exposed it.

That record is useful because it separates a signed release-candidate checkpoint from a finished stable release, while showing exactly what maintainers reviewed at the branch boundary. It gives the Bitcoin Core community several weeks to test packaging, synchronization, wallet calls and integrations before the planned October release, and it leaves a public trail for any defect that forces another candidate.

For everyday Bitcoin holders, there is no urgent action tied to the release candidate. For node operators and services built on Bitcoin Core, however, version 32 is a substantial maintenance release: faster work where storage has been a bottleneck, fresher fee inputs, safer wallet hooks and a hardened HTTP path.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.

 

Search ProCoinNews