PSBT lets one machine build and another sign, separately

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A format for handing off a half-built transaction

Before a standard existed, moving an unsigned transaction between two pieces of software, an online machine and an offline signer, was implementation-specific. The BIP174 specification, assigned 12 July 2017, states the problem directly: creating unsigned or partially signed transactions to pass around to multiple signers was implementation dependent, making it hard for people using different wallet software to do so easily. Its answer is a binary format beginning with fixed magic bytes, followed by a global map holding the unsigned transaction, then one map per input and one per output, each able to carry unknown fields forward for compatibility.

Who does what, in order

The Bitcoin Core PSBT documentation, describing the format as retrieved on 16 September 2026, sets out defined roles that a single piece of software can combine or split across machines: a Creator proposes a particular transaction to be created, an Updater adds information about the UTXOs being spent, a Signer inspects the proposal and contributes a partial signature, and a Finalizer converts the partial signatures and any script information into a final scriptSig or scriptWitness, after which an Extractor produces the ordinary, broadcastable transaction. The same document names hardware-wallet signing, multisignature coordination, and CoinJoin construction as the workflows this separation was built for.

What moves, and where the risk goes

The split removes a specific danger: an offline signer no longer needs live access to the UTXO set, or blind trust in a summary someone typed out, to know what it is actually signing, because the relevant previous-output data travels inside the PSBT itself. What the format does not remove is the transfer step. A PSBT still has to move between devices, by file, QR code, or another channel, and a signer that does not independently check the amounts and destinations embedded in it before signing has not gained the verification the format was built to provide, only a new file format to trust blindly. Support arrived broadly with Bitcoin Core 0.17.0, published 3 October 2018, which added six new RPCs, including createpsbt, walletprocesspsbt and finalizepsbt, covering the format end to end.

Questions to carry forward

• Does a hardware wallet display the PSBT's embedded destination and amount for the signer to check, or only a summary constructed elsewhere?
• Is the channel moving a PSBT between machines itself something an attacker could substitute a different file into?
• Which roles, in a given multisig setup, does each participant's software actually perform, and which are combined into one?

PSBT is a transport format, not a verification guarantee; it makes the handoff interoperable, and leaves the checking, as it always did, to whoever is asked to sign.