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 A60F2C002D for ; Tue, 24 May 2022 19:06:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 802C1817E4 for ; Tue, 24 May 2022 19:06:52 +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 2GYG0KB3PB3m for ; Tue, 24 May 2022 19:06:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by smtp1.osuosl.org (Postfix) with ESMTPS id 24642817D3 for ; Tue, 24 May 2022 19:06:50 +0000 (UTC) Date: Tue, 24 May 2022 19:06:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1653419207; x=1653678407; bh=0ya4IXRckNygdsC5XRTe+PFhm2xn+cvfsuc3x6Gjsi0=; 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=bgdIDwsrPR8yOBId9LoUWSqEWGDTFjm5GbzbXRmq5lo3Hhlx6D84706+7XlMdYmq/ P94BBFtyn54HtTG0Ug+CihVWct+FG4RgmAtBJ+V9MJuNd/draWc4n1TVHoRjJ/w8rE 2RKTxgxUOEZs/m6eMEM+REWX6wnAiJSlDpr/YNamSD8q2VnL00//8YCXTBSSmPMdVo jZsQkpQn2BcgO5Gqj2/nIpjeXU2/hwKgcUt3MiMoJwXZcWMvacDBW+DnaIqLU1KLDC UWSh96N+CJqaKnOS1vYnZw/vcJgfvmUE0brdeRzq9pd1PW6PG37xG86hpau3sjR/Z5 iMk7Pvp4w4e+A== To: Bitcoin Protocol Discussion , Jonas Nick From: AdamISZ Reply-To: AdamISZ Message-ID: In-Reply-To: References: <46175970-d2ab-a58e-7010-f29820849604@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: Tue, 24 May 2022 19:19:19 +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: Tue, 24 May 2022 19:06:52 -0000 ------- Original Message ------- On Monday, May 23rd, 2022 at 17:09, AdamISZ via bitcoin-dev wrote: > Jonas, all,: > > So I do want to ask a couple further clarifying questions on this point, = but I got rather majorly sidetracked :) > I wonder can you (and other list readers!) take a look at my attempt here= to summarize what is described in Footnote 2 of the draft BIP (as it's rel= ated to this discussion and also .. it's pretty interesting generally!): > > https://gist.github.com/AdamISZ/ca974ed67889cedc738c4a1f65ff620b > > (btw github gists have equation rendering now which is nice!) > > Thanks, > waxwing/AdamISZ > Jonas, list, So given that that's basically correct (see the comments), continuing on th= is point of how to handle duplicate keys: In https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki#ident= ifiying-disruptive-signers we have: "If partial signatures are received over authenticated channels, this metho= d can be used to identify disruptive signers and hold them accountable. Not= e that partial signatures are not signatures. An adversary can forge a part= ial signature, i.e., create a partial signature without knowing the secret = key for the claimed public key." (the gist in the previous message was just fleshing out what's stated there= and in Footnote 2: if you get a "valid" partial sig at index i, it doesn't= mean that the signer at index i knows the key for index i, *if* they also = control index j; it just means they won't be able to produce "valid" partia= l sigs for both indices i and j). (scare quotes "valid" - there is no notion in MuSig2 of a partial signature= as a signature, only the aggregate signature in toto is valid or invalid o= r forged). So we see in the above quote, that the concept of 'authenticated channels' = is rather important. Consider 2 scenarios: 1. "Persistent": Every signer has a persistent identity across many signing= sessions, and their communications are authenticated against that identity= . 2. "Spontaneous": Signers join the protocol in some ad hoc way, but authent= icate specifically inasmuch as they set up temporary nyms and use e.g. diff= ie hellman to establish a confidential and authenticated channel for the pe= riod of this signing session. An example of "Spontaneous" might be: a variant of a multiparty channel con= struction with anonymous participants on LN or LN* in which participants se= t up such constructions ad hoc e.g. via liquidity markets .. in contrast, e= .g. a hardware wallet multisig setup with a known provider might be a "Pers= istent" case. Not sure, but ... are we mainly talking about the "Spontaneous" case? Because the "Persistent" case doesn't seem interesting: If I "know" the cou= nterparty that I'm engaging in this protocol with, first, a Sybil at two in= dices is kinda weird, so the occurrence of a duplicated key from them tells= me something is wrong and manual intervention is needed (or equivalently s= ome sanity check in the meta-protocol). Often (e.g. cold storage, devices) = there'd be a way to know in advance what the keys *should* be. It's very li= kely a bug. (I suppose you could argue waiting till the second signing roun= d helps, because it helps us isolate the bug (except it might not, if in ce= rtain protocols, both signers have access to some shared keys, but, meh) ..= . but that doesn't seem convincing ... executing more of a protocol when yo= u already know the implementation is broken seems unwise). So, to the "Spontaneous" case: if we see two identical pubkeys from two pse= ud/anonymous counterparties, I can see the argument for waiting until parti= al sig sending occurs, before establishing misbehaviour. The main substance= of the argument seems to be something like: we can't actually deduce adver= sarial behaviour at key exchange time, so we *have* to wait for the partial= signature step. I'm objecting to this on two fronts: * A general principle of security should be 'abort early'. It's to me just = sensibly conservative to not continue given the substantial risk of bugs (e= sp. in systems exposed to nonce-fragility!) * The claim that the protocol laid out in the BIP identifies misbehaviour s= eems to be at best partially correct, it cannot be true in the general case= . Jonas has already countered my first bullet point by stating that this abor= t-early (at key exchange) strategy opens up an unlimited DOS vector. My cou= nter here is that that, because of the second bullet oint, the DOS vector r= emains, in the "Spontaneous" case, anyway; and that the only way to close i= t is to use either identities (switch to "Persistent": see e.g. Coinshuffle= which registers identities via inputs), or cost. (Why does the DOS vector remain? Because of the partial sig "validation" is= sue as per my gist and Footnote2: if key 3 and key 4 are identical in a set= of 5, we can wait, and then find that partial sig 3 verifies, and partial = sig 4 *also* verifies, and only at index 5 do we see an 'invalid' partial s= ig. If the adversary (as seems extremely likely.. I can't imagine it being = otherwise) has used two *different* nyms for his two adversarial indices 4 = and 5, then ejecting 5 doesn't really seem to close the DOS potential? If w= e then restart and 'grab another anonymous nym' for the 5th index, can't it= be the adversary again? And haven't we let the adversary stay, at index 4?= (though I'm not sure the implications)). Another way to look at it, I'm saying that this claim: "In contrast, MuSig2 is designed to identify disruptive signers at signing = time: any signer who prevents a signing session from completing successfull= y by sending incorrect contributions in the session can be identified and h= eld accountable (see below)." isn't *fully* correct. That is, for sure the algorithm will identify a disr= uptive signer who simply operates one key, but it doesn't (as current) alwa= ys identify every key owned by a disruptive signer. So it doesn't close the= DOS vector. (To be clear the whole 'fake partial sig' adversarial behaviour is *not* sp= ecific to having duplicate public keys; I'm just discussing whether the pro= tocol should continue if duplicates are seen). So overall I have the feeling that allowing duplicate keys at setup makes t= he implementation messier (and this protocol is complex, so that matters a = bit more), and it strikes me as risky in the inevitable presence of impleme= ntation errors. Cheers, waxwing/AdamISZ