From: AdamISZ <AdamISZ@protonmail•com>
To: Jonas Nick <jonasdnick@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] MuSig2 BIP
Date: Thu, 26 May 2022 17:34:47 +0000 [thread overview]
Message-ID: <VUoLgGbJszQbch6ZCnjWri-lV9sJ6PhsS8vUu9vVeaQ8XddMxp3b6HUP5hGDu8FfAAgsAb4xPXIoX4mZ-8pPuhXssrD2ysKtENbQ2fcIdMo=@protonmail.com> (raw)
In-Reply-To: <7c4395b0-9bc9-78e6-5a46-dc3eddb8e97f@gmail.com>
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 <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
Oh but that wasn't the claim - that it's useless. I'd characterize it more like: the benefit of identifying one disruptor index is less than claimed (but PR now to fix that), and in certain (see 'spontaneous' case) does not allow a guarantee of progress (but see below .. you have convinced me that this is kind of a false conclusion to draw). That combined with the risk potential from implementation errors weighted my opinion in favour of the abort early option.
> It seems very unlikely that they're
> nice enough to truthfully indicate their brokenness by copying someone elses
> public key.
I don't really buy that. My thinking was, there are of course an infinite number of ways an implementation can be broken, but this is not a vanishingly unlikely case, especially when you consider how often there might be ex-protocol cooperative interactions between signers. The obvious case that crops up is when one agent actually stands behind multiple different signing keys; in that scenario it's not that unlikely, and if that agent is co-signing with *other* agents something very bad might happen.
>
> 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.
That's a very fair point, and good to mention. The BIP strongly justifies no abort early, though.
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".
Yeah, this is the 'we can identify the disruptor' point which has been discussed in the previous mail and below, re: spontaneous. It's true except when it, partially, isn't :)
>
> 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.
Well but I didn't miss that point, I addressed it in the section "Why does the DOS vector remain?".
I see that where we've diverged here is only that you consider the case 'the same adversary keeps joining the group' to be out of scope as something that higher level protocols would have to address.
On reflection I guess I agree: such a protocol needs to address this point, regardless of the quirk of repeated keys, and regardless of forged partial sigs; if participant 5 is a disruptor and you replace him with another, you have to have a mechanism to handle that it might be the same guy, and it's outside the scope of this doc. The fact that the disruptor may still stay at another index modulates that argument a little bit, but doesn't invalidate it, I believe.
So from that perspective, my point here was more a 'quibble' than an actual critique: because the document kind of implies that you can do a bit more than you can, and didn't let the reader know that such an attacker, in this specific case, might 'still be around' in some sense, as you agree below:
>
> 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
Right, thanks, will follow up.
Honestly, as an implementor, I would still abort early *in most usage scenarios* ... So many more coins were lost to screw ups in implementations than super genius attackers.
Cheers,
waxwing/AdamISZ
next prev parent reply other threads:[~2022-05-26 17:34 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
2022-05-26 17:34 ` AdamISZ [this message]
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='VUoLgGbJszQbch6ZCnjWri-lV9sJ6PhsS8vUu9vVeaQ8XddMxp3b6HUP5hGDu8FfAAgsAb4xPXIoX4mZ-8pPuhXssrD2ysKtENbQ2fcIdMo=@protonmail.com' \
--to=adamisz@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jonasdnick@gmail$(echo .)com \
/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