PSBT version 2

Version 0 pins the input and output set at creation; version 2 moves every detail into per-input and per-output maps instead. BIP-370 was assigned on 14 January 2021 and skips the number 1, since BIP-174's format is version 0 and was colloquially called version 1. For a holder, version 2 matters only in a signing session where another participant adds coins to a transaction you already started.

How it works

PSBT version 2 keeps the outer container of BIP-174 and rearranges what sits inside it. Two rules define the switch: PSBT_GLOBAL_UNSIGNED_TX must be absent, and PSBT_GLOBAL_VERSION must be present and set to 2.

What the removed transaction used to carry is redistributed across twelve new fields. Five are global: transaction version (0x02), fallback locktime (0x03), input count (0x04), output count (0x05) and a modifiable flags byte (0x06). Five sit on each input: the 32 byte previous txid (0x0e), the spent output index (0x0f), the sequence number (0x10), and two required locktimes, one timestamp based at or above 500000000 (0x11), one height based below that and above zero (0x12). Outputs gain two, the amount in satoshis as a 64 bit signed little endian integer (0x03) and the script (0x04).

The modifiable flags byte does the real work. Bit 0 says inputs may still be added or removed, bit 1 says the same for outputs, and bit 2 records that some signature already committed with SIGHASH_SINGLE, so its input and output pairing has to be preserved. A signer must tighten those bits as it goes: a signature that does not use SIGHASH_ANYONECANPAY clears bit 0, and one that does not use SIGHASH_NONE clears bit 1. Permission to keep editing expires on its own as signatures land, rather than resting on the good manners of the next holder.

BIP-370 settles the two questions the missing transaction left open. Locktime becomes the largest value the inputs agree on, falling back to the global field, or to 0 when that is absent, and a height based requirement wins any tie. Identity becomes the txid you get by assembling the fields with every sequence number forced to 0, since sequence can still be edited later.

Where you see it

PSBT version 2 introduces a role BIP-174 has no equivalent for, the Constructor. A Creator opens the file with 0 inputs and 0 outputs and hands it on; the Constructor adds them, after checking the modifiable flags. A Creator expecting contributions must also set the transaction version to at least 2, so features gated on it, such as OP_CHECKSEQUENCEVERIFY, stay available.

Version 2 reuses the serialization of BIP-174, so a file looks the same from the outside, and the split is deliberate: of the 24 invalid test vectors in the BIP, 13 are ordinary version 0 files rejected for one out of place field or version number. Conversion runs downhill, since a version 2 file can be rebuilt as a version 0 one from its own fields. The reference implementation is Bitcoin Core pull request 21283, and the BIP header records the status as Deployed.

Of the 41 wallet reviews on this site, two mention PSBTs, Sparrow (rated 4.7) and BlueWallet (4.2), and neither names a version. Assume version 0 unless the software says otherwise, and test an unfamiliar tool with a small amount before it handles the rest.

PSBT version 2 vs the transaction version number

PSBT version 2 numbers the file format, while the transaction version number numbers the transaction being assembled inside it. Both live in the same global map, and BIP-370 says plainly they are not the same field. PSBT_GLOBAL_VERSION is 2 in every version 2 file; PSBT_GLOBAL_TX_VERSION is a signed 32 bit integer for the transaction being built, and BIP-370 requires it to be at least 2 when the Creator expects contributions, which is why the two get muddled. Change the first and older parsers refuse the file. Change the second and you change which consensus rules the spend is judged by.