Date: Thu, 26 May 2022 17:34:47 +0000
To: Jonas Nick <jonasdnick@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <VUoLgGbJszQbch6ZCnjWri-lV9sJ6PhsS8vUu9vVeaQ8XddMxp3b6HUP5hGDu8FfAAgsAb4xPXIoX4mZ-8pPuhXssrD2ysKtENbQ2fcIdMo=@protonmail.com>
In-Reply-To: <7c4395b0-9bc9-78e6-5a46-dc3eddb8e97f@gmail.com>
References: <46175970-d2ab-a58e-7010-f29820849604@gmail.com>
 <yitwgERAsaofLM5dheUZUYyFp0ncU8xyN98xTym3MkCxTch83DkweZN5JYyovVcfxA2Mo7DjTbv1Iku3wBApYiPG_cMwznTytKFpcjYa1O0=@protonmail.com>
 <c2a9b488-8d29-d1c6-b2c3-bc17d12b7d65@gmail.com>
 <HPRdBVSvEmkPyHkS-175ZYEYyL-ULZAgmhSPh3uwVtfryFOKZUFKUM5QXnSXjwZy3b10sV55f9lhOkZ-ILShaWSWJ7GMN0JmKNweKY6kfLg=@protonmail.com>
 <XRFIZf_z1dKNoKvgFJmrgThHcIE_B0JW9mmJL7mE2B2afcgwZn7NuJaK_vXUAvVwWSZ2Nijwz9yhiwYpty6iI3mrJyivdLxL_CtWlEaAhMY=@protonmail.com>
 <7c4395b0-9bc9-78e6-5a46-dc3eddb8e97f@gmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] MuSig2 BIP
Precedence: list

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-d=
ev@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 likel=
y a bug
> and continuing might be dangerous. If it is not a bug but a dishonest sig=
ner
> 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 a=
llow a guarantee of progress (but see below .. you have convinced me that t=
his is kind of a false conclusion to draw). That combined with the risk pot=
ential from implementation errors weighted my opinion in favour of the abor=
t early option.


> It seems very unlikely that they're
> nice enough to truthfully indicate their brokenness by copying someone el=
ses
> public key.

I don't really buy that. My thinking was, there are of course an infinite n=
umber of ways an implementation can be broken, but this is not a vanishingl=
y unlikely case, especially when you consider how often there might be ex-p=
rotocol cooperative interactions between signers. The obvious case that cro=
ps up is when one agent actually stands behind multiple different signing k=
eys; in that scenario it's not that unlikely, and if that agent is co-signi=
ng with *other* agents something very bad might happen.


>
> However, your suggestion to abort in KeyAgg when encountering duplicate p=
ublic
> keys is compatible with the MuSig2 BIP draft. No one can force a signer t=
o
> accept an arbitrary set of public keys for the multi-signature, so signer=
s are
> always fine to abort at the key aggregation stage to try to protect terri=
bly
> 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 n=
o abort early, though.

 I doubt that identifying duplicate public keys is less
> complex. The only consequence of allowing duplicate public keys is that t=
he
> `GetSecondKey` is required to loop over the public keys. Aborting when
> encountering duplicate public keys also has the added complexity of givin=
g users
> the unspecific instruction to "debug signers X and Y" versus "there's som=
ething
> definitely wrong with signer Z".

Yeah, this is the 'we can identify the disruptor' point which has been disc=
ussed in the previous mail and below, re: spontaneous. It's true except whe=
n 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 "pers=
istent"
> case is interesting. It's easy to imagine persistent identities not tied =
to
> secp256k1 curve points. Only for creating BIP-340 multi-signatures do the=
y 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 plen=
ty of
> opportunities for an attacker to overtake a participant and try to disrup=
t 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 therefo=
re
> allows to make progress. This closes the DoS vector as far as the MuSig p=
rotocol
> 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 'th=
e same adversary keeps joining the group' to be out of scope as something t=
hat 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, yo=
u 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 invalid=
ate 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 scena=
rios* ... So many more coins were lost to screw ups in implementations than=
 super genius attackers.

Cheers,
waxwing/AdamISZ