PSBT

Anna wants to send Pavel 60 000 sat, sixty thousand of bitcoin’s smallest units. Her wallet uses one previously received, still unspent output worth 100 000 sat. An output records an amount and the conditions for spending it. In this example, the wallet proposes 60 000 sat for Pavel, 39 000 sat back to Anna as change, and leaves 1 000 sat as the fee. So far, these are only instructions. The application puts them in a PSBT and passes it to the hardware wallet, perhaps by cable, QR code or memory card, depending on the device. Anna checks the payment on its display and approves a signature. The signature returns, not the secret key. Preparing a payment therefore need not happen on the device authorized to sign it. [1] [4]

A file ending in .psbt is not automatically a safe payment. The computer that created it may be compromised or simply misconfigured. Anna checks the recipient against the address she obtained from Pavel, the amount, the total fee and the return of change to her own wallet. With a hardware wallet, she follows its trusted display and the manufacturer’s procedure. The signing software also verifies supporting data and what the signature commits to. The technical term sighash describes which parts of a transaction the signature protects against changes. An unusual mode is not something a beginner should approve without understanding it. If an address is wrong or the fee cannot be verified, review the proposal rather than bypassing the check. [1]

In a two-of-three Multisig wallet, Anna can add the first signature and Pavel the second, each using their own device. They need not exchange recovery words or be connected at the same time. A coordinator—the application organizing the process—collects material for the same payment and combines signatures. Each signer still has to check their own intent; the coordinator does not decide for them. BIP 174 names a creator that starts the proposal, an updater that adds data, a signer that signs, and a combiner that merges corresponding versions. A finalizer assembles the final data satisfying the input conditions, and an extractor produces the ordinary network transaction. One program commonly performs several roles. These names describe jobs, not six mandatory participants. [1] [4]

A PSBT can reveal which coins you plan to use, whom you are paying, how much change you receive and how addresses are connected. It may also contain an xpub, public data for deriving further public keys and, together with the wallet’s address rules, addresses, or derivation paths, the locations of keys within the wallet’s structure. Do not send it to a random web service just to decode it. A signed PSBT may also allow someone else to complete and broadcast the particular transaction you authorized, if all necessary material is available. Deleting your copy does not revoke the signature. Nor is the file a substitute for a Seed Phrase (the backup words used to recover keys) or a complete Multisig configuration backup: it supports a particular payment, not general wallet recovery. [1] [4]

Adding a signature does not mean the network knows about the payment. Once the final transaction is assembled, someone must broadcast it. A node is a computer running software that checks Bitcoin transactions and blocks. A node then assesses it against network rules and its transaction-acceptance policy; a miner may include it in a block. A missing signature, an already-spent input and an insufficient fee are different problems that a ‘complete’ button does not solve by itself. Test your particular combination of application, device and wallet type before relying on the process. In Bitcoin Core 29, analyzepsbt can show missing data or signatures. finalizepsbt can produce the completed transaction; sending it is a further step. Even successful completion is not a block confirmation. [4] [5] [6]

BIP 174 defines PSBT as a binary format with information stored in key–value pairs. Here, key means a field identifier, not automatically a Bitcoin private key. A global map describes the transaction as a whole, input maps describe the outputs being spent, and output maps describe the new outputs being created. Alongside the proposal, they may carry scripts—the spending conditions—key origins and partial signatures. The data can be saved as a .psbt file or represented using Base64, an encoding of binary data as text. Base64 is not encryption. PSBT is not a new transaction type under Bitcoin’s rules: the network receives the resulting transaction, not the whole working file. [1]

A device away from the network needs to know what it is being asked to sign. A UTXO is an earlier output that has not yet been spent; a new input refers to it. Non-Witness UTXO can carry the entire previous transaction, while Witness UTXO carries the particular output with its amount and conditions. The required evidence depends on the input type and the signing software’s rules. Checks include the previous transaction’s identifier and matching output, the relationships between scripts, and an acceptable sighash. A missing amount must not be treated as a zero fee, or missing evidence as successful verification. Supply the data through a trusted process rather than guessing it. [1]

The PSBT version describes the format’s layout, not the signature count or the version of the Bitcoin transaction itself. PSBT v0 stores the unsigned transaction in a global field; if the PSBT version is omitted, it means v0. PSBT v2, defined in BIP 370, excludes that field and separates the information needed to build a transaction into individual fields. This supports adding inputs and outputs subject to permitted changes and existing signatures. It does not mean a signed payment can be freely rewritten. Both sides must understand the version; ‘supports PSBT’ is not a precise enough compatibility statement. [2]

BIP 371 adds the information needed for Taproot, including its signatures, scripts and key origins. These fields work with both PSBT v0 and PSBT v2. A wallet can therefore handle Taproot in the first format without supporting the second. Equally, v2 support alone does not mean a device handles every Taproot scenario. Key-path signing and spending through a script branch are different ways to meet a Taproot output’s conditions. For a user, that leads to a straightforward question: can my particular setup handle the payment I want to sign? Documentation and a tested workflow answer that, not an acronym in a feature list. [3]