taproot signatures should be serialized as 64 bytes#5
Merged
zebra-lucky merged 2 commits intoApr 26, 2024
Merged
Conversation
conduition
commented
Apr 24, 2024
| // | ||
| // where h is the cofactor | ||
| let R = C::effective_nonce_element(signature.R); | ||
| let R = signature.R; |
Author
There was a problem hiding this comment.
Before this PR, a Signature's R point could be either even or odd parity. When verifying, we were coercing R to be even, so that BIP340 verification logic would work.
After this PR, the Signature's R point is always even parity (unless someone manually constructs one with an odd-parity outside the scope of this library). We no longer need to do this coercion during verification.
BIP340 signatures are usually represented with x-only (even parity) nonce points. As a step towards normalizing this for the frost-secp256k1-tr crate, we should ensure all Signature struct instances always use the effective nonce point, including the DKG proof-of-knowledge.
BIP340 signatures are supposed to be serialized as a 64-byte array: 32 bytes for the x-only nonce point 'R', and 32 bytes for the signature component 's'. This commit customizes the frost-secp256k1-tr crate so that signatures are serialized with x-only nonces, omitting the leading parity byte.
conduition
force-pushed
the
add-secp256k1-tr
branch
from
33bb2cf to
5dc7dd8
Compare
Owner
|
Haha!)
|
Owner
|
Owner
|
Owner
|
Tests seems to be passed. I'm tankful for @conduition. |
Author
|
My pleasure :D |
Owner
|
I'm sorry for my slow reaction. |
Owner
|
I'm lost control by the last time... |
Owner
wrong worlds -- I'm sorry... Your coding practices is impressive... i'm periodical off.. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
updates ZcashFoundation#584 to serialize taproot signatures as 64 bytes, in compliance with BIP340.
BIP340 signatures are supposed to be serialized as a 64-byte array: 32 bytes for the x-only nonce point$R$ , and 32 bytes for the signature component $s$ . This PR customizes the
frost-secp256k1-trcrate so that signatures are serialized with x-only nonces, omitting the leading parity byte. Instead of embedding global serialization logic in the methods ofSignature, we now endowCiphersuitewith two optional methods to serialize and deserialize aSignature, and then replace those methods in thefrost-secp256k1-trcrate.To maintain reusability of the
Signaturetype, i had to modify the DKG proof-of-knowledge so that we always hash the participant's effective verifying key, which in taproot is always the even-parity point. This allows the PoK to also be serialized as a 64-byte BIP340 signature. For all other ciphersuites, this change has no effect.