PSBT Guide: Roles, Versions, Signing Checks, and Failure Modes
Security and commercial-interest disclosure: D-Central sells mining equipment and services and has a financial interest in mining decisions. This educational guide is not independent custody, product, legal, financial, or security advice, and it does not recommend a provider or guarantee an outcome. Verify the exact transaction, wallet policy, implementation documentation, and signer display before approval. Never enter a seed, private key, or live recovery secret into a webpage.
Partially Signed Bitcoin Transactions coordinate transaction data between creators, updaters, signers, combiners, input finalizers, transaction extractors, and broadcasters. A PSBT is data; it does not establish recipient intent, change ownership, fee reasonableness, authorization, or a safe transport path.
Roles and maps
BIP 174 defines a global map and maps for each input and output. A creator supplies transaction data; an updater adds information; a signer adds signatures only after verification; a combiner merges compatible PSBT data; an input finalizer produces final script data; and a transaction extractor creates a transaction from a complete PSBT. Broadcasting is a subsequent network action. Roles may be combined by an implementation, but their responsibilities remain distinct.
A BIP 174 participant must preserve key-value pairs it does not understand. Unknown and proprietary fields are not permission to reinterpret or silently sanitize a transaction. If an explicit conversion knowingly transforms fields, record it, retain the prior artifact, and compare the resulting PSBT with the documented implementation.
Version boundaries
| Specification | Boundary | Compatibility question |
|---|---|---|
| v0 / BIP 174 | Global unsigned transaction and per-map fields. | Does every participant support the required maps and finalization rules? |
| v2 / BIP 370 | Transaction construction fields live in maps. | Does a participant preserve v2 fields and transaction-modifiability rules rather than silently converting or dropping them? |
| Taproot / BIP 371 | Taproot-specific input and output fields. | Can the signer verify the intended key-path or script-path context? |
Signer checks before approval
- Compare every displayed output, amount, and destination with an independently obtained instruction.
- Identify change from the documented wallet policy; do not trust a label alone.
- Check fee, weight context, locktime, sequence, and sighash behaviour.
- Verify each input’s UTXO and applicable witness or non-witness data, scripts, derivation evidence, and spend path.
- Reject or pause on unexpected unknown or proprietary fields, missing data, display disagreement, or version incompatibility.
Sanitised workflow
Use a documented export and import route, retain an immutable transaction review record, and minimize unnecessary metadata. Treat removable media, QR transfer, cables, and networked services as untrusted transport channels. Re-open and compare the PSBT after each hand-off; an offline path does not guarantee isolation or correct interpretation.
Compatibility and failure matrix
| Signal | Risk | Safe response |
|---|---|---|
| Unknown field disappears | Another participant’s data or workflow requirement may be lost. | Stop, restore the prior artifact, and compare with the documented implementation. |
| Different displayed output or fee | Recipient, change, or fee interpretation mismatch. | Do not sign; independently reconstruct and review the transaction. |
| Missing UTXO or Taproot data | Signer cannot verify the spend context adequately. | Obtain authenticated wallet-policy evidence or abandon the workflow. |
| Version unsupported | Silent conversion or dropped fields can change meaning. | Use only documented compatible tooling and re-verify all maps. |
Pinned primary sources
Reviewed 2026-08-29. These exact revision-pinned sources make the review reproducible; they do not make an implementation permanently current. Related educational context: transaction lifecycle and independent node validation.
Frequently asked questions
What is a PSBT?
A PSBT is a structured container for Bitcoin transaction data as it moves through construction, signing, combination, finalization, and extraction roles. It is not a permission grant or proof that a transaction is safe.
What is PSBT v0?
BIP 174 version 0 uses a global unsigned transaction plus global, input, and output maps.
How does PSBT v2 differ?
BIP 370 version 2 represents transaction construction fields in maps rather than relying on the v0 global unsigned transaction field.
What does BIP 371 add?
BIP 371 specifies PSBT fields for Taproot inputs and outputs. A signer must understand the applicable spend path and fields before signing.
Should unknown or proprietary fields be removed?
No. A participant should preserve fields it does not understand. Do not strip them merely to make a tool accept the PSBT; use a compatible documented workflow and investigate any transformation.
What must a signer verify?
Verify every destination and amount, identify change independently, check fees and transaction weight context, inspect sighash behaviour, and verify UTXO and script data against the expected wallet policy.
Does an offline transfer guarantee safety?
No. Transport can reduce some exposure but cannot prove the transaction, firmware, display, policy, or receiving workflow is trustworthy.
Can one PSBT workflow be prescribed for every multisig arrangement?
No. Key custody, recovery, scripts, compatibility, and operational controls are specific to the documented wallet policy.
