Bitcoin Core’s developers created the signed v32.0 final tag on October 21, following the release-candidate process. The milestone fixes a specific source-code version for the major update, whose documented changes include wallet transaction formats and fee estimation.
TL;DR: Version 32.0 has reached its final source tag. For wallet and infrastructure operators, the practical work centres on compatibility and changed defaults.
The finalization pull request, also merged October 21, covers the version update, manual pages and release notes. A final tag identifies source code; it does not establish that every download channel, packaged distribution or service has already adopted that version.
A transaction format change reaches wallet integrations
The project’s 32.0 testing guide documents version 2 as the default produced by Bitcoin Core’s interfaces for partially signed Bitcoin transactions, or PSBTs. The implemented-BIPs list also records the new default in v32.0. These files allow different components to participate in constructing and signing a transaction before it is ready to broadcast.
The format’s underlying BIP 370 specification explains why it changes. The earlier format fixes an unsigned transaction at the outset, limiting the ability to add inputs and outputs later. Version 2 separates that information into fields that support further construction under defined rules.
The specification also makes compatibility explicit: version 2 and version 0 are not interchangeable, although conversion is possible. That matters for a workflow spanning wallet software, an offline signer and a service that assembles payments. Each component has to understand the format it receives.
A new default can expose an integration assumption that was previously invisible. A successful test should follow the complete transaction through construction, signing and finalization, rather than stop when one application produces a file.
Fee estimates remain estimates
The testing guide also describes a combined fee estimator. It brings together the existing estimator based on block history and a newer one using the node’s current pool of unconfirmed transactions, returning the lower estimate when both provide results.
The new component includes conditions for sparse or unhealthy data. Its intended role is to make the estimate responsive to current conditions; it does not reserve space in a future block or guarantee a confirmation time.
For a payment service, that means the displayed fee and the handling of a delayed transaction should be evaluated together. A lower initial estimate may reduce an immediate cost, but the service still needs a clear response if demand changes after broadcast.
The source milestone gives operators a stable version to assess. It does not remove the need to inspect the particular interfaces their services use, or imply a change in Bitcoin’s monetary policy. The most consequential effects for users may arrive through the wallets and payment systems that integrate these defaults over time.
Written by the News Desk and edited by Samuel Rae.