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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
