BIP-352: generate input_hash after summing up keys (simplification)
#1622
+7
−9
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For both sender and receiver, generating the input hash is currently listed as the first step. This 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. 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.
theStack
force-pushed
the
bip352-simplify_input-hash_flow
branch
from
3623b60
to
fe0f835
Compare
theStack
changed the title
input_hash after summing up keys (simplifcation)input_hash after summing up keys (simplification)
jonatack
added
Proposed BIP modification
Pending acceptance
|
Pinging BIP authors @josibake @RubenSomsen for review/sign-off. |
jonatack
reviewed
Jun 21, 2024
andrewtoth
reviewed
Jun 28, 2024
josibake
added a commit
to josibake/bips
that referenced
this pull request
Jun 29, 2024
Since bitcoin#1622, it makes more sense to define input_hash inline, vs having its own section.
jonatack
removed
the
Pending acceptance
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.