[musig2] two phase key aggregation #97
Closed
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
Since we do the negation check when we create them
so that before finalizing into an "AggKey" you can apply ordinary b32 type tweaks. After finalization you apply only "XOnly" taproot style tweaks.
nickfarrow
reviewed
Jun 15, 2022
| /// This is how you embed a taproot commitment into a key. | ||
| /// The resulting key is equal to the existing key plus `tweak * G`. The tweak mutates the | ||
| /// public key while still allowing the original set of signers to sign under the new key. | ||
| /// This function is appropriate for doing [BIP32] tweaks before calling `into_bip340_key`. |
There was a problem hiding this comment.
Thinking maybe move these two lines on top of the ones above? Just to be sure people see it and don't use the wrong tweak
nickfarrow
reviewed
Jun 15, 2022
| /// The `XOnly` aggregated key for the keylist. | ||
| pub fn agg_public_key(&self) -> XOnly { | ||
| self.agg_key.to_xonly() | ||
| impl AggKey { |
There was a problem hiding this comment.
Could rename AggKey to MuSigKey like we are planning with FrostKey which I quite like. But maybe this makes Bip340MuSigKey too long
With frost we will also have a Bip340FrostKey / Bip340AggKey
There was a problem hiding this comment.
Yeah let's apply the same thing to FROST and see what naming we like best. I think what you've suggested is right.
nickfarrow
reviewed
Jun 15, 2022
| /// Tweak the aggregate MuSig public key with a scalar so that the resulting key is equal to the | ||
| /// existing key plus `tweak * G`. The tweak mutates the public key while still allowing | ||
| /// the original set of signers to sign under the new key. | ||
| /// Add a scalar `tweak` to aggregate MuSig public key. |
There was a problem hiding this comment.
Both tweaks functions take scalar tweaks as inputs so perhaps this isn't the best description. But I also do not like ordinary tweaks..
|
superseded by #37 |
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.
Users must transition from a
AggKeyinto anBip340AggKeybefore starting a signing session. This is the idea:AggKeyyou can only apply ordinary tweaks (i.e. bip32)Bip340Aggkeyyou can only apply "xonly" tweaks. (i.e. taproot)The code and spec makes way more sense to me now. We are down to a single
needs_negationboolean we keep around. We can't implement all the spec tests for this since one test requires a ordinary tweak after a "xonly" tweak. I think I'll suggest removing that from the spec.