Thanks for the detailed feedback. Let me try to summarize your argument: Key aggregation should fail if there are duplicate keys because this is likely a bug and continuing might be dangerous. If it is not a bug but a dishonest signer trying to disrupt, then resuming the protocol and trying to identify the dishonest signer does not work because partial signatures are not real signatures.
I disagree that identifying dishonest signers is useless. But if I try hard, I can see your point that honest signers should not continue in order to protect terribly broken implementations. Broken could mean that signers reuse nonces, output their secret key instead of a partial signature, etc. However, terribly broken implementations are terribly broken. It seems very unlikely that they're nice enough to truthfully indicate their brokenness by copying someone elses public key. Perhaps they use the sum of every other key, actually create a proper public key, or do something entirely different. So I think in practice, it is implausible to find a single instance of an implementation that doesn't survive partial signature creation by looking at duplicate public keys. However, your suggestion to abort in KeyAgg when encountering duplicate public keys is compatible with the MuSig2 BIP draft. No one can force a signer to accept an arbitrary set of public keys for the multi-signature, so signers are always fine to abort at the key aggregation stage to try to protect terribly broken co-signers. In that sense, the BIP draft takes a more general and flexible approach. I doubt that identifying duplicate public keys is less complex. The only consequence of allowing duplicate public keys is that the `GetSecondKey` is required to loop over the public keys. Aborting when encountering duplicate public keys also has the added complexity of giving users the unspecific instruction to "debug signers X and Y" versus "there's something definitely wrong with signer Z". As mentioned above, I don't follow your argument that identifying signers claiming the public key of other signers is useless. I do think the "persistent" case is interesting. It's easy to imagine persistent identities not tied to secp256k1 curve points. Only for creating BIP-340 multi-signatures do they use secp256k1 public keys. These keys can be fresh, or if they are persistent, the participants may want to rotate them from time to time. So there are plenty of opportunities for an attacker to overtake a participant and try to disrupt the protocol. You mention that duplicating keys would require "a Sybil at two indices", but actually a single malicious signer that copies some public key is sufficient. Your analysis of the "spontaneous" case misses that partial signature verification identifies at least one of the dishonest signers and therefore allows to make progress. This closes the DoS vector as far as the MuSig protocol is concerned. If there are multiple disruptive signers, they may not all be identified in a single round but require multiple signing attempts. Of course, applications that use MuSig and replace disruptive signers with just some other arbitrary nym may be so unlucky that it always has disruptive signers. But that's a problem of the application layer, and it's easy to conceive smarter peer selection. I agree that the claim "any signer who prevents a signing session from completing successfully by sending incorrect contributions in the session can be identified" is incorrect. We can identify at least one, and that means applications can make progress. I opened a PR to fix the wording [0]. [0] https://github.com/jonasnick/bips/pull/25 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
