path: root/64/1323ec407b4c280cdfe3a2668f9d6abfbfbaec

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 A60F2C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>,
 Jonas Nick <jonasdnick@gmail.com>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <XRFIZf_z1dKNoKvgFJmrgThHcIE_B0JW9mmJL7mE2B2afcgwZn7NuJaK_vXUAvVwWSZ2Nijwz9yhiwYpty6iI3mrJyivdLxL_CtWlEaAhMY=@protonmail.com>
In-Reply-To: <HPRdBVSvEmkPyHkS-175ZYEYyL-ULZAgmhSPh3uwVtfryFOKZUFKUM5QXnSXjwZy3b10sV55f9lhOkZ-ILShaWSWJ7GMN0JmKNweKY6kfLg=@protonmail.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>
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 <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: Tue, 24 May 2022 19:06:52 -0000

------- Original Message -------
On Monday, May 23rd, 2022 at 17:09, AdamISZ via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> 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