What to Know

  • Bitcoin Core 32.0 entered final testing on Sept. 14.
  • The finished release is scheduled for Oct. 10.
  • The update does not change Bitcoin’s consensus rules.
  • Version 32 adds a second fee estimator that looks at transactions currently waiting to be confirmed.
  • Bitcoin Core can recommend the lower fee when current network conditions support it.
  • Nodes will be able to fetch transaction data using several processing threads at once while checking blocks.
  • Bitcoin Core will use eight processing threads by default for that database-fetching work.
  • Developers fixed a command-execution vulnerability affecting certain wallet configurations on non-Windows systems.
  • The wallet issue had existed since Bitcoin Core 24.0.
  • Four wallet commands used to create partially signed transactions will default to PSBT version 2.
  • A memory-exhaustion flaw in the new web server was caught before the stable release.
  • Testing showed sixteen unauthenticated REST connections could move one node from 46 MB of memory to about 3 GB in roughly a minute before the fix.

Bitcoin Core 32 Moves Toward Release

Bitcoin Core 32.0 has entered its final testing phase, putting the most widely recognized Bitcoin node software on track for a scheduled finished release on Oct. 10. The first release candidate was tagged on Sept. 14, opening the final window for developers, node operators and technical reviewers to test the package before it is considered stable.

The update is important because Bitcoin Core is the software many users rely on to independently verify Bitcoin transactions and blocks. Running a node allows a computer to check activity against Bitcoin’s rules without depending on a third-party service. That verification role is central to Bitcoin’s decentralized design, because the network’s integrity depends on many independent participants enforcing the same rule set.

For users watching the update closely, one point stands above the rest: Bitcoin Core 32 does not change Bitcoin’s consensus rules. The release focuses instead on how nodes estimate fees, how they process block data, how wallets format certain transaction workflows and how the software handles security issues found before release.

Fee Estimation Gets a More Current View of the Mempool

One of the most practical changes in Bitcoin Core 32 is the addition of a second transaction fee estimator. Bitcoin Core currently estimates what a user should pay largely by looking at fees attached to transactions that were included in previous blocks. That historical method can be useful, but it may also lag behind the present state of the network when congestion clears quickly.

Version 32 adds an estimator that looks at transactions currently waiting to be confirmed. Those pending transactions sit in the mempool, the pool of valid but unconfirmed transactions seen by a node. By using that real-time view alongside historical block data, the software can compare the two approaches and may recommend the lower fee when current network conditions support it.

That matters because Bitcoin fees can shift sharply when demand for block space rises or falls. When congestion eases, users do not always want their wallets to continue pricing transactions based on more expensive activity from earlier blocks. The newer method is intended to help fee estimates fall more quickly when the network environment improves, while still keeping the software grounded in observed transaction behavior.

The change does not guarantee that every user will pay less for every transaction. Fee markets remain dynamic, and the right fee depends on how quickly a transaction needs confirmation, what other users are bidding for block space and how wallet software chooses to apply available estimates. Still, technical traders, wallet developers and node operators may view the change as a meaningful refinement to one of Bitcoin Core’s everyday usability features.

Block Processing Aims to Reduce Waiting on Disk

Bitcoin Core 32 also changes how nodes fetch transaction data while checking blocks. Nodes can now retrieve transaction data from their databases using several processing threads at once. Bitcoin Core will use eight of those threads by default, which is designed to reduce time spent waiting for information stored on disk when a node is catching up with the blockchain.

This is especially relevant for node operators bringing a machine up to date. When a node is syncing, it must validate a large amount of historical activity. Any improvement that reduces bottlenecks during block checking can make the experience more efficient, particularly where disk access becomes a limiting factor.

The improvement is not a change to Bitcoin’s monetary policy, block structure or consensus requirements. Instead, it is an implementation-level performance adjustment. The same Bitcoin rules are enforced, but the software is designed to do some of the necessary data-fetching work more efficiently.

For the broader Bitcoin ecosystem, these kinds of updates tend to be less visible than price swings, exchange flows or institutional headlines. Yet they matter because the reliability and performance of node software shape how easy it is for users to verify the chain independently. Easier and more efficient validation can support the long-term health of a distributed network.

Wallet Command Vulnerability Fixed Before Stable Release

Security fixes are another central part of Bitcoin Core 32. Developers addressed a command-execution vulnerability that affected certain wallet configurations on non-Windows systems. The flaw had existed since Bitcoin Core 24.0 and involved an authenticated user with permission to create wallets.

Under certain conditions, such a user could create a wallet with a specially crafted name and cause commands to run on the computer hosting the node. The attack depended on the operator having enabled walletnotify, a feature that automatically runs a chosen command when a wallet transaction occurs.

Bitcoin Core 32 resolves the issue by treating wallet names as literal text rather than allowing parts of a wallet name to be interpreted as commands. That distinction is critical in software security. When user-controlled text is treated as executable instruction, an attacker may be able to move from naming something inside an application to influencing what the host system runs.

The vulnerability was limited by its requirements. It required authentication, wallet-creation permission and the relevant wallet notification configuration. Even so, the fix is meaningful because Bitcoin node software often runs in environments where security expectations are high. Market participants may focus on bitcoin’s price, but the underlying software must also protect operators from avoidable operational risks.

PSBT Version 2 Becomes the Default for Several Commands

Bitcoin Core 32 also updates wallet transaction workflows by making PSBT version 2 the default for four commands used to create partially signed transactions. Partially signed Bitcoin transactions are commonly passed between wallet software and signing devices before bitcoin is sent. This workflow is especially important for users who separate transaction construction from signing, including those using hardware devices or more advanced custody arrangements.

Applications can still request the older format, so the change does not immediately remove compatibility options. However, services that are built directly around those Bitcoin Core commands will need to make sure they support PSBT version 2. For infrastructure providers, wallet developers and technically advanced users, that compatibility check may become part of release preparation.

The shift reflects Bitcoin Core’s gradual movement toward newer transaction-handling standards while preserving pathways for older formats where needed. In practice, the default behavior matters because many applications follow defaults unless developers make a deliberate choice to override them.

For end users, the change may not be obvious unless a wallet or service exposes the format directly. For developers, however, defaults can influence integration requirements, testing plans and support expectations. That makes the PSBT update a notable operational detail even if it is not a consensus-level change.

New Web Server Memory Issue Caught in Testing

Version 32 also replaces Bitcoin Core’s existing web server, which handles requests from other applications communicating with a node. During review, a memory-exhaustion flaw was found in the new server before it appeared in a stable Bitcoin Core release.

The issue involved the server continuing to accept data from a client while still processing an earlier request. That data could accumulate in memory faster than the server could clear it, creating a path for memory use to keep increasing until the node ran out. The developer who submitted the fix described the situation as a memory-exhaustion scenario.

Testing also showed that the problem extended to Bitcoin Core’s REST interface, which can be used without login credentials. In one test, sixteen unauthenticated REST connections moved a node from 46 MB of memory to about 3 GB in roughly a minute. Another 90-second test used 3.2 GB of memory before the fix and about 3 MB after it.

Those figures show why final testing matters. A flaw in a new component can have serious operational consequences if it reaches production systems. In this case, the problem was caught before Bitcoin Core 32 shipped as a stable release, allowing developers to address it during the release candidate cycle.

Why the Update Matters for Bitcoin Users

Bitcoin Core 32 is not a flashy release in the sense of changing the core economics of Bitcoin. It does not alter issuance, block validity rules or the consensus framework. Its importance lies in practical software maintenance: more responsive fee estimation, faster data handling during block validation, safer wallet naming behavior, updated partially signed transaction defaults and a web server fix before stable deployment.

For node operators, the update will likely be assessed through reliability, compatibility and security. For wallet developers, the PSBT default change and fee estimator behavior may require testing. For users, the most visible impact could come through fee recommendations, depending on how wallets and services incorporate the new logic.

For the Bitcoin market, infrastructure updates rarely produce a direct price signal on their own. Still, they contribute to confidence in the network’s operational foundation. Bitcoin’s value proposition depends not only on scarcity and market demand, but also on the continued ability of users to verify the ledger independently with software that is maintained, reviewed and improved over time.

As the Oct. 10 release target approaches, attention will remain on final testing and any additional changes that emerge before the stable build. The release candidate stage is designed for exactly that process: identify issues, test fixes and give operators time to evaluate whether the new version is ready for broader deployment.

Frequently Asked Questions (FAQs)

What is Bitcoin Core 32.0?

Bitcoin Core 32.0 is the next major version of the software used by many Bitcoin node operators to independently verify transactions and blocks against Bitcoin’s rules.

When did Bitcoin Core 32.0 enter final testing?

Bitcoin Core 32.0 entered final testing on Sept. 14, when the first release candidate was tagged.

When is the finished Bitcoin Core 32.0 release scheduled?

The finished release is scheduled for Oct. 10, assuming the final testing process proceeds as planned.

Does Bitcoin Core 32 change Bitcoin’s consensus rules?

No. Bitcoin Core 32 does not change Bitcoin’s consensus rules. The update focuses on software behavior, performance, wallet workflows and security fixes.

How does the fee estimation change work?

Version 32 adds a second estimator that looks at transactions currently waiting to be confirmed. The software can compare that view with historical block-based estimates and recommend the lower fee when current network conditions support it.

Why does faster block processing matter?

Faster block processing can help nodes reduce time spent waiting for transaction data stored on disk while catching up with the blockchain. Bitcoin Core will use eight processing threads by default for this work.

What wallet security issue was fixed?

Developers fixed a command-execution vulnerability affecting certain wallet configurations on non-Windows systems. The issue involved specially crafted wallet names and required walletnotify to be enabled under certain conditions.

What is changing with PSBT transactions?

Four Bitcoin Core commands used to create partially signed transactions will use PSBT version 2 by default. Applications can still request the older format if needed.

Was the web server memory flaw released in a stable version?

No. The memory-exhaustion flaw was found in the new web server before Bitcoin Core 32 appeared as a stable release, and the fix reduced memory use sharply in testing.