diff options
Diffstat (limited to 'bip-0174.mediawiki')
| -rw-r--r-- | bip-0174.mediawiki | 688 |
1 files changed, 334 insertions, 354 deletions
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 80c7284..c034f05 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -5,7 +5,7 @@ Author: Andrew Chow <achow101@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174 - Status: Proposed + Status: Final Type: Standards Track Created: 2017-07-12 License: BSD-2-Clause @@ -21,6 +21,9 @@ signatures for an input while the input does not have a complete set of signatur 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. @@ -48,272 +51,337 @@ is the separator here <tt>0x00</tt> instead of <tt>0xff</tt>?''' The separator here is used to distinguish between each chunk of data. A separator of 0x00 would mean that the unserializer can read it as a key length of 0, which would never occur with actual keys. It can thus be used as a separator and allow for easier unserializer implementation.</ref>. -Each key-value pair must have a unique key within its scope; duplicates are not allowed. The format -of a record is as follows: -Note: <tt><..></tt> indicates that the data is prefixed by a compact size unsigned integer representing -the length of that data. <tt>{..}</tt> indicates the raw data itself. -<pre> -<key>|<value> -</pre> + <psbt> := <magic> <global-map> <input-map>* <output-map>* + <magic> := 0x70 0x73 0x62 0x74 0xFF + <global-map> := <keypair>* 0x00 + <input-map> := <keypair>* 0x00 + <output-map> := <keypair>* 0x00 + <keypair> := <key> <value> + <key> := <keylen> <keytype> <keydata> + <value> := <valuelen> <valuedata> + +Where: + +;<tt><keytype></tt> +: 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. This must be unique within a specific <tt><map></tt>. +;<tt><keylen></tt> +: The compact size unsigned integer containing the combined length of <tt><keytype></tt> and <tt><keydata></tt> +;<tt><valuelen></tt> +: The compact size unsigned integer containing the length of <tt><valuedata></tt>. +;<tt><magic></tt> +: Magic bytes which are ASCII for psbt <ref>'''Why use 4 bytes for psbt?''' The +transaction format needed to start with a 5 byte header which uniquely identifies +it. The first bytes were chosen to be the ASCII for psbt because that stands for +Partially Signed Bitcoin Transaction. </ref> followed by a separator of <tt>0xFF</tt> +<ref>'''Why Use a separator after the magic bytes?''' The separator +is part of the 5 byte header for PSBT. This byte is a separator of <tt>0xff</tt> because +this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT +as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction +in the non-PSBT format will be able to be unserialized by a PSBT unserializer.</ref>. This integer must be serialized +in most significant byte order. + +The currently defined global types are as follows: -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Name -!Type -!Description +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +! Parent BIP |- -| Key Length -| Compact Size Unsigned Integer -| Specify how long the key is +| Unsigned Transaction +| <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt> +| None +| No key data +| <tt><transaction></tt> +| The 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). +| 0 +| +| 0 +| 174 |- -| Key -| byte[] -| The Key itself +| Extended Public Key +| <tt>PSBT_GLOBAL_XPUB = 0x01</tt> +| <tt><xpub></tt> +| The 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. +| <tt><32-bit uint> <32-bit uint>*</tt> +| 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 +| 174 |- -| Value Length -| Compact Size Unsigned Integer -| Specify how long the value is +| PSBT Version Number +| <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. +| +| +| 0 +| 174 |- -| Value -| byte[] -| The Value itself +| Proprietary Use Type +| <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 |} -The format of each key-value map is as follows: - -<pre> -{key-value pair}|{key-value pair}|...|{0x00} -</pre> +The currently defined per-input types are defined as follows: -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Field Size -!Name -!Type -!Value -!Description +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +! Parent BIP +|- +| Non-Witness UTXO +| <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> +| None +| No key data +| <tt><transaction></tt> +| 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref> +| +| +| 0 +| 174 +|- +| Witness UTXO +| <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> +| None +| No key data +| <tt><64-bit uint> <scriptPubKeylen> <scriptPubKey></tt> +| 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt> +| +| +| 0 +| 174 +|- +| Partial Signature +| <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> +| <tt><pubkey></tt> +| The public key which corresponds to this signature. +| <tt><signature></tt> +| The signature as would be pushed to the stack from a scriptSig or witness. +| +| +| 0 +| 174 +|- +| Sighash Type +| <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| 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 +| 174 +|- +| Redeem Script +| <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt> +| None +| No key data +| <tt><redeemScript></tt> +| The redeemScript for this input if it has one. +| +| +| 0 +| 174 +|- +| Witness Script +| <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt> +| None +| No key data +| <tt><witnessScript></tt> +| The witnessScript for this input if it has one. +| +| +| 0 +| 174 +|- +| BIP 32 Derivation Path +| <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt> +| <tt><pubkey></tt> +| The public key +| <tt><32-bit uint> <32-bit uint>*</tt> +| 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 +| 174 |- -| 1+ -| Key-value pairs -| Array of key-value pairs -| varies -| The key-value pairs. +| Finalized scriptSig +| <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> +| None +| No key data +| <tt><scriptSig></tt> +| The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. +| +| +| 0 +| 174 +|- +| Finalized scriptWitness +| <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt> +| None +| No key data +| <tt><scriptWitness></tt> +| The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. +| +| +| 0 +| 174 +|- +| Proof-of-reserves commitment +| <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> +| None +| No key data +| <tt><porCommitment></tt> +| The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. +| +| +| 0 +| [[bip-0127.mediawiki|127]] +|- +| RIPEMD160 preimage +| <tt>PSBT_IN_RIPEMD160 = 0x0a</tt> +| <tt><20-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm +| +| +| 0 +| 174 |- -| 1 -| separator -| char -| <tt>0x00</tt> -| Must be <tt>0x00</tt> at the end of the map. +| SHA256 preimage +| <tt>PSBT_IN_SHA256 = 0x0b</tt> +| <tt><32-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm +| +| +| 0 +| 174 +|- +| HASH160 preimage +| <tt>PSBT_IN_HASH160 = 0x0c</tt> +| <tt><20-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm followed by the <tt>RIPEMD160</tt> algorithm +| +| +| 0 +| 174 +|- +| HASH256 preimage +| <tt>PSBT_IN_HASH256 = 0x0d</tt> +| <tt><32-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice +| +| +| 0 +| 174 +|- +| Proprietary Use Type +| <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 |} -At the beginning of each key is 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. -For convenience, this BIP will specify types using their full serialization, so a multi-byte type will have it's full prefix and zero padding as necessary. -There are global types, per-input types, and per-output types. - -The currently defined global types are as follows: - -* Type: Unsigned Transaction <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x00}</tt> -** Value: The 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). A PSBT must have a transaction, otherwise it is invalid. -*** <tt>{transaction}</tt> -** Note: Every PSBT must have a field with this type. - -* Type: Extended Public Key <tt>PSBT_GLOBAL_XPUB = 0x01</tt> -** Key: The type followed by the 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. -*** <tt>{0x01}|{xpub}</tt> -** Value: 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. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Version Number <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0xFB}</tt> -** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. -*** <tt>{32-bit uint}</tt> - -* Type: Proprietary Use Type <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> - -The currently defined per-input types are defined as follows: - -* Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -***<tt>{0x00}</tt> -** Value: 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref> -*** <tt>{transaction}</tt> - -* Type: Witness UTXO <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x01}</tt> -** Value: 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt> -*** <tt>{serialized transaction output({output value}|<scriptPubKey>)}</tt> - -* Type: Partial Signature <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> -** Key: The public key which corresponds to this signature. -*** <tt>{0x02}|{public key}</tt> -** Value: The signature as would be pushed to the stack from a scriptSig or witness. -*** <tt>{signature}</tt> - -* Type: Sighash Type <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x03}</tt> -** Value: 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. -*** <tt>{sighash type}</tt> - -* Type: Redeem Script <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x04}</tt> -** Value: The redeemScript for this input if it has one. -*** <tt>{redeemScript}</tt> - -* Type: Witness Script <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x05}</tt> -** Value: The witnessScript for this input if it has one. -*** <tt>{witnessScript}</tt> - -* Type: BIP 32 Derivation Path <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt> -** Key: The public key -*** <tt>{0x06}|{public key}</tt> -** Value: 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. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Finalized scriptSig <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x07}</tt> -** Value: The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. -*** <tt>{scriptSig}</tt> - -* Type: Finalized scriptWitness <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x08}</tt> -** Value: The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. -*** <tt>{scriptWitness}</tt> - -* Type: Proof-of-reserves commitment <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x09}</tt> -** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. -*** <tt>{porCommitment}</tt> - -* Type: RIPEMD160 preimage <tt>PSBT_RIPEMD160 = 0x0a</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0a}|{20-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm -*** <tt>{preimage}</tt> - -* Type: SHA256 preimage <tt>PSBT_SHA256 = 0x0b</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0b}|{32-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm -*** <tt>{preimage}</tt> - -* Type: HASH160 preimage <tt>PSBT_HASH160 = 0x0c</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0c}|{20-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm followed by the `RIPEMD160` algorithm -*** <tt>{preimage}</tt> - -* Type: HASH256 preimage <tt>PSBT_HASH256 = 0x0d</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0d}|{32-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice -*** <tt>{preimage}</tt> - -* Type: Proprietary Use Type <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> - The currently defined per-output <ref>'''Why do we need per-output data?''' Per-output data allows signers to verify that the outputs are going to the intended recipient. The output data can also be use by signers to determine which outputs are change outputs and verify that the change is returning to the correct place.</ref> types are defined as follows: -* Type: Redeem Script <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x00}</tt> -** Value: The redeemScript for this output if it has one. -*** <tt>{redeemScript}</tt> - -* Type: Witness Script <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x01}</tt> -** Value: The witnessScript for this output if it has one. -*** <tt>{witnessScript}</tt> - -* Type: BIP 32 Derivation Path <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> -** Key: The public key -*** <tt>{0x02}|{public key}</tt> -** Value: The master key fingerprint 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. Public keys are those needed to spend this output. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Proprietary Use Type <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> - -The transaction format is specified as follows: - - -<pre> - {0x70736274}|{0xff}|{global key-value map}|{input key-value map}|...|{input key-value map}|{output key-value map}|...|{output key-value map}| -</pre> - -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Field Size -!Name -!Type -!Value -!Description -|- -| 4 -| Magic Bytes -| int32_t -| <tt>0x70736274</tt> -| Magic bytes which are ASCII for psbt. <ref>'''Why use 4 bytes for psbt?''' The -transaction format needed to start with a 5 byte header which uniquely identifies -it. The first bytes were chosen to be the ASCII for psbt because that stands for -Partially Signed Bitcoin Transaction. </ref> This integer should be serialized -in most significant byte order. +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +! Parent BIP |- -| 1 -| separator -| char -| <tt>0xff</tt> -| Must be <tt>0xff</tt> <ref>'''Why Use a separator after the magic bytes?''' The separator -is part of the 5 byte header for PSBT. This byte is a separator of <tt>0xff</tt> because -this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT -as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction -in the non-PSBT format will be able to be unserialized by a PSBT unserializer.</ref> +| Redeem Script +| <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt> +| None +| No key data +| <tt><redeemScript></tt> +| The redeemScript for this output if it has one. +| +| +| 0 +| 174 |- -| 1+ -| Global data -| Key-value Map -| varies -| The key-value pairs for all global data. +| Witness Script +| <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt> +| None +| No key data +| <tt><witnessScript></tt> +| The witnessScript for this output if it has one. +| +| +| 0 +| 174 |- -| 1+ -| Inputs -| Array of key-value maps -| varies -| The key-value pairs for each input as described above. Every input in the unsigned transaction must have a corresponding input map. +| BIP 32 Derivation Path +| <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> +| <tt><public key></tt> +| The public key +| <tt><{32-bit uint> <32-bit uint>*</tt> +| The master key fingerprint 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. Public keys are those needed to spend this output. +| +| +| 0 +| 174 |- -| 1+ -| Outputs -| Array of key-value maps -| varies -| The key-value pairs for each output as described above. Every output in the unsigned transaction must have a corresponding output map. +| Proprietary Use Type +| <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 |} -Each block of data between separators can be viewed as a scope, and all separators -are required<ref>'''Why are all separators required?''' The separators are required -so that the unserializer knows which input it is unserializing data for.</ref>. Types can be skipped when they are unnecessary. For example, if an input is a witness input, then it should not have a Non-Witness UTXO key-value pair. @@ -336,10 +404,10 @@ values are valid, then it does not matter which is chosen as either way the tran ===Proprietary Use Type=== For all global, per-input, and per-output maps, the types <tt>0xFC</tt> is reserved for proprietary use. -The proprietary use type requires keys that follow the type with a variable length string identifer, then a subtype. +The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data. The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it. -It can also be the empty string and just be a single <tt>0x00</tt> byte although this is not recommended. +It can also be the empty string although this is not recommended. The subtype is defined by the proprietary type user and can mean whatever they want it to mean. The subtype must also be a compact size unsigned integer in the same form as the normal types. @@ -350,9 +418,15 @@ It is useful when there are additional data that they need attached to a PSBT bu The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes. This type must be used for internal processes only. -==Responsibilities== +==Version 0== -Using the transaction format involves many different responsibilities. Multiple responsibilities can be handled by a single entity, but each responsibility is specialized in what it should be capable of doing. +Partially Signed Bitcoin Transactions version 0 is the first version of the PSBT format. +Version 0 PSBTs must either omit PSBT_GLOBAL_VERSION or include it and set it to 0. +Version 0 PSBTs must include PSBT_GLOBAL_UNSIGNED_TX, if omitted, the PSBT is invalid. + +==Roles== + +Using the transaction format involves many different roles. Multiple roles can be handled by a single entity, but each role is specialized in what it should be capable of doing. ===Creator=== @@ -373,7 +447,7 @@ The Signer must only accept a PSBT. The Signer must only use the UTXOs provided in the PSBT to produce signatures for inputs. Before signing a non-witness input, the Signer must verify that the TXID of the non-witness UTXO matches the TXID specified in the unsigned transaction. Before signing a witness input, the Signer must verify that the witnessScript (if provided) matches the hash specified in the UTXO or the redeemScript, and the redeemScript (if provided) matches the hash in the UTXO. -The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO<tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref> +The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO</tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref> The Signer should not need any additional data sources, as all necessary information is provided in the PSBT format. The Signer must only add data to a PSBT. Any signatures created by the Signer must be added as a "Partial Signature" key-value pair for the respective input it relates to. @@ -509,6 +583,18 @@ Updaters and combiners that need to add a version number to a PSBT should use th For example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1. If an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified. +===Procedure For New Fields=== + +New fields should first be proposed on the bitcoin-dev mailing list. +If a field requires significatn description as to its usage, it should be accompanied by a separate BIP. +The field must be added to the field listing tables in the Specification section. + +===Procedure For New Versions=== + +New PSBT versions must be described in a separate BIP. +The BIP may reference this BIP and any components of PSBT version 0 that are retained in the new version. +Any new fields described in the new version must be added to the field listing tables in the Specification section. + ==Compatibility== This transaction format is designed so that it is unable to be properly unserialized @@ -757,109 +843,3 @@ and for coming up with the name and abbreviation of PSBT. Thanks to Pieter Wuille, Gregory Maxwell, Jonathan Underwood, Daniel Cousens and those who commented on the bitcoin-dev mailing list for additional comments and suggestions for improving this proposal. - -==Appendix A: Data types and their specifications== - -Any data types, their associated scope and BIP number must be defined here - -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Scope -!Type values -!Name -!BIP Number -|- -| Global -| 0 -| PSBT_GLOBAL_UNSIGNED_TX -| BIP 174 -|- -| Global -| 1 -| PSBT_GLOBAL_XPUB -| BIP 174 -|- -| Global -| 251 -| PSBT_GLOBAL_VERSION -| BIP 174 -|- -| Global -| 252 -| PSBT_GLOBAL_PROPRIETARY -| BIP 174 -|- -| Input -| 0 -| PSBT_IN_NON_WITNESS_UTXO -| BIP 174 -|- -| Input -| 1 -| PSBT_IN_WITNESS_UTXO -| BIP 174 -|- -| Input -| 2 -| PSBT_IN_PARTIAL_SIG -| BIP 174 -|- -| Input -| 3 -| PSBT_IN_SIGHASH_TYPE -| BIP 174 -|- -| Input -| 4 -| PSBT_IN_REDEEM_SCRIPT -| BIP 174 -|- -| Input -| 5 -| PSBT_IN_WITNESS_SCRIPT -| BIP 174 -|- -| Input -| 6 -| PSBT_IN_BIP32_DERIVATION -| BIP 174 -|- -| Input -| 7 -| PSBT_IN_FINAL_SCRIPTSIG -| BIP 174 -|- -| Input -| 8 -| PSBT_IN_FINAL_SCRIPTWITNESS -| BIP 174 -|- -| Input -| 9 -| PSBT_IN_POR_COMMITMENT -| [[bip-0127.mediawiki|BIP 127]] -|- -| Input -| 252 -| PSBT_IN_PROPRIETARY -| BIP 174 -|- -| Output -| 0 -| PSBT_OUT_REDEEM_SCRIPT -| BIP 174 -|- -| Output -| 1 -| PSBT_OUT_WITNESS_SCRIPT -| BIP 174 -|- -| Output -| 2 -| PSBT_OUT_BIP32_DERIVATION -| BIP 174 -|- -| Output -| 252 -| PSBT_OUT_PROPRIETARY -| BIP 174 -|} |