Bitcoin Core v32.0rc1 has entered a concentrated compatibility-testing phase for node operators, wallet providers and services dependent on Bitcoin Core's RPC interfaces. The release candidate was tagged with a verified signature on September 14, with October 10 set as the target date for the final v32.0 release.
The prerelease software does not signal a new consensus-rule activation. However, it includes several changes that may require testing and adjustments across the ecosystem.
RPC and Protocol Changes
Four RPCs will default to PSBTv2 (Partially Signed Bitcoin Transaction version 2), requiring compatibility checks across wallet parsers and signers. Other RPC interfaces will remove deprecated fields or reject arguments that older versions previously tolerated, potentially affecting integrations that depend on those deprecated parameters.
Fee Estimation Updates
The default estimatesmartfee path now combines block-policy and mempool estimators, which may return a lower estimate than previously. The combined fee estimate requires both estimators to succeed, creating failure paths that need testing. If either component fails, the RPC can error, requiring operators to implement explicit block-policy fallbacks.
Performance and Infrastructure Changes
The release includes parallel prefetching of transaction outputs during block connection, with a default setting of eight workers and support for up to 16. The HTTP server has been rewritten with new features including an 8,192-byte header limit, stricter malformed-header handling, a default ceiling of 16 RPC connections, and new REST cache controls.
Downgrade Considerations
The rebuilt transaction index uses less than half the disk space of previous versions, but older releases cannot read the new format. A downgrade to a previous version can trigger a full index rebuild lasting several hours, making upgrade decisions significant for operators.
Testing Recommendations
Bitcoin Core's RC testing guide recommends operators exercise regularly used features in separate temporary data directories and compare the candidate with the prior release (v31.1). Teams managing PSBT creation, conversion or fee-bumping should trace transactions through downstream parsers and signers to identify compatibility issues before production deployment.
