PSBT and Air-Gapped Signing: Keep Keys Offline While the Network Watches

Self-custody fails open when the same network-exposed machine that builds and broadcasts a spend also holds the keys that authorise it. Phishing, clipboard malware, and a compromised host OS all share one property: they live where the network lives. If signing material lives there too, “not your keys” collapses into “not your outcome.”

BIP 174 — Partially Signed Bitcoin Transaction Format — is the separation protocol. A PSBT carries enough information for a signer to produce valid signatures without needing direct access to the UTXO set, and without requiring the private keys to sit on the machine that talks to peers. The online side can watch, construct, and later broadcast. The offline side can sign. The packet in between is the contract both sides share.

This note is educational protocol literacy. It sits beside — and does not rewrite — the companion note on verify-before-trust. PSBT is how keys stay cold; verification is how you notice when either side is lying.

What a PSBT actually is

BIP 174 defines a binary format of key-value maps: one global map, then a map per input, then a map per output. Magic bytes psbt plus 0xFF mark the object so a normal transaction parser fails closed instead of mistaking a PSBT for a network transaction. Version 0 PSBTs must include a global unsigned transaction with empty scriptSigs and witnesses. Fields that a participant does not understand are passed through unchanged — the format is designed to be extended without breaking older signers.

What the packet commonly carries (in BIP 174’s own terms):

• Global: the unsigned transaction; optional BIP 32 extended public keys with master fingerprints and derivation paths; optional PSBT version.
• Per input: non-witness and/or witness UTXO data; partial signatures keyed by public key; sighash type; redeemScript / witnessScript; BIP 32 derivation paths for keys that must sign; later, finalized scriptSig / scriptWitness.
• Per output: redeem/witness scripts and BIP 32 paths so a signer can verify destinations and recognise change.

Encoding is binary (.psbt) or Base64. The point is that the signer should need only what is inside the PSBT, not a live chain connection.

BIP 370 (PSBTv2) later lets inputs and outputs be added after creation by dropping the fixed global unsigned transaction. Air-gapped single-signer flows still speak the BIP 174 role model; treat v2 as evolution, not a different philosophy.

Roles: who does what

BIP 174 names specialised roles. One device or program can play several; the names exist so implementations agree on invariants.

1. Creator — builds a new PSBT with an unsigned transaction and empty input/output maps.
2. Updater — adds UTXOs, scripts, and BIP 32 paths it knows. A watch-only wallet is typically Creator + Updater.
3. Signer — accepts only a PSBT; uses only the UTXOs provided in it; verifies prevout hashes / script commitments before signing; adds partial signatures; must not invent missing chain data from a side channel the host controls.
4. Combiner — merges one or more PSBTs for the same unsigned transaction (multisig, parallel updaters).
5. Input Finalizer — when enough signatures exist, constructs finalized scriptSig / scriptWitness and clears intermediate fields.
6. Transaction Extractor — emits a network-serialized transaction ready to broadcast when every input is finalized.

Bitcoin Core’s wallet RPCs map onto this pipeline: walletcreatefundedpsbt / converttopsbt for create+update, walletprocesspsbt for update/sign/finalize, plus combinepsbt, finalizepsbt, and analyzepsbt for the next role. The RPC surface shows the roles are real, not marketing.

Air-gapped flow in plain steps

1. Online watch-only (Creator/Updater) selects coins and destinations it can see, funds fees/change, and embeds UTXO and derivation metadata into a PSBT.
2. Export the PSBT across an air gap — QR frames, microSD, or another offline transport that does not require the signing device to open a socket.
3. Offline signing device (Signer) parses the PSBT, checks UTXO commitments against the unsigned inputs, computes amounts and fee from the provided data, and displays destinations on a screen the host cannot rewrite.
4. Human confirmation on that trusted display — every character of external destinations, not a truncated middle.
5. Return the PSBT now carrying partial signatures across the same air gap.
6. Online Finalizer/Extractor completes scripts and broadcasts the extracted raw transaction.

The private keys never touch the network-facing machine. The network-facing machine never needs them to build a valid unsigned skeleton. That is the whole design.

Why host/device disagreement and transport matter

BIP 174’s motivation section is blunt: offline signers should sign without risk of being defrauded by incomplete or hostile context. The Signer checks are mechanical — non-witness UTXO hash must match the prevout; redeemScript / witnessScript must match the UTXO or redeemScript hash; unacceptable sighash types must fail closed. Many wallets also require full previous transactions for segwit inputs so other inputs’ amounts cannot be tweaked into a fee-drain pattern (the BIP 143-related concern called out in BIP 174).

None of that helps if the human rubber-stamps a laptop screen. Clipboard malware and poisoned history rewrite what the host shows; they do not rewrite a second channel on an offline device — unless you ignore disagreement. If the device and the host disagree about destination or amount, stop. Same verify-before-trust habit, different costume.

Transport is part of the threat model. QR and SD-card paths keep the signer offline; they also add surfaces — malicious frames, swapped cards, incomplete multi-part QRs. Treat the carrier as untrusted bytes until the device’s parser and display say otherwise. Unknown-field pass-through resists “simplified” stripping, but an attacker can still hand you a different PSBT than the one you exported. Re-check on the builder after signing when tooling allows.

Limitations — what PSBT does not fix alone

PSBT does not verify that the watch-only software is the binary you intended. It does not stop you from confirming a poisoned destination you pasted from history. It does not heal a seed entered into a phishing page “to sync.” It does not make multisig policy honest if cosigners are coerced or offline devices are seeded from a compromised host.

In short: separation of signing from networking is necessary and not sufficient. Software integrity, address hygiene, and threat-model clarity remain the job of verify-before-trust. PSBT gives the offline device honest inputs to those habits; it does not replace them.

Civil-liberty stakes travel globally without geography theatre. When the internet-facing device is treated as hostile — shared machines, invasive endpoint monitoring, seizure-prone laptops, or a phone that must stay online — offline signing is resilience infrastructure. Keep authorisation material where sockets are not. That does not defeat every adversary; it shrinks the blast radius of the ones that live on the wire.

What this is not

This note is not a hardware-wallet shopping guide, brand ranking, or vendor setup tutorial. It does not discuss prices, yields, swaps, or “where to buy.” It does not give personalised custody advice, recovery services, or trading signals. It does not claim air gaps are absolute — side channels, supply-chain firmware, and operator error remain. It does not equate Base64 PSBT strings with privacy, nor treat Bitcoin Core RPC names as a product endorsement. It does not teach evasion of lawful process.

Educational takeaway: self-custody that shares a network stack with its keys is a single fault domain. BIP 174’s PSBT roles exist so building and broadcasting can stay online while signing stays offline — with enough structured data that the offline signer can check before it commits. The mechanisms are public, boring, and learnable. That is why they beat slogans.

Related on CryptoDecentral

• Self-custody & wallets pillar
• Self-Custody Without Verify-Before-Trust Is a Slogan
• Network metrics

Further reading (primary)

• BIP 174 — Partially Signed Bitcoin Transaction Format (raw)
• BIP 174 on GitHub
• BIP 370 — PSBT Version 2 (raw)
• Bitcoin Core — walletprocesspsbt
• Bitcoin developer reference — analyzepsbt