-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement MuSig2 multisignature scheme #80
Conversation
We do this so we naturally get an implementation for lists of things that do HashInto. It's hard to arrange otherwise.
To allow for using faster multi-exp algorithms now used in backend.
Nobody actually needs this!
@@ -28,8 +28,8 @@ impl KeyPair { | |||
} | |||
|
|||
/// Returns a reference to the public key. | |||
pub fn public_key(&self) -> &XOnly { | |||
&self.pk | |||
pub fn public_key(&self) -> XOnly { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any rationale on why you go this way (by value instead ref?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
XOnly
is Copy so I think it's conventional to not return references to Copy
things. On top of that There's no reason to leak the implementation that keyPair
stores an XOnly
(it could store a Point<EvenY>
instead).
(that comment needs to change though).
And add a way to clear them manually to try and discourage serializing nonces.
Sort of compatible with: BlockstreamResearch/secp256k1-zkp#131
relevant new code is in
musig.rs
the rest is just yak shaving.