Compare the original PSBT format with version 2, including input/output construction, modification flags and compatibility between signing tools.
Two different version numbers
A Bitcoin transaction has its own version field. A PSBT container can also have a format version. They answer different questions. Changing the PSBT format does not activate a consensus upgrade or create a new Bitcoin network.
The original BIP 174 representation is usually called PSBT v0. BIP 370 specifies PSBT v2. The skipped number does not imply there was a separate deployed PSBT v1 transaction format that every wallet must support.
What changes in the container
In v0, a global unsigned transaction supplies the transaction skeleton. Per-input and per-output maps add the information needed by participating tools. That structure suits a workflow in which the proposal has already been assembled before it is exchanged.
Version 2 moves transaction-construction information into dedicated global, input and output fields. It provides a way for a constructor to work with input/output lists under explicit modification conditions. A valid v2 PSBT excludes the v0 global unsigned-transaction field and identifies its container version as required by the specification.
This is a structural distinction. It does not mean every v2 file can be modified freely at any point or that signatures remain valid after arbitrary changes.
Modification permission is not a promise about signatures
BIP 370 defines transaction-modifiable flags, including constraints related to inputs, outputs and SIGHASH_SINGLE pairings. A constructor must interpret these alongside the signatures and their commitment rules. Once a signature commits to particular data, altering that data can invalidate it.
Adding a second participant
A coordinator initially collects one participant's input and later another's. A compatible v2 construction workflow can represent that changing proposal under its flags. Before the final proposal is signed, every participant still needs to review the destinations, amounts and fee. A permission flag is not approval of a newly added output.
Compatibility comes before convenience
A wallet may understand one PSBT version, only some script types, or only a particular signer workflow. A successful import does not prove that it can sign every input or safely recognize change. Check the specific wallet's documentation and use public test fixtures when evaluating interoperability.
Conversion between formats requires preserving the transaction and relevant metadata under the target format's rules. Renaming a file or editing its version field is not a conversion. Unknown fields should be handled according to the specification rather than discarded because an interface does not display them.
Keep the boundaries separate
When diagnosing a failed handoff, ask whether the problem is the PSBT container, the output script type, missing previous-output data, unsupported key derivation or the proposed transaction itself. Those problems require different fixes.
The intended payment should remain inspectable in either format. Never approve a proposal merely because a tool reports a newer version number. The destination and the signed commitments matter more than the label on the container.
Sources and further reading
Key takeaways
- PSBT version and Bitcoin transaction version are separate fields.
- PSBT v2 changes transaction-construction metadata; it is not a network fork.
- Modification flags do not override signature commitments or signer review.
Common questions
Does Taproot require PSBT v2?
Taproot-specific PSBT fields are specified separately. Do not confuse script support with the container version supported by a wallet.
Can I change a version field to convert a file?
No. The required fields and representation differ, so a format-aware conversion is necessary.