PSBT v2

Anna and Jan want to pay one invoice together. Each contributes some funds and adds a signature on their own device. They need to exchange an agreed proposal, not their private keys. A private key is a secret number a wallet uses to create a digital signature authorising a spend. PSBT provides a working envelope containing the transaction and supporting information. Inputs identify earlier amounts being spent; outputs specify new amounts and the conditions for spending them later. The original PSBT v0 stores this structure in a fixed global unsigned transaction. In v2, inputs and outputs can be added progressively under the relevant rules. The benefit is collaborative construction, not permission to rewrite whatever someone has already signed. [1] [2]

Anna need not read every technical field. On a trusted signing device, she should verify the actual recipient, amount, fee and any change returning to her own wallet. That last item is easy to overlook: someone else’s output must not be mistaken for her change. The device must check the supporting UTXO data—information about outputs that have not yet been spent—and whether their conditions agree with what it signs. A key derivation path describes the steps a wallet follows to obtain a particular key from its master key. A claimed key derivation path does not establish ownership by itself. The signing device must also correctly interpret SIGHASH, the setting that determines which parts of a transaction a signature protects. Signing does not require adding a private key or Seed Phrase, the wallet’s backup words, to the exchanged file. [2] [4]

A device or application advertising PSBT support does not necessarily support v2. Check the complete workflow: creation, import, signing and returning the result between the particular programs and devices involved. PSBT v0 and v2 are not directly interchangeable. Conversion to v0 requires constructing an unsigned transaction and adjusting fields to that version’s rules; changing a number is not enough. Taproot, a newer way to define Bitcoin output spending conditions, is also distinct from v2. BIP 371 specifies its signing data for both PSBT versions. A small end-to-end trial establishes compatibility for that setup, not the correctness of every future payment. [1] [3]

The file format’s version and the Bitcoin transaction’s version mean different things. In v2, PSBT_GLOBAL_VERSION must contain 2, while the old PSBT_GLOBAL_UNSIGNED_TX field must be absent. A separate required field, PSBT_GLOBAL_TX_VERSION, gives the transaction’s own version. Input and output counts are also required. This separation keeps information with each individual item rather than making software look in a shared transaction structure as well. If the creator hands construction to other participants, BIP 370 requires the appropriate modification flags and a transaction version of at least 2. Throughout, this is a working format, not a new set of network consensus rules. [1]

Each input needs a TXID, the identifier of the previous transaction, and the index of the particular output being spent from it. The TXID alone is insufficient: a transaction can have several outputs. Each new output carries an amount in satoshi, Bitcoin’s smallest units, and scriptPubKey, the script defining its spending conditions. Adding an item must also update its global count. The optional sequence field carries another input control value; if absent, 0xffffffff is used. These construction fields describe how to assemble the transaction. They do not replace the value and spending-condition data for the UTXOs being spent, which the device needs to assess signing and fees safely. [1]

Suppose Jan needs to add another input. Software must not assume it can do so merely because it has the file. In PSBT_GLOBAL_TX_MODIFIABLE, bit 0 indicates whether inputs may change and bit 1 whether outputs may change. Bit 2 signals a SIGHASH_SINGLE signature, which pairs an input with the output at the corresponding position. That pairing must survive insertion of additional items. The constructor therefore examines actual signatures and their restrictions. Flags communicate information to cooperating programs; they cannot bypass a cryptographic signature or turn an invalid change into a valid one. [1]

Some inputs require a transaction to wait for a particular block height or time boundary. A block is a group of transactions recorded in the network’s shared history; its height indicates its position in the chain. The shared nLockTime field must use a requirement type compatible with every input. The highest required value of that type is selected; if both types are possible, block height takes precedence. Height and time cannot simply be compared as two ordinary numbers. If no input has a requirement, the global fallback value is used, or 0 if it is absent. An input with an incompatible requirement must not be added. Once signatures exist, a new input must also leave the calculated nLockTime unchanged. These fields alone do not ensure that every timelock rule is satisfied. [1]

A signature progressively restricts further editing. BIP 370 requires the signer to disable input changes without SIGHASH_ANYONECANPAY and output changes without SIGHASH_NONE, and to record the required pairing for SIGHASH_SINGLE. These names describe different scopes of signature protection, not switches for a beginner to toggle at random. Once all inputs are ready, finalisation assembles the required signing data and an extractor constructs the network-format transaction from the fields. Only broadcasting lets nodes assess it and a miner include it in a block. Anna and Jan therefore distinguish a proposal, a signed result and a confirmed payment; exchanging a PSBT alone establishes neither of the latter two. [1] [2] [4]