From: Jonas Nick <jonasdnick@gmail•com>
To: AdamISZ <AdamISZ@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] MuSig2 BIP
Date: Thu, 26 May 2022 15:32:33 +0000 [thread overview]
Message-ID: <7c4395b0-9bc9-78e6-5a46-dc3eddb8e97f@gmail.com> (raw)
In-Reply-To: <XRFIZf_z1dKNoKvgFJmrgThHcIE_B0JW9mmJL7mE2B2afcgwZn7NuJaK_vXUAvVwWSZ2Nijwz9yhiwYpty6iI3mrJyivdLxL_CtWlEaAhMY=@protonmail.com>
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
next prev parent reply other threads:[~2022-05-26 15:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 22:57 Jonas Nick
2022-04-28 1:47 ` Olaoluwa Osuntokun
2022-04-28 3:53 ` Olaoluwa Osuntokun
2022-04-28 19:18 ` Jonas Nick
2022-05-22 22:26 ` AdamISZ
2022-05-23 15:56 ` Jonas Nick
2022-05-23 22:09 ` AdamISZ
2022-05-24 19:06 ` AdamISZ
2022-05-26 15:32 ` Jonas Nick [this message]
2022-05-26 17:34 ` AdamISZ
2022-06-12 23:07 ` AdamISZ
2022-10-03 20:41 ` Jonas Nick
2022-10-11 15:34 ` Jonas Nick
2022-11-03 14:43 ` Jonas Nick
2022-04-28 15:33 Brandon Black
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c4395b0-9bc9-78e6-5a46-dc3eddb8e97f@gmail.com \
--to=jonasdnick@gmail$(echo .)com \
--cc=AdamISZ@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox