fix(frost-secp256k1-tr): empty merkle root tweak should still hash the x-only pk #815
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
conradoplg
requested changes
Dec 27, 2024
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #815 +/- ##
==========================================
+ Coverage 82.18% 82.54% +0.36%
==========================================
Files 31 41 +10
Lines 3188 4338 +1150
==========================================
+ Hits 2620 3581 +961
- Misses 568 757 +189 ☔ View full report in Codecov by Sentry. |
…e x-only pk Per BIP-341 if there is no script paths the internal key should still be tapTweak'd by tG where t = TaggedHash(P_x). Before this commit the internal key and the taproot output key are the same if no script paths are used. This is because the tweak is the 0 scalar value so Q = P + tG = P. It is worth noting that Bitcoin's consensus would still accept a non-taptweak'd internal key as it verifies a signature against whatever pk is used in the witness program. So the outputs are still spendable, however it deviates from the spec.
0xBEEFCAF3
force-pushed
the
fix/taptweak
branch
from
4a7e3ef to
4f57f63
Compare
Done! |
conradoplg
approved these changes
Dec 30, 2024
10 tasks
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.
I noticed that the addresses I was deriving with rust-bitcoin and the ones I created with the taptweak'd key using this library were not the same. The problem is in how the tweak is calculated in the absence of script paths.
Per BIP-341, if there are no script paths, the internal key should still be tapTweak'd by tG, where t = TaggedHash(P_x). Before this commit, the internal key and the Taproot output key were the same if no script paths were used. This is because the tweak was the 0 scalar value, so Q = P + tG = P.
It is worth noting that Bitcoin's consensus rules will accept a non-taptweak'd internal key as it verifies a signature against whatever public key is used in the witness program. So the outputs are still spendable; however, they deviate from the BIP-341 spec.
I also noticed that in
post_dkg, we are tweaking by[0u8; 0]. However, the comment above it correctly states the tweak should beint(hashTapTweak(bytes(P)))G. I can change this code slightly to be:This should just tweak with the hash of the x-only pk. Just lmk, happy to make this change as well.