Partially signed transactions (PSBT)

Wonder

1. Why does an unfinished transaction need more data than the finished one?
2. Why did every hardware wallet once need its own format for unsigned transactions?
3. How can a user add a new output after the initial template is already built?

Explore

1. A standard raw transaction is a compact, final artifact ready for broadcast. A Partially Signed Bitcoin Transaction (PSBT), defined by BIP174 in 2017 by Andrew Chow, is different: it is a container holding an unfinished transaction alongside all metadata needed to complete it later. It exists in three states: fully constructed but unsigned, partially signed with some inputs done and others pending, or fully signed and ready for extraction into raw hex. This format allows an untrusted program to generate a template that can be verified by a trusted device without the device needing network access.
2. The PSBT workflow defines six roles: Creator, Updater, Signer, Combiner, Finalizer and Extractor (version 2 adds a seventh, Constructor). After a creator builds the transaction, an updater attaches the previous outputs being spent, their scripts and the keys’ derivation paths, so a signer can check exactly what it approves, amounts and fee included. This explicit inclusion of metadata makes the file significantly less compact than standard serialization, but it is essential because it allows hardware wallets to verify the transaction’s structure without connecting to an internet-connected node that might be compromised or running malicious software.
3. Interoperability is the primary driver for PSBTs. Before this standard existed, different wallet software used incompatible methods to pass data between a hot wallet and a cold storage device, creating vendor lock-in. BIP174 solved this by establishing a universal language; today a coordinator such as Sparrow can hand the same PSBT to signing devices from different manufacturers, by USB, SD card or QR code. That makes multisig across vendors practical: each signer adds its signature to the file, and no private key ever leaves its device.
4. Version 0 of PSBT has a rigid structural limitation: once created, the global unsigned transaction is fixed. Version 0 stores a complete unsigned transaction in a global field, so inputs and outputs cannot be added once it is created. This rigidity meant that if someone started building a complex multi-party transaction and realized they needed an extra change output, they had to scrap the entire process and start over from scratch with a new template.
5. BIP370 introduces PSBT Version 2 to solve this immutability problem. In Version 2, all information for a given input or output is consolidated into that specific field rather than being split between local and global data. Participants can then add inputs or outputs after creation, as long as the PSBT’s ‘modifiable’ flags allow it. It streamlines the collaborative process by ensuring that if one looks at a single input, every piece of data related to it is contained right there, simplifying verification for hardware devices and reducing the risk of state desynchronization.
6. Practical uses range from hardware wallet signing to collaborative transactions such as payjoin and coinjoin, where participants pass PSBTs back and forth until everyone has signed. For a standard user, this means one can create a transaction on a phone, plug in a hardware wallet to sign it securely offline, and then extract the final raw transaction for broadcast—with each device seeing exactly what it signs.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• BIP174: Partially-Signed Bitcoin Transactions (2017)
• BIP370: PSBT Version 2 (2021)
• Bitcoin Core documentation: psbt.md