⏱ 3 min read
Release-candidate testing is underway toward an October target, with parallel DB reads, PSBT default updates, and patches for walletnotify command risks and HTTP server memory use.
Bitcoin Core 32.0 entered release-candidate testing with an October target, bundling parallelized block checks, PSBT default updates across four wallet commands, and fixes for crafted wallet names and excessive memory use in the HTTP server. Draft notes and contributor updates frame the scope as performance and security.
Bitcoin Core 32.0 RC
Bitcoin Core lets computers verify Bitcoin transactions and blocks. The next version is in release-candidate testing, with developers targeting October for the final release, according to the project’s schedule. Draft release notes indicate that the update mainly affects node operators and developers who run wallets and related services on top of the software. The testing process can still change the delivery timeline, which leaves room for adjustments as issues are validated and documentation finalizes. The approach balances a performance-focused refactor — parallel database reads for block checks — with security hardening across walletnotify and the new HTTP server, while keeping wallet interoperability intact through an opt-in path to the older partially signed transaction format.
Draft notes specify that four wallet commands will default to a newer format for exchanging partially signed transactions between wallets and signing devices, while applications can still request the older version. A security fix prevents crafted wallet names from triggering commands on a node’s computer. The flaw applied to non-Windows systems under two conditions: an authenticated user could create wallets, and the walletnotify feature was configured to run commands on wallet transactions. A separate patch addresses excessive memory use in the new HTTP server, which serves connected applications and was observed under a “memory exhaustion scenario” scoped to authenticated clients.
▼ 0.25%
Parallel Block Checks
The performance change reads database information in parallel to speed up block checks, without altering how quickly Bitcoin produces blocks, per the draft notes. That distinction matters for operators optimizing infrastructure: faster verification reduces the time software spends validating block data before handing decisions back to dependent services. In practice, the change aims to lower the latency of internal checks and improve responsiveness when nodes are processing data for wallets and application backends that rely on consistent verification throughput.
Security and interoperability shifts arrive alongside the performance work. Defaulting four wallet commands to a newer partially signed transaction format suggests a push to modernize workflows while retaining backward compatibility through explicit requests for the older format. The wallet name fix reduces the risk of unintended command execution when walletnotify is configured, but only where an authenticated user could create wallets on non-Windows systems. Together, these changes point to scoped hardening and smoother developer ergonomics rather than any change to consensus or block production mechanics.
Node Operator Playbook
- Validate parallel-read gains under your production workload; benchmark block-check latency before and after the upgrade.
- Audit walletnotify configurations; restrict who can create wallets and verify command hooks only run with intended inputs.
- Map PSBT defaults across four affected commands; ensure signing devices and wallet software accept the newer format.
- Load-test the HTTP server under authenticated access; monitor memory behavior and enforce strict client authentication.
RC Testing Timeline
Release-candidate testing introduces moving parts that can adjust scope and timing; developers are targeting October, but testing could change that timeline, according to the project’s schedule. The decisive catalysts: stability of parallel database reads under operator-scale workloads, confirmation that PSBT default changes preserve interoperability for wallets and signing devices, and validation that the walletnotify and HTTP server fixes fully mitigate the described issues. Contributor Matthew Zipkin (pinheadmz) highlighted a memory exhaustion scenario limited to authenticated clients and used Kimi K3 during the audit, pointing to focused, operator-facing risk. Final release notes will signal the maturity of these changes and whether any defaults or mitigations shift before general availability.
This content is for informational purposes only and does not constitute financial advice.
🧠 HafidWatch Take
If regression tests demonstrate that parallel database reads do not yield any measurable reduction in block-check latency, then this article’s interpretation of the performance improvements is fundamentally flawed. Such a result would indicate that the changes amount merely to code refactoring without tangible throughput gains, undermining the core argument that the update enhances node verification speed. This would expose the misconception that parallelization intrinsically translates to latency or efficiency benefits, rendering the entire framing of the performance thesis inaccurate from the outset.
A comparable scenario arose during the early adoption of SegWit in 2017, when initial claims of scaling improvements were met with mixed results due to uneven software support and fragmented ecosystem readiness. Similarly, there is a secondary risk that defaulting to the new PSBT format could exacerbate workflow fragmentation if wallet developers lag in updating compatibility, potentially stalling broader adoption and complicating user experience—an operational challenge that extends beyond raw performance metrics and requires vigilant coordination within the developer community.
Daily crypto intelligence. Before the market opens.
Including the Divergence Index — the sentiment gap no other newsletter tracks. Free, every morning at 7:30am ET.
✓ Free forever · ✓ No spam · ✓ 50+ sources monitored
