Key points

  • Bitcoin Core maintainers tagged the signed 32.0 release candidate 1 on September 14, with the final tag targeted for October 10.
  • Four wallet RPCs will create PSBT version 2 by default, while fee estimation and HTTP behavior also change.
  • The build is prerelease software for testing and does not activate new Bitcoin consensus rules.

Bitcoin Core maintainers released version 32.0 release candidate 1 on September 14, opening a focused testing period for node operators, wallet developers and infrastructure providers. The GitHub tag carries a verified signature, while the project's release schedule lists October 10 as the target for the final 32.0 tag. This is prerelease software, not a routine production upgrade, and it does not introduce a new Bitcoin consensus-rule activation. The immediate task is compatibility testing across interfaces that applications use to construct transactions, estimate fees and communicate with nodes.

Wallet software faces a PSBT default change

The most visible integration change affects four remote procedure calls: createpsbt, walletcreatepsbt, converttopsbt and psbtbumpfee. According to the draft release notes, they will create Partially Signed Bitcoin Transactions using version 2 by default. Developers can still request another version through a new psbt_version argument, but services that assume version 0 may need updates. Wallet providers, hardware-signing tools and custody systems should test the full path from creation to signing and broadcast, because one incompatible parser can interrupt an otherwise valid workflow.

Related reporting: BIS study finds Bitcoin transfer estimates can vary sixfold

Fee estimates gain a second input

Bitcoin Core 32.0 also changes estimatesmartfee by combining the existing block-policy estimator with a new estimator based on current mempool conditions. The combined result uses the lower of the two successful estimates, but both estimators must succeed. During startup, after too few recent blocks or when the mempool appears unhealthy, the default request can return an error. Operators that require the prior behavior can explicitly select the block-policy estimator. That makes failure handling and monitoring important parts of release-candidate testing, not just comparisons of the returned fee rate.

HTTP and indexes broaden the test surface

The candidate replaces Bitcoin Core's HTTP server implementation and tightens several edge cases. Draft notes specify an 8,192-byte header limit, stricter malformed-header handling and a default maximum of 16 simultaneous RPC connections. Unauthorized client addresses will be disconnected immediately instead of receiving a 403 response, which may affect reverse proxies and health checks. A rebuilt transaction index should use less than half the previous disk space, but older releases cannot read the new format. A later downgrade would therefore require rebuilding the index again.

Performance gains require local measurement

For block validation, the candidate can prefetch previous transaction outputs in parallel while connecting blocks. The default uses eight worker threads, with a maximum of 16 and an option to disable the feature. The change is intended to improve disk-bound validation, but the practical result will vary with processor, memory and storage performance. Operators can compare the candidate with their current installation in separate temporary data directories, measuring resource use and startup behavior without treating RC1 as the production baseline.

The final release is still conditional

The October 10 date remains an aim rather than a guarantee. Release-candidate testing exists to uncover regressions before maintainers publish the final build, and findings may lead to another candidate or schedule changes. Independent reporting has highlighted the compressed window for checking wallet parsers, fee fallbacks, HTTP clients and rollback procedures. Users who do not operate nodes or build Bitcoin services do not need to take immediate action. For affected teams, the sensible priority is reproducible testing, documented fallbacks and avoiding a production rollout until a final signed release is available.

Sources

AI-generated editorial image; not a photograph of the reported event. Prepared with AI assistance and source verification.