From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 797CBC002D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: AdamISZ Reply-To: AdamISZ Message-ID: In-Reply-To: <7c4395b0-9bc9-78e6-5a46-dc3eddb8e97f@gmail.com> References: <46175970-d2ab-a58e-7010-f29820849604@gmail.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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