BIP-352: generate input_hash
after summing up keys (simplification)
#1622
+7
−9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While working on the sender side equivalent of #1620 I noticed that the current flow of input hash generation and key summing is a bit redundant and potentially confusing.
For both sender and receiver, generating the input hash is currently listed as the first step:
bips/bip-0352.mediawiki
Lines 302 to 304 in 85cda4e
bips/bip-0352.mediawiki
Lines 336 to 338 in 85cda4e
This step already involves summing up the public keys, even though summing up key material (private keys for sender, public keys of inputs for receiver) is then again listed explicitly in later steps. Especially for the sender side, this means that the summing up happens twice -- once for the pubkeys to generate the input hash, then again for the private keys to create the shared secret.
It seems to be more obvious and less redundant (and also hopefully less confusing for readers) to reorder the instructions to calculate the input_hash after the key aggregation is done to reuse the result. In case of the sender, the private key sum has to be multiplicated with G in order to the get to the corresponding input pubkey sum.
This also corresponds to the current BIP352 implementation in the secp256k1 library (bitcoin-core/secp256k1#1519). The reference implementation in Python here is adapted for the sender side, the receiver side has already generated the input_hash after summing up the pubkeys.