utils/MuSig2Sign: validate signer inputs and accept raw keys#1110
utils/MuSig2Sign: validate signer inputs and accept raw keys#1110starius wants to merge 2 commits intolightninglabs:masterfrom
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the MuSig2 signing utility to improve robustness and developer experience. By enforcing stricter input validation and simplifying the key handling interface, it ensures safer and more flexible interactions with the MuSig2 signing flow, while also addressing compatibility requirements for different protocol versions. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the MuSig2Sign utility to accept raw private keys, implements x-only public key support for MuSig2 v0.4, fixes a typo, and adds unit tests. Feedback identifies a critical logic error where private keys must be negated for x-only public keys with odd Y coordinates in v0.4. Additionally, the reviewer suggested failing fast by moving input validation to the start of the function and improving test coverage by verifying signatures against aggregate public keys.
| if version == input.MuSig2Version040 { | ||
| pubKey := pubKeys[i].SerializeCompressed() | ||
| xOnlyPubKey, err := schnorr.ParsePubKey(pubKey[1:]) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("error parsing x-only "+ | ||
| "pubkey: %v", err) | ||
| } | ||
|
|
||
| pubKeys[i] = xOnlyPubKey | ||
| } |
There was a problem hiding this comment.
When using MuSig2 v0.4 with x-only public keys, if the original public key has an odd Y coordinate, the corresponding private key must be negated to match the x-only public key (which is assumed to have an even Y coordinate). Failing to do so will result in an invalid signature because the signer will be using a private key that does not correspond to the public key used in the MuSig2 aggregation. You should check the parity of the public key and negate the private key if necessary.
There was a problem hiding this comment.
I don't think we need to add an extra private-key negation in our wrapper for review item 1.
For MuSig2Version040, our helper calls input.MuSig2CreateContext, which passes the private key into the v0.4 implementation.
Inside that implementation, musig2v040.NewContext already normalizes the local signer public key to x-only by calling schnorr.ParsePubKey(schnorr.SerializePubKey(signingKey.PubKey())).
Then, during signing, musig2v040.Sign checks whether the original local public key has odd Y, sets paritySignKey.Negate() when needed, and multiplies the private scalar by that parity factor before producing the partial signature.
So the odd-Y to x-only adjustment is already handled by lnd/input for the v0.4 path. Adding another manual negation in our helper would duplicate that logic and risks over-correcting the signer key.
I added a test case to make sure that odd Y keys work.
| privKeys := make([]*btcec.PrivateKey, len(keys)) | ||
| pubKeys := make([]*btcec.PublicKey, len(keys)) |
There was a problem hiding this comment.
It is more efficient to validate the input length before performing any cryptographic operations or memory allocations. Moving the check for at least two signing keys to the beginning of the function will allow it to fail fast.
if len(keys) < 2 {
return nil, fmt.Errorf("need at least two signing keys")
}
privKeys := make([]*btcec.PrivateKey, len(keys))
pubKeys := make([]*btcec.PublicKey, len(keys))There was a problem hiding this comment.
I put the check after the translation to reduce the diff size. In the real use case the check never fires, so this has no performance impact.
utils/musig_test.go
Outdated
| sig, err := MuSig2Sign( | ||
| version, rawKeys(1, 2), &input.MuSig2Tweaks{}, | ||
| [32]byte{}, | ||
| ) | ||
| require.NoError(t, err) | ||
| require.Len(t, sig, 64) |
There was a problem hiding this comment.
The test currently only checks that a 64-byte signature is returned without error. It should also verify that the generated signature is valid against the aggregate public key to ensure the MuSig2 flow is correctly implemented, especially for different versions and key parities.
There was a problem hiding this comment.
Added signature verification to the test.
starius
force-pushed
the
musig2sign-refactor
branch
from
de6e154 to
d0b88fd
Compare
|
@gemini-code-assist review |
There was a problem hiding this comment.
Code Review
This pull request refactors the MuSig2Sign utility to accept raw private keys, centralizing public key derivation and x-only conversion logic for MuSig2 v0.4. It also fixes a typo in an error message and adds a new test suite for version compatibility. A review comment suggests moving the input validation for the number of keys to the beginning of the function to avoid unnecessary allocations.
| privKeys := make([]*btcec.PrivateKey, len(keys)) | ||
| pubKeys := make([]*btcec.PublicKey, len(keys)) | ||
|
|
||
| // First parse the raw private keys and also create the corresponding | ||
| // public keys. | ||
| for i, key := range keys { | ||
| privKeys[i], pubKeys[i] = btcec.PrivKeyFromBytes(key[:]) | ||
|
|
||
| // MuSig2 v0.4 expects x-only public keys. | ||
| if version == input.MuSig2Version040 { | ||
| pubKey := pubKeys[i].SerializeCompressed() | ||
| xOnlyPubKey, err := schnorr.ParsePubKey(pubKey[1:]) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("error parsing x-only "+ | ||
| "pubkey: %v", err) | ||
| } | ||
|
|
||
| pubKeys[i] = xOnlyPubKey | ||
| } | ||
| } | ||
|
|
||
| if len(privKeys) < 2 { | ||
| return nil, fmt.Errorf("need at least two signing keys") | ||
| } |
There was a problem hiding this comment.
The check for the minimum number of signing keys should be performed at the beginning of the function. This avoids unnecessary allocations and processing (such as parsing keys and performing x-only conversions) when the input is invalid.
if len(keys) < 2 {
return nil, fmt.Errorf("need at least two signing keys")
}
privKeys := make([]*btcec.PrivateKey, len(keys))
pubKeys := make([]*btcec.PublicKey, len(keys))
// First parse the raw private keys and also create the corresponding
// public keys.
for i, key := range keys {
privKeys[i], pubKeys[i] = btcec.PrivKeyFromBytes(key[:])
// MuSig2 v0.4 expects x-only public keys.
if version == input.MuSig2Version040 {
pubKey := pubKeys[i].SerializeCompressed()
xOnlyPubKey, err := schnorr.ParsePubKey(pubKey[1:])
if err != nil {
return nil, fmt.Errorf("error parsing x-only "+
"pubkey: %v", err)
}
pubKeys[i] = xOnlyPubKey
}
}1 participant
This fixes some issues discovered in #1109 and before that by Gemini AI in #1108
Pull Request Checklist
release_notes.mdif your PR contains major features, breaking changes or bugfixes