diff options
Diffstat (limited to 'bip-0174.mediawiki')
| -rw-r--r-- | bip-0174.mediawiki | 34 |
1 files changed, 27 insertions, 7 deletions
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 65fa9a9..c424c5d 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -200,25 +200,25 @@ The currently defined per-input types are defined as follows: ** 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> +* Type: RIPEMD160 preimage <tt>PSBT_IN_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> +* Type: SHA256 preimage <tt>PSBT_IN_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> +* Type: HASH160 preimage <tt>PSBT_IN_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> +* Type: HASH256 preimage <tt>PSBT_IN_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 @@ -350,9 +350,9 @@ 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== +==Roles== -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. +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 +373,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. @@ -839,6 +839,26 @@ Any data types, their associated scope and BIP number must be defined here | [[bip-0127.mediawiki|BIP 127]] |- | Input +| 10 +| PSBT_IN_RIPEMD160 +| BIP 174 +|- +| Input +| 11 +| PSBT_IN_SHA256 +| BIP 174 +|- +| Input +| 12 +| PSBT_IN_HASH160 +| BIP 174 +|- +| Input +| 13 +| PSBT_IN_HASH256 +| BIP 174 +|- +| Input | 252 | PSBT_IN_PROPRIETARY | BIP 174 |