Bitcoin Core 32.0 has entered final testing ahead of a planned October 10, 2026 release, bringing practical improvements to fee estimation, block validation, wallet compatibility and node security without changing Bitcoin’s consensus rules or monetary policy.
A maintenance release with broad operational impact
The update is the next major version of the software used by a large share of Bitcoin’s independently operated nodes. It will not change the maximum block size, total supply, issuance schedule or rules that determine whether blocks and transactions are valid. Instead, Core 32 is aimed at the infrastructure layer, where small improvements can affect exchanges, wallet providers, miners, developers and individuals running their own nodes.
That focus makes the release less dramatic than a consensus change, but potentially more useful in daily operations. Bitcoin’s reliability depends on thousands of independently managed computers validating the same history. Their ability to process blocks, estimate transaction fees and resist attacks directly affects how efficiently users interact with the network.
Developers moved Core 32 into final testing on September 14. The testing period is intended to identify regressions before the stable version is made available to node operators and businesses that depend on predictable software behavior.
Fee estimates respond faster to changing conditions
One of the most visible changes concerns fee estimation. Bitcoin Core has traditionally estimated fees by examining transactions that were recently confirmed in blocks. That approach provides a useful record of what users had to pay, but it can remain influenced by earlier congestion even after the mempool begins to clear.
The mempool is the holding area for valid transactions that have been received by nodes but have not yet been included in a block. Core 32 adds a second estimation model that observes transactions still waiting there. When the available data supports it, the software can use the lower of the two estimates.
In practical terms, suggested fees could fall sooner after a period of heavy demand. A wallet that relies on Core’s recommendations may avoid continuing to suggest fees based on expensive blocks after network conditions have improved. That could reduce unnecessary costs for users and make fee guidance more responsive during rapidly changing periods of activity.
The change is not a promise that every transaction will confirm cheaply or quickly. Fees still depend on demand, transaction size and the user’s preferred confirmation time. Its importance is that wallets and other applications can make decisions using a more current view of the market for block space.
Faster validation for nodes catching up
Core 32 also targets the time required for a node to validate the blockchain. The software will allow transaction data to be retrieved from disk using multiple processing threads during block validation. Eight threads will be used by default.
Disk access can become a bottleneck when a node is downloading and checking a large number of historical blocks. By processing more reads concurrently, the update may reduce the time needed for a new or offline node to catch up with the chain. Faster synchronization lowers the operational burden for businesses and users that want to verify Bitcoin transactions independently rather than relying on third party infrastructure.
The improvement is especially relevant as the blockchain grows. A node that can complete initial synchronization more efficiently is easier to deploy, restore and maintain. That supports a wider distribution of validation power, which is central to Bitcoin’s resilience.
Wallet security issue receives long overdue fix
The strongest security news involves a vulnerability present since Core 24.0 on non Windows systems. Under specific conditions, an authenticated user who was able to create wallets could use a specially constructed wallet name to cause commands to execute on the machine running the node.
Exploitation required the operator to have enabled the walletnotify feature, which allows the node to trigger an external command when wallet related events occur. That requirement limited the circumstances in which the flaw could be used, but the potential impact remained serious because command execution can expose the host system to further compromise.
Core 32 changes wallet name handling so names are treated as literal text rather than being interpreted in a way that could alter command behavior. Operators should still review access controls and notification settings, particularly on nodes exposed to other users or connected to business systems.
A separate audit of Core’s new web server identified a memory exhaustion issue before the server reached a stable release. A client could send data faster than the server cleared it, causing memory use to climb continuously. Testing showed that 16 unauthenticated REST connections could increase a node’s memory consumption from 46 megabytes to about 3 gigabytes in roughly one minute.
After the fix, a comparable 90 second test used about 3 megabytes instead of 3.2 gigabytes. Finding and correcting the issue before a stable launch highlights the value of security reviews for infrastructure components that can accept network requests.
PSBT version 2 becomes the default
Core 32 will also make PSBT version 2 the default for four commands that create partially signed Bitcoin transactions. PSBTs allow different participants, such as a wallet, exchange or hardware device, to coordinate signing without sharing private keys.
The default change means wallet services and hardware signing workflows that call those commands should verify compatibility. The adjustment is part of Bitcoin’s gradual protocol maintenance, improving the format used by transaction signing systems while preserving the network’s underlying consensus rules.
Taken together, the release shows how Bitcoin’s next stage of development is being shaped by execution rather than headline features. Better fee signals, faster validation, safer command handling and improved signing compatibility address the practical systems that users and companies depend on every day.
This article was written with the assistance of an AI system and published automatically.