A partially signed Bitcoin transaction (PSBT) carries an unsigned transaction together with the signatures collected so far. When a wallet or signing device rejects a file, the failure is often attributed to “version 2” without checking what that actually means. Before changing the payment or requesting more signatures, it helps to separate three questions: can the application open the container, are further changes to the transaction still permitted, and can the signer authorize the intended input type and spending path. These are distinct boundaries, and answering one does not answer the others.
The first check is the container version. Under BIP-174, a version-zero PSBT must contain PSBT_GLOBAL_UNSIGNED_TX and must either omit PSBT_GLOBAL_VERSION or set it to zero; the embedded unsigned transaction must have empty scriptSigs and witnesses and use the non-witness serialization format. BIP-370 requires a version-two PSBT to exclude that unsigned-transaction field and set PSBT_GLOBAL_VERSION to two, with transaction components spread across global, per-input and per-output fields. A report that only says “version 2” is ambiguous, because BIP-370 also introduces PSBT_GLOBAL_TX_VERSION, which records the version of the Bitcoin transaction being created rather than the version of the PSBT container. Ask for the decoded PSBT_GLOBAL_VERSION value, or confirmation that it is absent, and the transaction version as a separate figure.
The second check concerns whether the payment can still change. BIP-370 uses PSBT_GLOBAL_TX_MODIFIABLE to record whether inputs and outputs may be added or removed. Inputs may be added only when the Inputs Modifiable flag is true, and outputs only when Outputs Modifiable is true. The absence of the field is not permission to edit: a creator that is also the only constructor may omit it, and a constructor can clear the flags to end further changes. After signing, the signer must update the flags according to the signature’s sighash mode — Inputs Modifiable becomes false for a signature that does not use SIGHASH_ANYONECANPAY, and Outputs Modifiable becomes false without SIGHASH_NONE. A readable container, in other words, does not authorize revising a signed payment.
The third check is whether the signer can actually authorize the intended spending path. BIP-371 defines Taproot fields for both container versions, so switching between v0 and v2 does not by itself establish Taproot support. The specification separates key-spend and script-spend signature fields and requires 64- or 65-byte Schnorr signatures and 32-byte X-only public keys; its invalid test cases include wrong-length signatures and mis-encoded keys. BIP-174 also allows a signer to support only some input types and requires it to reject an unacceptable sighash type. If a file opens but no signature appears, inspect input-type support, the supplied signing data and the requested signature mode before trying another format change.
Conversion is reconstruction, not relabeling. BIP-370 describes v2-to-v0 conversion as building an unsigned transaction from the v2 fields; editing only the version marker does not produce a conforming v0 container, and adding the unsigned transaction while keeping v2-only fields does not either. Preserve the original file and compare the reconstructed transaction — input and output order, amounts, scripts, sequence numbers, transaction version and locktime — against it. Locktime deserves particular care: the fallback value applies only when no input states a requirement, height-based locktime takes precedence when both types remain possible, and a blocking conflict can leave no compatible value.
A useful diagnostic order is container structure first, modification permissions second, and signing requirements third. The specifications explain what to inspect; they do not identify the cause of an unexplained error in a particular application. Before the next signature request, obtain the decoded container version, the separate transaction version, a required-field validation result and documentation for the intended spending path. If conversion is needed, confirm that any unexplained differences are resolved before collecting further signatures.
Source: BTCUSA.