PSBT v0 vs PSBT v2 (BIP 174 vs BIP 370)
PSBT version 0 (BIP 174) stores a complete unsigned transaction up front, so its inputs and outputs are fixed from the start; PSBT version 2 (BIP 370) drops that global transaction and keeps each input's and output's details in its own map, so participants can add inputs and outputs later. Both share the same container format, roles and signing fields, and there is no version 1.
Updated · 3 min read
At a glance
| BIP 174 | BIP 370 | |
|---|---|---|
| Title | Partially Signed Bitcoin Transaction Format | PSBT Version 2 |
| Status | Deployed | Deployed |
| Type | Specification | Specification |
| Assigned | 2017-07-12 | 2021-01-14 |
| Authors | Ava Chow | Ava Chow |
| In plain English | Defines PSBT (Partially Signed Bitcoin Transaction), a standard file format for a transaction that is still collecting signatures. It lets different wallets, hardware devices, and co-signers pass a transaction back and forth safely, which is essential for multisig setups and offline signing. | Updates the Partially Signed Bitcoin Transaction (PSBT) format, a standard file for passing an unfinished transaction between wallets and signing devices. Version 2 allows inputs and outputs to be added after the file is created, which makes collaborative transactions like CoinJoins or payjoins easier to build. |
What BIP 174 (PSBT v0) defines
BIP 174, by Ava Chow, defines the Partially Signed Bitcoin Transaction format: a binary container that starts with the magic bytes 0x70 0x73 0x62 0x74 0xFF ("psbt" followed by 0xFF), then a global map, one map per input and one per output. Each map holds typed key-value pairs: the UTXO being spent, BIP 32 derivation paths, partial signatures, sighash types, and finally the completed scriptSig and witness. A PSBT travels as a binary .psbt file or a Base64 string between roles (Creator, Updater, Signer, Combiner, Input Finalizer and Transaction Extractor), so a watch-only wallet, a hardware signer and the co-signers of a multisig can each do their part.
In version 0 the Creator places the whole unsigned transaction in PSBT_GLOBAL_UNSIGNED_TX (key type 0x00). Everything else refers back to that transaction, so its inputs and outputs can't change after creation.
What BIP 370 (PSBT v2) changes
BIP 370, also by Ava Chow, requires PSBT_GLOBAL_VERSION set to 2 and requires PSBT_GLOBAL_UNSIGNED_TX to be left out. The transaction is described field by field instead:
- Global: transaction version (
0x02), fallback locktime (0x03), input count (0x04), output count (0x05) and a modifiable-flags byte (0x06). - Per input: previous txid (
0x0e), output index (0x0f), sequence (0x10), and optional required time-based or height-based locktimes (0x11,0x12). - Per output: amount (
0x03) and script (0x04).
A new Constructor role adds inputs and outputs while the PSBT_GLOBAL_TX_MODIFIABLE flags allow it. Signers update those flags as they sign: a signature without SIGHASH_ANYONECANPAY closes the inputs, and one without SIGHASH_NONE closes the outputs. The final locktime is worked out from the fallback value and each input's requirements, preferring height-based locks when both kinds are possible.
PSBT v0 vs PSBT v2 compared
| PSBT v0 (BIP 174) | PSBT v2 (BIP 370) | |
|---|---|---|
PSBT_GLOBAL_VERSION |
Omitted or 0 | Must be 2 |
| Global unsigned transaction | Required | Must be excluded |
| Where input and output data lives | Split between the global transaction and the per-input/output maps | Entirely in each input's or output's map |
| Add inputs or outputs after creation | Not possible | Yes, while the modifiable flags allow it |
| Locktime | Fixed in the unsigned transaction | Computed from the fallback and per-input requirements |
| Roles | Creator, Updater, Signer, Combiner, Input Finalizer, Transaction Extractor | The same, plus Constructor |
| Unique identifier | Txid of the global unsigned transaction | Txid of a transaction rebuilt from the fields, with sequences set to 0 |
| Transaction version | Any | At least 2 when others may add inputs or outputs |
| Taproot fields (BIP 371) | Supported | Supported |
How PSBT v2 relates to v0
BIP 370 builds on BIP 174 rather than replacing it. The generic format, the roles and most fields are shared, and BIP 370 says parsers for version 0 should be able to deserialize version 2 "with only changes to support the new fields". As files, though, the two are intentionally incompatible: a parser that meets a version number it doesn't recognize must stop, which is what allowed the global transaction to be removed. A v2 PSBT can be converted to v0 by building the unsigned transaction from its fields.
Why skip version 1? BIP 370 explains that version 0 had been colloquially called "version 1", while the new format was called "version 2" during its design, so numbering it 2 avoided confusion.
Which PSBT version should you use?
- Fixed transactions, where one wallet builds the transaction and a hardware wallet or co-signers sign it: version 0 handles this, and it is the original format.
- Collaborative transactions, where several parties contribute inputs or outputs, such as coinjoins and payjoins: version 2 is designed for this, because each party can add its part before anyone signs over everything.
- Mixed tool support: check which versions your software accepts. BIP 370 notes that a v2 PSBT can be turned into v0 for tools that only read v0.
The PSBT guide walks through each role step by step, and the multisig guide shows PSBTs in use.
Frequently asked questions
What is PSBT v2?
PSBT version 2 is the format defined in BIP 370 by Ava Chow. It keeps BIP 174's container and roles but replaces the single global unsigned transaction with per-input and per-output fields, plus counts, a fallback locktime and modifiable flags. That lets inputs and outputs be added after the PSBT is created, which suits collaborative transactions.
Why is there no PSBT version 1?
BIP 370 skipped the number on purpose. The original BIP 174 format, which is version 0, had been informally called version 1, and the new format had been called version 2 while it was being designed. Numbering the new format 2 avoided having two different things both known as version 1.
Can PSBT v0 and v2 be converted?
BIP 370 notes that a v2 PSBT can be converted to v0 by building an unsigned transaction from its fields and placing it in the global map. The formats themselves are deliberately incompatible, so software has to check the version number: a parser that only understands version 0 should reject a version 2 file rather than misread it.
Do Taproot PSBT fields work with PSBT v2?
Yes. BIP 371, also by Ava Chow, adds Taproot fields such as key-path signatures, script-path signatures, leaf scripts and Taproot BIP 32 derivations, and defines them for both version 0 and version 2. A Taproot input can be signed through either PSBT version.
Which PSBT version should I use?
For ordinary sends, use whatever your wallet and signing devices support; a fixed transaction works fine as version 0. Choose version 2 when several parties need to add inputs or outputs before signing, as in coinjoins or payjoins. Signers record in the modifiable flags when further changes would invalidate their signatures.