📅 Original date posted:2022-05-23
📝 Original message: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 discussion and also .. it's pretty interesting generally!):
https://gist.github.com/AdamISZ/ca974ed67889cedc738c4a1f65ff620b
(btw github gists have equation rendering now which is nice!)
Thanks,
waxwing/AdamISZ
Sent with ProtonMail secure email.
------- Original Message -------
On Monday, May 23rd, 2022 at 10:56, Jonas Nick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
> that case, a disruptive signer can permanently DoS-attack a session by simply
> copying the public key of some other signer. Therefore, the BIP is much more
> useful if it can deal with identical public keys.
>
> The MuSig2 BIP draft requires some added complexity to handle identical public
> keys (because of the MuSig2* optimization). But this solution naturally allows
> identifying and removing disruptive signers, which ultimately reduces the
> complexity for MuSig2 users.
>
> [0] https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki#public-key-aggregation
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev