BIP-174 (PSBT Format)

What Is BIP-174?

BIP-174 is a Bitcoin Improvement Proposal that specifies the Partially Signed Bitcoin Transaction (PSBT) format. Authored by Ava Chow (achow101) and first proposed in August 2017, it defines a binary serialization format for passing unsigned or partially signed transactions between different software and hardware. The specification has "Deployed" status and was first implemented in Bitcoin Core version 0.17.0 in October 2018.

Before PSBT, there was no standard way to share an incomplete transaction between wallets. Each hardware vendor and software wallet used proprietary formats, making interoperability difficult. A user with a cold storage device from one vendor often could not use it with wallet software from another. BIP-174 solved this by creating a universal container format that any compliant tool can read, modify, and pass along.

The core principle is simple: the unsigned transaction travels, but the keys do not. A networked computer constructs the transaction, an offline signing device adds its signature, and the signed transaction returns for broadcast. At no point do private keys leave the secure environment.

How It Works

A PSBT is a binary data structure built around key-value maps. The format begins with the magic bytes 0x70736274ff (ASCII "psbt" followed by a 0xff separator), then contains a global map, one map per input, and one map per output. Each map is a sequence of key-value pairs terminated by a 0x00 byte.

Binary Structure

<psbt>       := <magic> <global-map> <input-map>* <output-map>*
<magic>      := 0x70 0x73 0x62 0x74 0xFF
<global-map> := <keypair>* 0x00
<input-map>  := <keypair>* 0x00
<output-map> := <keypair>* 0x00
<keypair>    := <key> <value>
<key>        := <keylen> <keytype> <keydata>
<value>      := <valuelen> <valuedata>

The 0xff separator after the magic bytes is intentional: any non-PSBT deserializer that tries to parse the data as a regular transaction will fail immediately, preventing accidental misinterpretation.

Key-Value Maps

The global map stores data that applies to the entire transaction, such as the unsigned transaction itself (key type 0x00) and any extended public keys with their derivation paths (key type 0x01).

Each per-input map carries the data a signer needs for that specific input: the previous UTXO being spent, redeem scripts, witness scripts, BIP-32 derivation paths for the keys involved, and any partial signatures already collected. For SegWit inputs, only the witness UTXO (amount and scriptPubKey) is required rather than the full previous transaction.

Per-output maps describe change outputs the wallet controls, including redeem scripts, witness scripts, and derivation paths. This allows signing devices to verify that change is returning to addresses the user owns.

The Six Roles

BIP-174 defines six roles that participate in the PSBT lifecycle. A single entity can perform multiple roles, and the workflow does not need to follow a strict linear sequence:

1. Creator: constructs a new PSBT containing the unsigned transaction with the desired inputs and outputs. The Creator determines which UTXOs to spend and where funds go, but adds no signing metadata.
2. Updater: enriches the PSBT with metadata that signers need. This includes full previous transactions or UTXO data, redeem scripts, witness scripts, and BIP-32 derivation paths for each key.
3. Signer: examines the PSBT and adds partial signatures for inputs it controls. Multiple signers can work in parallel on separate copies of the same PSBT.
4. Combiner: merges multiple PSBTs that represent the same underlying transaction but contain different partial signatures. This is essential for parallel signing workflows.
5. Finalizer: collects all partial signatures for each input and constructs the final scriptSig and scriptWitness data. Once finalized, unnecessary metadata is stripped from the PSBT.
6. Extractor: takes the finalized PSBT and produces a complete, network-serialized transaction ready for broadcast.

Example Workflow

A typical multisig PSBT workflow using Bitcoin Core's RPC interface:

# Creator: build the unsigned transaction
bitcoin-cli walletcreatefundedpsbt \
  '[{"txid":"abc...","vout":0}]' \
  '[{"bc1q...":0.01}]'

# Updater: add UTXO and derivation data
bitcoin-cli walletprocesspsbt "cHNidP8B..."

# Signer 1: sign on first device
bitcoin-cli walletprocesspsbt "cHNidP8B..."

# Signer 2: sign on second device
bitcoin-cli walletprocesspsbt "cHNidP8B..."

# Combiner: merge both partially signed PSBTs
bitcoin-cli combinepsbt '["cHNidP8B...","cHNidP8B..."]'

# Finalizer + Extractor: finalize and extract
bitcoin-cli finalizepsbt "cHNidP8B..."

The base64-encoded strings (beginning with "cHNidP8B", which decodes to the PSBT magic bytes) can be transferred between devices via file, QR code, SD card, or NFC.

PSBT Version 2 (BIP-370)

BIP-370, also authored by Ava Chow, introduced PSBT version 2 with "Deployed" status. The primary limitation of PSBT v0 is that the entire unsigned transaction is stored as a single global field, making it impossible to add or remove inputs and outputs after the PSBT is created.

Version 2 decomposes the transaction into individual fields spread across the per-input and per-output maps. Each input map stores its own previous txid, output index, and sequence number. Each output map stores its amount and scriptPubKey. A new global "transaction modifiable" flags field (key type 0x06) indicates whether inputs, outputs, or both can still be added.

This change introduces a new Constructor role that can modify the transaction structure before signing begins. The practical impact is significant: protocols that require interactive transaction building, such as Payjoin and CoinJoin, can now use the standard PSBT format rather than custom protocols.

PSBTv2 is intentionally incompatible with v0 (the global unsigned transaction field is excluded in v2), though a v2 PSBT can be converted to v0 by reconstructing the unsigned transaction from the decomposed fields. There is no "version 1": since v0 was colloquially called "version 1," the next version was numbered 2 to avoid confusion.

Taproot and Advanced Extensions

BIP-371 extends the PSBT format with fields specific to Taproot transactions. It adds per-input fields for Taproot key-spend signatures, script-spend signatures, leaf scripts, internal keys, and Taproot-specific BIP-32 derivation paths. Per-output fields carry the Taproot internal key, tap tree structure, and derivation paths.

Because Taproot signatures commit to all input amounts, Taproot inputs can safely use only the witness UTXO without the full previous transaction. This simplifies the data requirements for signing devices and reduces the PSBT size.

Additional BIP extensions build on the PSBT framework: BIP-373 adds fields for MuSig2 Schnorr multi-signatures, BIP-375 enables sending to silent payment addresses, and Miniscript (BIP-379) helps wallets automatically determine what signatures are needed to satisfy complex spending conditions within PSBTs.

Use Cases

Hardware Wallet Signing

PSBT is the standard interface between software wallets and hardware signing devices. A wallet application on a networked computer constructs and updates the PSBT, transfers it to a hardware device (via USB, SD card, QR code, or NFC), the device signs, and the signed PSBT returns for broadcast. Devices like Coldcard, Trezor, Ledger, BitBox02, Blockstream Jade, and SeedSigner all support the PSBT format.

Multisig Coordination

For multisig wallets, PSBT enables practical multi-party signing. In a 2-of-3 setup, the PSBT can be sent to each cosigner independently. Each signer adds their partial signature, and a Combiner merges the results. The format carries all the metadata (redeem scripts, derivation paths, previous UTXOs) that each signer needs to verify the transaction before signing.

Air-Gapped Security

PSBT enables fully air-gapped workflows where signing keys never touch a network-connected device. The transaction is built on an online machine, transferred to an offline signer via SD card or animated QR codes (using the BBQr protocol), signed in isolation, and returned. This is the gold standard for self-custody security.

Lightning Channel Funding

Lightning implementations like LND use PSBT for channel funding transactions. This allows users to fund channels from external wallets or hardware devices rather than the LND internal wallet, preserving the separation between hot channel keys and cold funding keys.

Why It Matters

PSBT eliminated vendor lock-in in Bitcoin wallet infrastructure. Before the standard, choosing a hardware wallet meant committing to its companion software. Now, users can pair any PSBT-compliant signing device with any PSBT-compliant wallet: Sparrow Wallet with a Coldcard, Specter Desktop with a SeedSigner, or Bitcoin Core with a Ledger.

For developers building on Bitcoin, PSBT provides a universal interface for transaction signing. Libraries like rust-bitcoin, bitcoinjs-lib, and the Hardware Wallet Interface (HWI) all implement PSBT parsing and construction, making it straightforward to build applications that support any compliant signer. For platforms like Spark, which prioritize self-custody, PSBT-compatible tooling ensures users retain full control over their signing workflows.

Risks and Considerations

Input Validation

Signers must carefully validate PSBT data before signing. A malicious PSBT could misrepresent the transaction's outputs or fee level. For non-SegWit inputs in PSBT v0, the full previous transaction must be included so the signer can verify the input amounts. Without this verification, a signer could be tricked into signing a transaction with an inflated fee that effectively donates funds to miners.

Privacy Considerations

A PSBT contains extensive metadata: extended public keys, derivation paths, and UTXO data. If a PSBT is intercepted in transit, an observer learns which xpubs control which UTXOs and how a wallet's HD wallet is structured. For sensitive transactions, PSBTs should be transmitted over encrypted channels or physically secure media like SD cards.

Version Compatibility

Not all wallets support the same PSBT version or extensions. A PSBT created with v2 features cannot be processed by a v0-only wallet without conversion. Similarly, Taproot-specific fields (BIP-371) require signer support for Taproot. Users should verify that all parties in a signing workflow support the required PSBT version and field types before beginning.

Complexity in Advanced Workflows

While basic PSBT workflows are straightforward, advanced use cases involving Miniscript policies, threshold signatures, or interactive construction (PSBTv2) require careful coordination. Applications must track the state of each input, handle partial failures, and ensure all participants complete their roles before deadlines imposed by timelocks.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.