diff options
Diffstat (limited to 'bip-0174.mediawiki')
| -rw-r--r-- | bip-0174.mediawiki | 161 |
1 files changed, 72 insertions, 89 deletions
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index d70a7f1..6a5d5e8 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -65,7 +65,7 @@ be used as a separator and allow for easier unserializer implementation.</ref>. 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. There can be multiple entries with the same <tt><keytype></tt> within a specific <tt><map></tt>, but the <tt><key></tt> must be unique. +: A [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer 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 <tt><keytype></tt> within a specific <tt><map></tt>, but the <tt><key></tt> must be unique. ;<tt><keylen></tt> : The compact size unsigned integer containing the combined length of <tt><keytype></tt> and <tt><keydata></tt> ;<tt><valuelen></tt> @@ -98,18 +98,18 @@ The currently defined global types are as follows: | <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt> | None | No key data -| <tt><transaction></tt> +| <tt><bytes 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 -| +| 2 | 0 | 174 |- | Extended Public Key | <tt>PSBT_GLOBAL_XPUB = 0x01</tt> -| <tt><xpub></tt> +| <tt><bytes 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> +| <tt><4 byte fingerprint> <32-bit little endian uint path element>*</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. | | @@ -120,7 +120,7 @@ The currently defined global types are as follows: | <tt>PSBT_GLOBAL_TX_VERSION = 0x02</tt> | None | No key data -| <tt><32-bit uint></tt> +| <tt><32-bit little endian int version></tt> | 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. | 2 | 0 @@ -131,7 +131,7 @@ The currently defined global types are as follows: | <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03</tt> | None | No key data -| <tt><32-bit uint></tt> +| <tt><32-bit little endian uint locktime></tt> | The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime. | | 0 @@ -142,7 +142,7 @@ The currently defined global types are as follows: | <tt>PSBT_GLOBAL_INPUT_COUNT = 0x04</tt> | None | No key data -| <tt><compact size uint></tt> +| <tt><compact size uint input count></tt> | Compact size unsigned integer representing the number of inputs in this PSBT. | 2 | 0 @@ -153,7 +153,7 @@ The currently defined global types are as follows: | <tt>PSBT_GLOBAL_OUTPUT_COUNT = 0x05</tt> | None | No key data -| <tt><compact size uint></tt> +| <tt><compact size uint input count></tt> | Compact size unsigned integer representing the number of outputs in this PSBT. | 2 | 0 @@ -164,19 +164,8 @@ The currently defined global types are as follows: | <tt>PSBT_GLOBAL_TX_MODIFIABLE = 0x06</tt> | None | No key data -| <tt><single byte boolean> <single byte boolean> <bitvector></tt> -| A single byte boolean (0 for False, 1 for True) representing whether inputs can be modified, followed by a single byte boolean representing whether outputs can be modified. -| -| 0 -| 2 -| [[bip-0370.mediawiki|370]] -|- -| SIGHASH_SINGLE Inputs -| <tt>PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS = 0x07</tt> -| None -| No key data -| <tt><bit vector></tt> -| A bit vector representing which input indexes use SIGHASH_SINGLE. If the bit for an index is set to 1, then the input and output pair at that index are tied together with SIGHASH_SINGLE and must be moved together. +| <tt><8-bit uint flags></tt> +| 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. | | 0 | 2 @@ -186,7 +175,7 @@ The currently defined global types are as follows: | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> | None | No key data -| <tt><32-bit uint></tt> +| <tt><32-bit little endian uint version></tt> | The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0. | | @@ -195,9 +184,9 @@ The currently defined global types are as follows: |- | 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> +| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt> +| 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. +| <tt><bytes data></tt> | Any value data as defined by the proprietary type user. | | @@ -223,7 +212,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> | None | No key data -| <tt><transaction></tt> +| <tt><bytes 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> | | @@ -234,7 +223,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> | None | No key data -| <tt><64-bit int> <scriptPubKeylen> <scriptPubKey></tt> +| <tt><64-bit little endian int amount> <compact size uint scriptPubKeylen> <bytes 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> | | @@ -243,10 +232,10 @@ The currently defined per-input types are defined as follows: |- | Partial Signature | <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> -| <tt><pubkey></tt> +| <tt><bytes 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. +| <tt><bytes signature></tt> +| 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 @@ -256,7 +245,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt> | None | No key data -| <tt><32-bit uint></tt> +| <tt><32-bit little endian uint sighash type></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. | | @@ -267,7 +256,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt> | None | No key data -| <tt><redeemScript></tt> +| <tt><bytes redeemScript></tt> | The redeemScript for this input if it has one. | | @@ -278,7 +267,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt> | None | No key data -| <tt><witnessScript></tt> +| <tt><bytes witnessScript></tt> | The witnessScript for this input if it has one. | | @@ -287,9 +276,9 @@ The currently defined per-input types are defined as follows: |- | BIP 32 Derivation Path | <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt> -| <tt><pubkey></tt> +| <tt><bytes pubkey></tt> | The public key -| <tt><32-bit uint> <32-bit uint>*</tt> +| <tt><4 byte fingerprint> <32-bit little endian uint path element>*</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. | | @@ -300,7 +289,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> | None | No key data -| <tt><scriptSig></tt> +| <tt><bytes scriptSig></tt> | The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. | | @@ -311,7 +300,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt> | None | No key data -| <tt><scriptWitness></tt> +| <tt><bytes scriptWitness></tt> | The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. | | @@ -322,7 +311,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> | None | No key data -| <tt><porCommitment></tt> +| <tt><bytes porCommitment></tt> | The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. | | @@ -333,7 +322,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_RIPEMD160 = 0x0a</tt> | <tt><20-byte hash></tt> | The resulting hash of the preimage -| <tt><preimage></tt> +| <tt><bytes preimage></tt> | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm | | @@ -344,7 +333,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_SHA256 = 0x0b</tt> | <tt><32-byte hash></tt> | The resulting hash of the preimage -| <tt><preimage></tt> +| <tt><bytes preimage></tt> | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm | | @@ -355,7 +344,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_HASH160 = 0x0c</tt> | <tt><20-byte hash></tt> | The resulting hash of the preimage -| <tt><preimage></tt> +| <tt><bytes 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 | | @@ -366,7 +355,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_HASH256 = 0x0d</tt> | <tt><32-byte hash></tt> | The resulting hash of the preimage -| <tt><preimage></tt> +| <tt><bytes preimage></tt> | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice | | @@ -377,7 +366,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_PREVIOUS_TXID = 0x0e</tt> | None | No key data -| <tt><txid></tt> +| <tt><32 byte txid></tt> | 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent. | 2 | 0 @@ -388,7 +377,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_OUTPUT_INDEX = 0x0f</tt> | None | No key data -| <tt><32-bit uint></tt> +| <tt><32-bit little endian uint index></tt> | 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 @@ -399,7 +388,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_SEQUENCE = 0x10</tt> | None | No key data -| <tt><32-bit uint></tt> +| <tt><32-bit little endian uint sequence></tt> | The 32 bit unsigned little endian integer for the sequence number of this input. If omitted, the sequence number is assumed to be the final sequence number (0xffffffff). | | 0 @@ -410,7 +399,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11</tt> | None | No key data -| <tt><32-bit uint></tt> +| <tt><32-bit little endian uint locktime></tt> | 32 bit unsigned little endian integer greater than or equal to 500000000 representing the minimum Unix timestamp that this input requires to be set as the transaction's lock time. | | 0 @@ -421,7 +410,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12</tt> | None | No key data -| <tt><32-bit uiht></tt> +| <tt><32-bit uint locktime></tt> | 32 bit unsigned little endian integer less than 500000000 representing the minimum block height that this input requires to be set as the transaction's lock time. | | 0 @@ -431,8 +420,8 @@ The currently defined per-input types are defined as follows: | Taproot Key Spend Signature | <tt>PSBT_IN_TAP_KEY_SIG = 0x13</tt> | None -| No key data -| <tt><signature></tt> +| No key data +| <tt><64 or 65 byte signature></tt> | The 64 or 65 byte Schnorr signature for key path spending a Taproot output. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. | | @@ -441,9 +430,9 @@ The currently defined per-input types are defined as follows: |- | Taproot Script Spend Signature | <tt>PSBT_IN_TAP_SCRIPT_SIG = 0x14</tt> -| <tt><xonlypubkey> <leafhash></tt> +| <tt><32 byte xonlypubkey> <leafhash></tt> | A 32 byte X-only public key involved in a leaf script concatenated with the 32 byte hash of the leaf it is part of. -| <tt><signature></tt> +| <tt><64 or 65 byte signature></tt> | The 64 or 65 byte Schnorr signature for this pubkey and leaf combination. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. | | @@ -452,10 +441,10 @@ The currently defined per-input types are defined as follows: |- | Taproot Leaf Script | <tt>PSBT_IN_TAP_LEAF_SCRIPT = 0x15</tt> -| <tt><control block></tt> +| <tt><bytes control block></tt> | The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf. -| <tt><script> <8-bit uint></tt> -| The script for this leaf as would be provided in the witness stack followed by the single byte leaf version. Note that the leaves included in this field should be those that the signers of this input are expected to be able to sign for. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. +| <tt><bytes script> <8-bit uint leaf version></tt> +| The script for this leaf as would be provided in the witness stack followed by the single byte leaf version. Note that the leaves included in this field should be those that the signers of this input are expected to be able to sign for. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. | | | 0, 2 @@ -463,9 +452,9 @@ The currently defined per-input types are defined as follows: |- | Taproot Key BIP 32 Derivation Path | <tt>PSBT_IN_TAP_BIP32_DERIVATION = 0x16</tt> -| <tt><xonlypubkey></tt> -| A 32 byte X-only public key involved in this input. It may be the internal key, or a key present in a leaf script. -| <tt><hashes len> <leaf hash>* <4 byte fingerprint> <32-bit uint>*</tt> +| <tt><32 byte xonlypubkey></tt> +| A 32 byte X-only public key involved in this input. It may be the output key, the internal key, or a key present in a leaf script. +| <tt><compact size uint number of hashes> <32 byte leaf hash>* <4 byte fingerprint> <32-bit little endian uint path element>*</tt> | A compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, followed by the 4 byte 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. The leaf hashes are of the leaves which involve this public key. The internal key does not have leaf hashes, so can be indicated with a <tt>hashes len</tt> of 0. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. | | @@ -476,7 +465,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_TAP_INTERNAL_KEY = 0x17</tt> | None | No key data -| <tt><pubkey></tt> +| <tt><32 byte xonlypubkey></tt> | The X-only pubkey used as the internal key in this output. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. | | @@ -487,7 +476,7 @@ The currently defined per-input types are defined as follows: | <tt>PSBT_IN_TAP_MERKLE_ROOT = 0x18</tt> | None | No key data -| <tt><pubkey></tt> +| <tt><32-byte hash></tt> | The 32 byte Merkle root hash. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. | | @@ -496,9 +485,9 @@ The currently defined per-input types are defined as follows: |- | 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> +| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt> +| 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. +| <tt><bytes data></tt> | Any value data as defined by the proprietary type user. | | @@ -526,7 +515,7 @@ determine which outputs are change outputs and verify that the change is returni | <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt> | None | No key data -| <tt><redeemScript></tt> +| <tt><bytes redeemScript></tt> | The redeemScript for this output if it has one. | | @@ -537,7 +526,7 @@ determine which outputs are change outputs and verify that the change is returni | <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt> | None | No key data -| <tt><witnessScript></tt> +| <tt><bytes witnessScript></tt> | The witnessScript for this output if it has one. | | @@ -546,9 +535,9 @@ determine which outputs are change outputs and verify that the change is returni |- | BIP 32 Derivation Path | <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> -| <tt><public key></tt> +| <tt><bytes public key></tt> | The public key -| <tt><{32-bit uint> <32-bit uint>*</tt> +| <tt><4 byte fingerprint> <32-bit little endian uint path element>*</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. | | @@ -559,7 +548,7 @@ determine which outputs are change outputs and verify that the change is returni | <tt>PSBT_OUT_AMOUNT = 0x03</tt> | None | No key data -| <tt><64-bit int></tt> +| <tt><64-bit int amount></tt> | 64 bit signed little endian integer representing the output's amount in satoshis. | 2 | 0 @@ -570,7 +559,7 @@ determine which outputs are change outputs and verify that the change is returni | <tt>PSBT_OUT_SCRIPT = 0x04</tt> | None | No key data -| <tt><script></tt> +| <tt><bytes script></tt> | The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2. | 2 | 0 @@ -581,7 +570,7 @@ determine which outputs are change outputs and verify that the change is returni | <tt>PSBT_OUT_TAP_INTERNAL_KEY = 0x05</tt> | None | No key data -| <tt><pubkey></tt> +| <tt><32 byte xonlypubkey></tt> | The X-only pubkey used as the internal key in this output. | | @@ -592,29 +581,18 @@ determine which outputs are change outputs and verify that the change is returni | <tt>PSBT_OUT_TAP_TREE = 0x06</tt> | None | No key data -| <tt>{<8-bit uint depth> <8-bit uint leaf version> <scriptlen> <script>}*</tt> +| <tt>{<8-bit uint depth> <8-bit uint leaf version> <compact size uint scriptlen> <bytes script>}*</tt> | One or more tuples representing the depth, leaf version, and script for a leaf in the Taproot tree, allowing the entire tree to be reconstructed. The tuples must be in depth first search order so that the tree is correctly reconstructed. Each tuple is an 8-bit unsigned integer representing the depth in the Taproot tree for this script, an 8-bit unsigned integer representing the leaf version, the length of the script as a compact size unsigned integer, and the script itself. | | | 0, 2 | [[bip-0371.mediawiki|371]] |- -| Taproot Leaf Script -| <tt>PSBT_OUT_TAP_LEAF_SCRIPT = 0x06</tt> -| <tt><control block></tt> -| The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf. -| <tt><script></tt> -| The script for this leaf as would be provided in the witness stack. -| -| -| 0, 2 -| [[bip-0371.mediawiki|371]] -|- | Taproot Key BIP 32 Derivation Path | <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt> -| <tt><xonlypubkey></tt> -| A 32 byte X-only public key involved in this output. It may be the internal key, or a key present in a leaf script. -| <tt><hashes len> <leaf hash>* <4 byte fingerprint> <32-bit uint>*</tt> +| <tt><32 byte xonlypubkey></tt> +| A 32 byte X-only public key involved in this output. It may be the output key, the internal key, or a key present in a leaf script. +| <tt><compact size uint number of hashes> <32 byte leaf hash>* <4 byte fingerprint> <32-bit little endian uint path element>*</tt> | A compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, followed by the 4 byte 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. The leaf hashes are of the leaves which involve this public key. The internal key does not have leaf hashes, so can be indicated with a <tt>hashes len</tt> of 0. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. | | @@ -623,9 +601,9 @@ determine which outputs are change outputs and verify that the change is returni |- | 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> +| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt> +| 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. +| <tt><bytes data></tt> | Any value data as defined by the proprietary type user. | | @@ -698,7 +676,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 143 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. @@ -798,6 +776,8 @@ Or, for participants performing fA(psbt) and fB(psbt): Combine(fA(psbt), fB(psbt The Input Finalizer must only accept a PSBT. For each input, the Input Finalizer determines if the input has enough data to pass validation. If it does, it must construct the <tt>0x07</tt> Finalized scriptSig and <tt>0x08</tt> Finalized scriptWitness and place them into the input key-value map. +If scriptSig is empty for an input, <tt>0x07</tt> should remain unset rather than assigned an empty array. +Likewise, if no scriptWitness exists for an input, <tt>0x08</tt> should remain unset rather than assigned an empty array. All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction. ===Transaction Extractor=== @@ -839,6 +819,9 @@ If an updater is updating a PSBT and needs to add a field that is only available New fields should first be proposed on the bitcoin-dev mailing list. If a field requires significant 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. +Although some PSBT version 0 implementations encode types as uint8_t rather than compact size, +it is still safe to add >0xFD fields to PSBT 0, because these old parsers ignore +unknown fields, and <keytype> is prefixed by its length. ===Procedure For New Versions=== |