Since #1622, it makes more sense to define input_hash inline, vs having its own section.
Also remove the wording about txid and vout, since this is already defined in the specification.
input_hash
wording
#1629
Since https://github.com/bitcoin/bips/pull/1622, it makes more sense
to define input_hash inline, vs having its own section.
296@@ -303,7 +297,7 @@ After the inputs have been selected, the sender can create one or more outputs f
297 * 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>
298 * 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
299 ** If ''a = 0'', fail
300-* Generate the ''input_hash'' with the smallest outpoint lexicographically and ''A = a·G'', using the method described above
301+* 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''
A = a·G
becomes just A
with this change, aligning it with the change https://github.com/bitcoin/bips/pull/1622/files#diff-f675d83bad4bfe13848faf132a4130f2d6801d36c12308854dbf6adcddac8398R102 IIUC?
Edit: never mind, misread the diff.