Bitcoin Core v32 RC1 switches key RPCs to PSBTv2

Bitcoin Core v32.0rc1, tagged Sept. 14 with a target final tag of Oct. 10, changes default behavior for multiple RPCs and node functions. The release candidate is a prerelease build and does not activate new consensus rules.

Four RPC calls that create, convert or fee-bump partially signed Bitcoin transactions (PSBTs) now default to PSBTv2. PSBTs produced by those RPCs will use the v2 format unless callers explicitly request otherwise. Clients that parse or sign PSBTs must accept or convert PSBTv2 to process transactions made by the updated RPCs. Several RPC responses also drop deprecated fields or reject arguments that older clients previously tolerated.

The estimatesmartfee path has been changed to combine a block-policy estimator with the mempool estimator. The combined path can return a lower fee estimate than prior logic and can fail if either estimator reports an error. Startup conditions and sparse or unhealthy mempools can surface those failure paths.

The HTTP server has been rewritten with stricter controls. New limits include an 8,192-byte header cap, tighter handling of malformed headers, a default limit of 16 concurrent RPC connections, updated REST cache controls and immediate disconnection of unauthorized client addresses. Those changes can affect reverse proxies, health checks, client connection pools and existing error handlers.

On performance and storage, the node adds parallel prefetching of transaction outputs during block connection. The setting defaults to eight worker threads, supports up to 16, and can be disabled. Running disk-bound validation with multiple prefetch workers may alter CPU, memory and storage-latency usage on specific hardware. The transaction index format has been rebuilt to use less than half the prior disk space; older releases cannot read the new format, so downgrading requires a full index rebuild that can take hours.

Privacy-related adjustments include a Tor fallback fix and limits on private-broadcast behavior. The private-broadcast queue is capped at 10,000 entries and attempts are limited to 1,000; relay behavior under load has also been altered.

The official RC testing guidance recommends exercising commonly used features in temporary data directories and comparing node startup, wallet behavior and RPC responses against the current baseline, release 31.1. Test plans typically include wallet parsing and signing flows, fee-bump scenarios, mempool edge cases, HTTP client behavior and downgrade paths.

A draft proposal, BIP 323, would change how signaling bits and unknown-deployment warnings are treated, but that proposal remains in Draft status and is not active. With the final v32.0 tag targeted for Oct. 10, the release candidate period is the time window for discovering compatibility and regression issues that affect wallets and services dependent on Bitcoin Core’s RPC interfaces.