We updated the MuSig2 BIP draft to fix the vulnerability published in an earlier
post [0].
We also wrote an article [1] that contains a description of
1. the vulnerable scheme (remember that the original MuSig2 scheme is not
vulnerable because it doesn't allow tweaking)
2. an attack against
It is still true that cryptography is hard, unfortunately. Yannick Seurin, Tim
Ruffing, Elliott Jin, and I discovered an attack against the latest version of
BIP MuSig2 in the case that a signer's individual key A = a*G is tweaked before
giving it as input to key aggregation.
In more detail, a
Since the initial publication of the BIP draft, we incorporated feedback from
this mailing list and the development git repository and made significant
improvements compared to the initial version. There are multiple implementations
today, and there have been no requests for major changes or
Sent with Proton Mail secure email.
--- Original Message ---
On Thursday, May 26th, 2022 at 12:34, AdamISZ via bitcoin-dev
wrote:
> Hi Jonas, list,
> responses inline
>
> >
> > [0] https://github.com/jonasnick/bips/pull/25
>
>
> Right, thanks, will follow up.
>
Just to drop a note to
Hi Jonas, list,
responses inline
Sent with Proton Mail secure email.
--- Original Message ---
On Thursday, May 26th, 2022 at 10:32, Jonas Nick via bitcoin-dev
wrote:
> Thanks for the detailed feedback. Let me try to summarize your argument: Key
> aggregation should fail if there
--- Original Message ---
On Monday, May 23rd, 2022 at 17:09, AdamISZ via bitcoin-dev
wrote:
> Jonas, all,:
>
> So I do want to ask a couple further clarifying questions on this point, but
> I got rather majorly sidetracked :)
> I wonder can you (and other list readers!) take a look at
Jonas, all,:
So I do want to ask a couple further clarifying questions on this point, but I
got rather majorly sidetracked :)
I wonder can you (and other list readers!) take a look at my attempt here to
summarize what is described in Footnote 2 of the draft BIP (as it's related to
this
Thank you for taking the time to look at the BIP and reference code, waxwing. I
don't know if you're overlooking anything, so let me try to restate the
paragraph in the BIP draft that attempts to cover this topic [0].
Suppose signers would just abort in the presence of identical public keys. In
Jonas,
Many thanks for getting the BIP draft out. Particularly appreciate the
reference code!
I have a question about identical pubkeys (including how it relates to MuSig2*
optimization):
What is the purpose of allowing this? Isn't it always the case that N equal
keys combined with M
Happy to hear that the BIP draft is already useful and thank you, Laolu, for
extracting the test vectors.
> an implementation must make the _pre tweaked_ combined key available to the
caller
To apply the Taproot tweak with the key aggregation algorithm as specified you
would have to do the
Hi Laolu,
> Finally, can you elaborate a bit on this fragment of the BIP that
describes
> a "short cut" when a specific signers is meant to send their nonces last:
>
> > Second, if there is a unique signer who is supposed to send the pubnonce
> > last, it is possible to modify nonce generation
Stating the taproot interaction more plainly: the taproot tweak is defined
as a function of the internal key itself h_tapTeak(internalKey || rootHash),
which means that the full tweak can't be known ahead of time. Instead, one
must aggregate the keys to obtain the internal key _then_ apply the
Hi Jonas,
Great work on this BIP! Props to you and the other co-authors for putting
together such an excellent technical specification. I'm sure I'm not the
only developer stoked to see the much anticipated musig2 BIP published!
I made a PR earlier today to add some JSON test vectors [1],
Tim Ruffing, Elliott Jin, and I are working on a MuSig2 BIP that we would like
to propose to the community for discussion. The BIP is compatible with BIP340
public keys and signatures. It supports tweaking, which allows deriving BIP32
child keys from aggregate keys and creating BIP341 Taproot
14 matches
Mail list logo
