1
0
mirror of https://github.com/bitcoin/bips.git synced 2024-11-19 01:40:05 +01:00

BIP352: improve input_hash wording

Since https://github.com/bitcoin/bips/pull/1622, it makes more sense
to define input_hash inline, vs having its own section.
This commit is contained in:
josibake 2024-06-29 14:28:37 +02:00
parent 3b99594660
commit 8ac84bd344
No known key found for this signature in database
GPG Key ID: 8ADCB558C4F33D65

View File

@ -279,12 +279,6 @@ The sender performs the tweak using the private key for the nested ''P2WPKH'' ou
The receiver obtains the public key from the ''scriptSig''. The receiver MUST parse the ''scriptSig'' for the public key, even if the ''scriptSig'' does not match the template specified (e.g. <code><dummy> OP_DROP <Signature> <Public Key></code>). This is to address the [https://en.bitcoin.it/wiki/Transaction_malleability third-party malleability of ''P2PKH'' ''scriptSigs''].
=== Input hash ===
The sender and receiver MUST calculate an input hash for the transaction in the following manner:
* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically by txid and vout used in the transaction<ref name="why_smallest_outpoint"></ref>
=== Sender ===
==== Selecting inputs ====
@ -303,7 +297,7 @@ After the inputs have been selected, the sender can create one or more outputs f
* For each private key ''a<sub>i</sub>'' corresponding to a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output, check that the private key produces a point with an even Y coordinate and negate the private key if not<ref name="why_negate_taproot_private_keys">'''Why do taproot private keys need to be checked?''' Recall from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] that each X-only public key has two corresponding private keys, ''d'' and ''n - d''. To maintain parity between sender and receiver, it is necessary to use the private key corresponding to the even Y coordinate when performing the ECDH step since the receiver will assume the even Y coordinate when summing the taproot X-only public keys.</ref>
* Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>'', where each ''a<sub>i</sub>'' has been negated if necessary
** If ''a = 0'', fail
* Generate the ''input_hash'' with the smallest outpoint lexicographically and ''A = a·G'', using the method described above
* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest ''outpoint'' lexicographically used in the transaction<ref name="why_smallest_outpoint"></ref> and ''A = a·G''
* Group receiver silent payment addresses by ''B<sub>scan</sub>'' (e.g. each group consists of one ''B<sub>scan</sub>'' and one or more ''B<sub>m</sub>'')
* For each group:
** Let ''ecdh_shared_secret = input_hash·a·B<sub>scan</sub>''
@ -336,7 +330,7 @@ If each of the checks in ''[[#scanning-silent-payment-eligible-transactions|Scan
* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
** If ''A'' is the point at infinity, skip the transaction
* Generate the ''input_hash'' with the smallest outpoint lexicographically and ''A'', using the method described above
* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest ''outpoint'' lexicographically used in the transaction<ref name="why_smallest_outpoint"></ref>
* Let ''ecdh_shared_secret = input_hash·b<sub>scan</sub>·A''
* Check for outputs:
** Let ''outputs_to_check'' be the taproot output keys from all taproot outputs in the transaction (spent and unspent).