Bitcoin Core v32.0rc1 lands with wallet protocol tweaks, raising app compatibility risks

Bitcoin Core v32.0rc1 has effectively set a focused compatibility window for node operators, wallet providers and any services relying on Bitcoin Core's RPC interfaces. The release candidate was tagged with a verified signature on Sept. 14. The project's live release schedule targets Oct. 10 for the final v32.0 tag, creating a 26-day span for testing. CryptoSlate's August preview cited Sept. 10 as the RC1 target, while the live schedule now shows Sept. 14, a four-day shift without confirming a missed deadline. The v32.0rc1 tag indicates prerelease software rather than a production-ready upgrade, and it does not imply activation of new consensus rules. One adjustment linked to draft BIP 323 changes how Bitcoin Core handles signaling bits and unknown-deployment warnings, though the proposal remains in Draft status. Bitcoin Core's latest RC testing guide suggests a straightforward approach: test frequently used features in separate temporary data directories, then compare behavior against the prior release. The official download page lists 31.1 as the current baseline. This side-by-side check can highlight differences in node startup, wallet behavior and RPC responses without treating the RC as a routine production update. The most notable performance item in the draft v32 release notes is parallel prefetching of transaction outputs during block connection. The default is eight workers, configurable up to 16, and it can be disabled. Operators running disk-bound validation are encouraged to test multiple settings to see whether faster block processing introduces unacceptable CPU, memory or storage-latency costs on their hardware. Wallet and service integrations face a separate risk of breakage. Four RPC methods will default to PSBTv2. Other interfaces either remove deprecated fields or reject arguments that older versions previously accepted. Teams that create, convert or fee-bump PSBTs should trace those flows through downstream parsers and signers to confirm compatibility. Fee estimation also warrants testing under failure scenarios. The default estimatesmartfee path now combines blockpolicy and mempool estimators, may return a lower estimate, and can error if either component fails. Operators should observe behavior during startup and under sparse or unhealthy mempool conditions, then verify monitoring logic and explicit blockpolicy fallbacks operate as intended. A rewrite of the HTTP server expands the testing surface beyond the node. Changes include an 8,192-byte header limit, stricter handling of malformed headers, a default cap of 16 RPC connections, new REST cache controls and immediate disconnection of unauthorized client addresses. These updates may show up in reverse proxies, health checks, client connection pools and error-handling logic. Rollback planning is also part of the RC work. A rebuilt transaction index uses less than half the disk space, but older releases cannot read the new format. Downgrading can trigger another index rebuild that may take hours. Privacy-focused operators are advised to replay private-broadcast failure paths tied to the Tor fallback fix, the 10,000-entry queue, the 1,000-attempt limit and relay behavior under load. With the final tag still listed as a target rather than a certainty, validating these edge cases is a practical focus for the RC testing window.