path: root/a6/1b6260f3f75b276e5f76e1eb5cb699f46a03ce

Return-Path: <AdamISZ@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 797CBC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 May 2022 17:34:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 692BB84702
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 May 2022 17:34:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wEw_FMnUrbAQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 May 2022 17:34:53 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 6613784701
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 May 2022 17:34:53 +0000 (UTC)
Date: Thu, 26 May 2022 17:34:47 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1653586490; x=1653845690;
 bh=D53FHbk513UtAD/dHqXmewQfd1QniF1wmOR9sP1F/qc=;
 h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=CZalzZx3dIYwrOmVzd9K9Zhf2jBp8ISeeNPteD6iELTqiQXjwK2enMdlpy4c9qRCO
 V6ivvxtZbV5NzO/9ln0IcwjiUnXdjAexa5yDdrzAsajAhFmLD9a1WbaddMyzkyXuOI
 zmhLkEwg6CyzGvsieUAfbG1NKJIXVGDyernHcZHjYxFJvK0rjrO5YfBgv2M/zYkbxO
 x+AWQZQibNnUDoo0CtsNwy3TlvkDMZYrc7Q27sIO22HIL3nGVAeV53W+P3T4UEVTzQ
 vM4ozKpGYWXBMPXPyb8EBSNwtzHdbUs2HXd3edUPmgJ9RwmDxHXfRIQQIyfh7q19w6
 fzsKcQmt0AQEg==
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
X-Mailman-Approved-At: Thu, 26 May 2022 19:03:24 +0000
Subject: Re: [bitcoin-dev] MuSig2 BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 26 May 2022 17:34:55 -0000

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