PSBT (Partially Signed Bitcoin Transaction)

What Is a PSBT?

A Partially Signed Bitcoin Transaction (PSBT) is a standardized data format defined in BIP 174 that allows multiple parties or devices to collaboratively construct and sign a Bitcoin transaction. Before PSBTs, there was no universal way to pass an incomplete transaction between wallets, hardware signers, and coordination software. Each tool had its own proprietary format, making interoperability difficult.

PSBTs solve this by defining a container format that carries all the information needed to sign a transaction: the unsigned transaction itself, the UTXOs being spent, their scripts, derivation paths, and any partial signatures collected so far. A PSBT can be passed from one signer to the next, with each adding their signature, until the transaction is fully signed and ready for broadcast.

Think of a PSBT like a contract that circulates among signatories: the document contains all the terms (transaction details), and each party adds their signature in turn. Once all required signatures are collected, the contract is finalized and executed.

How It Works

The PSBT workflow is organized around six distinct roles. These roles can be performed by the same software or distributed across completely separate devices and parties:

The Six Roles

1. Creator: constructs the base unsigned transaction with the desired inputs and outputs. The creator determines which UTXOs to spend and where to send the funds, but does not add any signing metadata yet.
2. Updater: attaches the information signers will need. This includes the full previous transaction or UTXO data for each input, redeem scripts, witness scripts, BIP 32 derivation paths, and any other data required for signing. Multiple updaters can contribute information for different inputs.
3. Signer: inspects the PSBT, verifies the transaction details (amounts, destinations, fees), and adds a partial signature for the inputs they control. A signer only needs access to its own private keys and the PSBT data: it never sees other signers' keys.
4. Combiner: merges multiple PSBTs that contain different partial signatures for the same underlying transaction. This role is needed when signers work in parallel rather than passing a single PSBT sequentially.
5. Finalizer: collects all partial signatures for each input and assembles the final scriptSig or witness data. The finalizer determines whether enough signatures have been collected to satisfy each input's spending conditions.
6. Extractor: takes the finalized PSBT and produces the complete, network-serialized transaction ready for broadcast to the Bitcoin network.

PSBT Data Structure

A PSBT contains a global section and per-input/per-output maps. Each section stores key-value pairs with specific types:

PSBT Structure:
├── Global
│   ├── Unsigned Transaction (raw tx without scriptSig/witness)
│   ├── Extended Public Keys (xpubs for derivation)
│   └── Version Number
├── Per-Input Maps (one per transaction input)
│   ├── Non-Witness UTXO (full previous transaction)
│   ├── Witness UTXO (previous output being spent)
│   ├── Partial Signatures (pubkey → signature pairs)
│   ├── Sighash Type
│   ├── Redeem Script (for P2SH inputs)
│   ├── Witness Script (for P2WSH inputs)
│   ├── BIP 32 Derivation Paths (key origin info)
│   └── Final ScriptSig / Final Script Witness
└── Per-Output Maps (one per transaction output)
    ├── Redeem Script (for P2SH outputs)
    ├── Witness Script (for P2WSH outputs)
    └── BIP 32 Derivation Paths (for change outputs)

The format uses a binary encoding prefixed with the magic bytes 0x70736274ff (the ASCII string "psbt" followed by a separator). For transport between devices, PSBTs are typically encoded as Base64 strings, QR codes, or transmitted via files and NFC.

Example Workflow

Here is how a 2-of-3 multisig transaction is constructed using PSBTs with Bitcoin Core:

# 1. Creator: build the unsigned transaction
bitcoin-cli createpsbt \
  '[{"txid":"abc123...","vout":0}]' \
  '[{"bc1q...":0.5},{"bc1q...":0.499}]'

# 2. Updater: add UTXO data and derivation paths
bitcoin-cli utxoupdatepsbt "cHNidP8B..."

# 3. Signer A: sign with first key
bitcoin-cli walletprocesspsbt "cHNidP8B..."

# 4. Signer B: sign with second key (on a different device)
bitcoin-cli walletprocesspsbt "cHNidP8B..."

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

# 6. Finalizer + Extractor: finalize and extract raw tx
bitcoin-cli finalizepsbt "cHNidP8B...combined"
# Returns: {"hex":"0200000001...", "complete":true}

# 7. Broadcast the final transaction
bitcoin-cli sendrawtransaction "0200000001..."

Each signer only needs the PSBT data and their own private key. Signer A and Signer B can operate on completely separate machines (including hardware signing devices) without any network connection between them.

PSBT Version 2

BIP 370 introduced PSBT version 2 (PSBTv2), which addresses several limitations of the original format. The key improvement: PSBTv2 removes the global unsigned transaction and instead stores transaction fields (version, locktime, inputs, outputs) directly in the PSBT maps. This enables important new capabilities:

• Inputs and outputs can be added or removed after creation, enabling interactive protocols like CoinJoin where multiple participants contribute inputs and outputs incrementally
• Transaction construction becomes truly collaborative: participants do not need to agree on all inputs and outputs upfront before the PSBT is created
• Better support for Taproot key paths and script paths through additional field types defined in BIP 371
• Compatibility with protocols that require modifying the transaction structure during the signing process, such as splicing operations on Lightning channels

Use Cases

Hardware Wallet Signing

The most common PSBT use case is coordinating between a software wallet (which manages UTXOs and constructs transactions) and a hardware signing device (which holds private keys offline). The software wallet creates and updates the PSBT, the user transfers it to the hardware device via USB, QR code, or SD card, the device signs it, and the signed PSBT returns to the software wallet for finalization and broadcast.

This workflow ensures private keys never leave the hardware device. The PSBT carries all the context the device needs to verify the transaction and produce a valid signature, without requiring the device to have any network access or blockchain state.

Multisig Coordination

PSBTs are the standard way to coordinate multisig transactions. In a multisig setup, multiple keys must sign the same transaction. PSBTs allow the transaction to be passed between signers (sequentially or in parallel) with each adding their signature. The combiner then merges all partial signatures before finalization.

For threshold signature schemes, PSBTs serve a similar coordination role. Even though the underlying cryptography differs (threshold signatures produce a single combined signature rather than multiple individual signatures), the PSBT format provides a common container for exchanging transaction data and partial signing artifacts between participants.

CoinJoin and Collaborative Transactions

CoinJoin transactions combine inputs from multiple unrelated users into a single transaction to improve privacy. PSBTv2 is particularly useful here because participants can add their inputs and outputs incrementally without needing a trusted coordinator to hold the complete transaction. Each participant signs only after verifying that their outputs are included and correct.

Airgapped and Offline Signing

For high-security cold storage setups, PSBTs enable fully airgapped transaction signing. The online (watch-only) wallet constructs the PSBT, which is then transferred to the offline signing device via QR code or removable media. The signed PSBT is transferred back and broadcast. At no point does the signing device connect to a network.

Layer 2 Protocols

PSBTs play a role in various layer 2 constructions. For example, Lightning channel opening and closing transactions can be coordinated using PSBTs, especially when splicing is involved. The Spark protocol and similar systems also leverage PSBT-compatible workflows when interacting with the Bitcoin base layer.

Risks and Considerations

UTXO Data Verification

One of the most important security properties of PSBTs is that signers can verify exactly what they are signing. However, this depends on the PSBT containing accurate UTXO data. A malicious updater could provide incorrect UTXO amounts, tricking the signer into approving a transaction that pays excessive fees. BIP 174 mitigates this for segwit inputs by including the witness UTXO (just the previous output), but for legacy inputs, the full previous transaction must be included so the signer can verify amounts independently.

Fee Manipulation

Signers should always calculate and verify the transaction fee before signing. The fee is the difference between total input value and total output value. Without careful verification, a signer might approve a transaction where the fee is much higher than expected, effectively donating funds to miners. Modern hardware wallets display the fee prominently, but software implementations must also enforce this check.

Replay and Substitution Attacks

PSBTs can be intercepted and modified in transit if the communication channel between participants is not secure. An attacker could substitute output addresses or alter amounts. Signers should verify all transaction details (recipient addresses, amounts, change outputs) on a trusted display before signing. For multisig setups, each signer should independently verify the transaction rather than trusting that a previous signer already checked it.

State Management

Applications that work with PSBTs must carefully track the state of each transaction through the workflow. A PSBT might be partially signed by some parties but not others, or it might be an older version that has been superseded. Accidentally broadcasting a stale or incomplete transaction can lead to fund loss. Robust PSBT management requires versioning, deduplication, and clear status tracking throughout the signing lifecycle.

Privacy Considerations

PSBTs contain detailed information about the transaction and its inputs, including derivation paths and extended public keys. Sharing a PSBT with untrusted parties can leak information about your wallet structure, balance, and address derivation scheme. In privacy-sensitive contexts, minimize the metadata included in PSBTs and share them only through encrypted channels.

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.