← Back to Bitcoin Improvement Proposals
BIP 174specificationDeployedwalletpsbtkey-managementtransactionssigning

Partially Signed Bitcoin Transaction Format

This document proposes a binary transaction format which contains the information necessary for a signer to produce signatures for the transaction and holds the signatures for an input while the input does not have a complete set of signatures. The signer can be offline as all necessary information will be provided in the transaction. The generic format is described here in addition to the specification for version 0 of this format.

No reviews
Ava Chow·Updated Mar 29, 2026·0 reviews·0 attestations·View source
Collections:BIPs — Merged

Specification

  BIP: 174
  Layer: Applications
  Title: Partially Signed Bitcoin Transaction Format
  Authors: Ava Chow 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174
  Status: Deployed
  Type: Specification
  Assigned: 2017-07-12
  License: BSD-2-Clause

Introduction

Abstract

This document proposes a binary transaction format which contains the information necessary for a signer to produce signatures for the transaction and holds the signatures for an input while the input does not have a complete set of signatures. The signer can be offline as all necessary information will be provided in the transaction.

The generic format is described here in addition to the specification for version 0 of this format.

Copyright

This BIP is licensed under the 2-clause BSD license.

Motivation

Creating unsigned or partially signed transactions to be passed around to multiple signers is currently implementation dependent, making it hard for people who use different wallet software from being able to easily do so. One of the goals of this document is to create a standard and extensible format that can be used between clients to allow people to pass around the same transaction to sign and combine their signatures. The format is also designed to be easily extended for future use which is harder to do with existing transaction formats.

Signing transactions also requires users to have access to the UTXOs being spent. This transaction format will allow offline signers such as air-gapped wallets and hardware wallets to be able to sign transactions without needing direct access to the UTXO set and without risk of being defrauded.

Specification

The Partially Signed Bitcoin Transaction (PSBT) format consists of key-value maps. Each map consists of a sequence of key-value records, terminated by a 0x00 byte .

:= * * := 0x70 0x73 0x62 0x74 0xFF := * 0x00 := * 0x00 := * 0x00 := := :=

Where:

; : A compact size unsigned integer representing the type. This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. There can be multiple entries with the same within a specific , but the must be unique. ; : The compact size unsigned integer containing the combined length of and ; : The compact size unsigned integer containing the length of (which must be exactly this many bytes). ; : Magic bytes which are ASCII for psbt followed by a separator of 0xFF. This integer must be serialized in most significant byte order.

The currently defined global types are as follows:

Name Description DescriptionVersions Requiring InclusionVersions Requiring ExclusionVersions Allowing InclusionParent BIP
Unsigned TransactionPSBT_GLOBAL_UNSIGNED_TX = 0x00NoneNo key dataThe transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses).020174
Extended Public KeyPSBT_GLOBAL_XPUB = 0x01The 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.<4 byte fingerprint> <32-bit little endian uint path element>*The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.0, 2174
Transaction VersionPSBT_GLOBAL_TX_VERSION = 0x02NoneNo key data<32-bit little endian int version>The 32-bit little endian signed integer representing the version number of the transaction being created. Note that this is not the same as the PSBT version number specified by the PSBT_GLOBAL_VERSION field.202370
Fallback LocktimePSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03NoneNo key data<32-bit little endian uint locktime>The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime.02370
Input CountPSBT_GLOBAL_INPUT_COUNT = 0x04NoneNo key dataCompact size unsigned integer representing the number of inputs in this PSBT.202370
Output CountPSBT_GLOBAL_OUTPUT_COUNT = 0x05NoneNo key dataCompact size unsigned integer representing the number of outputs in this PSBT.202370
Transaction Modifiable FlagsPSBT_GLOBAL_TX_MODIFIABLE = 0x06NoneNo key data<8-bit uint flags>An 8 bit little endian unsigned integer as a bitfield for various transaction modification flags. Bit 0 is the Inputs Modifiable Flag and indicates whether inputs can be modified. Bit 1 is the Outputs Modifiable Flag and indicates whether outputs can be modified. Bit 2 is the Has SIGHASH_SINGLE flag and indicates whether the transaction has a SIGHASH_SINGLE signature who's input and output pairing must be preserved. Bit 2 essentially indicates that the Constructor must iterate the inputs to determine whether and how to add an input.02370
Silent Payment Global ECDH SharePSBT_GLOBAL_SP_ECDH_SHARE = 0x07<33 byte scan key>The scan key that this ECDH share is for.<33 byte share>An ECDH share for a scan key. The ECDH shared is computed with a * B_scan, where a is the sum of all private keys of all eligible inputs, and B_scan is the scan key of a recipient.02375
Silent Payment Global DLEQ ProofPSBT_GLOBAL_SP_DLEQ = 0x08<33 byte scan key>The scan key that this proof covers.<64-byte proof>A BIP374 DLEQ proof computed for the matching ECDH share.02375
PSBT Version NumberPSBT_GLOBAL_VERSION = 0xFBNoneNo key data<32-bit little endian uint version>The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0.20, 2174
Proprietary Use TypePSBT_GLOBAL_PROPRIETARY = 0xFC Compact size unsigned integer of the length of the identifier, followed by identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself.Any value data as defined by the proprietary type user.0, 2174

The currently defined per-input types are defined as follows:

{| ! Name ! ! ! Description ! ! Description ! Versions Requiring Inclusion ! Versions Requiring Exclusion ! Versions Allowing Inclusion ! Parent BIP |- | Non-Witness UTXO | PSBT_IN_NON_WITNESS_UTXO = 0x00 | None | No key data | | The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO. | | | 0, 2 | 174 |- | Witness UTXO | PSBT_IN_WITNESS_UTXO = 0x01 | None | No key data | <64-bit little endian int amount> | The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO | | | 0, 2 | 174 |- | Partial Signature | PSBT_IN_PARTIAL_SIG = 0x02 | | The public key which corresponds to this signature. | | The signature as would be pushed to the stack from a scriptSig or witness. The signature should be a valid ECDSA signature corresponding to the pubkey that would return true when verified and not a value that would return false or be invalid otherwise (such as a NULLDUMMY). | | | 0, 2 | 174 |- | Sighash Type | PSBT_IN_SIGHASH_TYPE = 0x03 | None | No key data | <32-bit little endian uint sighash type> | The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature. | | | 0, 2 | 174 |- | Redeem Script | PSBT_IN_REDEEM_SCRIPT = 0x04 | None | No key data | | The redeemScript for this input if it has one. | | | 0, 2 | 174 |- | Witness Script | PSBT_IN_WITNESS_SCRIPT = 0x05 | None | No key data | | The witnessScript for this input if it has one. | | | 0, 2 | 174 |- | BIP 32 Derivation Path | PSBT_IN_BIP32_DERIVATION = 0x06 | | The public key | <4 byte fingerprint> <32-bit little endian uint path element>* | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input. | | | 0, 2 | 174 |- | Finalized scriptSig | PSBT_IN_FINAL_SCRIPTSIG = 0x07 | None | No key data | | The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. | | | 0, 2 | 174 |- | Finalized scriptWitness | PSBT_IN_FINAL_SCRIPTWITNESS = 0x08 | None | No key data | | The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. | | | 0, 2 | 174 |- | Proof-of-reserves commitment | PSBT_IN_POR_COMMITMENT = 0x09 | None | No key data | | The UTF-8 encoded commitment message string for the proof-of-reserves. See BIP 127 for more information. | | | 0, 2 | 127 |- | RIPEMD160 preimage | PSBT_IN_RIPEMD160 = 0x0a | <20-byte hash> | The resulting hash of the preimage | | The hash preimage, encoded as a byte vector, which must equal the key when run through the RIPEMD160 algorithm | | | 0, 2 | 174 |- | SHA256 preimage | PSBT_IN_SHA256 = 0x0b | <32-byte hash> | The resulting hash of the preimage | | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm | | | 0, 2 | 174 |- | HASH160 preimage | PSBT_IN_HASH160 = 0x0c | <20-byte hash> | The resulting hash of the preimage | | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm followed by the RIPEMD160 algorithm | | | 0, 2 | 174 |- | HASH256 preimage | PSBT_IN_HASH256 = 0x0d | <32-byte hash> | The resulting hash of the preimage | | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm twice | | | 0, 2 | 174 |- | Previous TXID | PSBT_IN_PREVIOUS_TXID = 0x0e | None | No key data | <32 byte txid> | 32 byte txid in standard byte order, not display byte order, of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent. | 2 | 0 | 2 | 370 |- | Spent Output Index | PSBT_IN_OUTPUT_INDEX = 0x0f | None | No key data | <32-bit little endian uint index> | 32 bit little endian integer representing the index of the output being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID. | 2 | 0 | 2 | 370 |- | Sequence Number | PSBT_IN_SEQUENCE = 0x10 | None | No key data |

[Content truncatedview full spec at source]

Discussion (0 threads)

Loading discussions...