path: root/af/a1f10c02a29ad3fb21afc62fc2359dd596532f

Return-Path: <tom@commerceblock.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D9317C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 13:25:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id ACC0F83993
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 13:25:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ACC0F83993
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=commerceblock-com.20221208.gappssmtp.com
 header.i=@commerceblock-com.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=q/dLpHaB
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 DTMT0ip_cAE4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 13:25:48 +0000 (UTC)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [IPv6:2a00:1450:4864:20::136])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 9A6D08309A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 13:25:47 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9A6D08309A
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-4fdd31bf179so1697952e87.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 06:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1690464345;
 x=1691069145; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=NSuVLb1L3ev5Ubl/03IPWgCaSBRJcqs31RdwDYYM5pU=;
 b=q/dLpHaB91v3QdB9G5MuwpfE6C7SFYnA1o8Ufb8VkuXTosqJZ8ooqGfVTrcNGI3TNS
 8LEpM4V9WUNHo0X1g4TMyaSB7+iI46jbCcp/fPoqPugeGt/+DAAndmFJr/3j9ak3eV3z
 ssQlUx4Rqpz00b6/ZXfVqxW9egQk4mZqwV3qvHCm7atoBHYaZI8NotWe08YYvbf54tK8
 LyZrNVM91cEXwTi6A5yYtsmFFCjnH2uVm7/zphG31JA87J1jxfZiy5vHKi7qHrZlKohA
 1HjCOA+O+OXQvzkxrKHIIzI5zr9rKiXr8El9U0Ic9CQB7G7Vkt7+u5pZNiskho/SVc4N
 yNZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1690464345; x=1691069145;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=NSuVLb1L3ev5Ubl/03IPWgCaSBRJcqs31RdwDYYM5pU=;
 b=cXVLZA3xZuTD/aNFZJq+i7Tofths4LPS06/U2Sfx2QdU1iDcE/WZt82L8cYGwneOu6
 W40T8odQRDrpbdcvmr++FeMc167AFwVN4gQYgh5TWAVWdin8J53MaTm9AlEc8ig2KvGr
 vuhF6ksEK9B6U1Tj7rIxRRhbGkb4j39kRqZTaq0LoXL50CvD1y+ygKzk/MkCNAuT4PBs
 X31qt+eOXO1IPjfFArpUwLYq3YLkIMOn1tQXArn+4kpZoABKkPP/Qz++OzwMLqKmdB+5
 /QS49WaAEgPx1yJKu36OIf3NgjLEfrBY70a+YL1/TzkMJahaj0oEazRpERdIM/Js+xan
 siUg==
X-Gm-Message-State: ABy/qLbNnSEL0/W+22FwDHlBjP2f29D2tcKnEqsGIp5jtTzZd2G++v8A
 6V6RFo/DQaK/QidE96Uw1WzbxFNqaViJV7ui6MgcHnh/VGj6vqk=
X-Google-Smtp-Source: APBJJlEDEv5WCsxqp+1PofLeBG+AreNkCxMqrnJ7Rnrvln/HFaGck+CrFkGsgNW/7uePdB4MxIoPdRxr05ECnoTTs24=
X-Received: by 2002:a19:710f:0:b0:4fe:ef9:c8d0 with SMTP id
 m15-20020a19710f000000b004fe0ef9c8d0mr1640407lfc.35.1690464344708; Thu, 27
 Jul 2023 06:25:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
 <ca674cee-6fe9-f325-7e09-f3efda082b6b@gmail.com>
 <YwMiFAEImHAJfAHHU7WbN1C1JuHjh0vC18Hn61QplFOlY5mEgKmjsAlj2geV1-28E36_wgfL9_QHTRJsbtOLt73o9C4JfoVt8scvYGzKHOI=@protonmail.com>
 <CAJowKgJ61nWBHMfNVx7J+C1QwZZMQ9zUaFQnAw1roXiPfi5O6A@mail.gmail.com>
 <CAJvkSsdAVFf44XXXXhXqV7JcnmV796vttHEtNEp=v-zxehUofw@mail.gmail.com>
 <CAJowKgJFHzXEtJij4K0SR_KvatTZMDfUEU40noMzR2ubj8OSvA@mail.gmail.com>
 <c5ae9d75-e64f-1565-93d0-e2b5df45d3f4@gmail.com>
 <CAJvkSsdRCHA6pB0mMY-7SE4GbDodAR34_RMgPrhEZAAq_8O2Aw@mail.gmail.com>
 <7eae57c9-be42-ae07-9296-ae9e8e03c1b8@gmail.com>
 <CAJvkSsfa8rzbwXiatZBpwQ6d4d94yLQifK8gyq3k-rq_1SH4OQ@mail.gmail.com>
In-Reply-To: <CAJvkSsfa8rzbwXiatZBpwQ6d4d94yLQifK8gyq3k-rq_1SH4OQ@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Thu, 27 Jul 2023 14:25:33 +0100
Message-ID: <CAJvkSsea+aKJFkNpNxHPAGCxrYwU+8wXOzV-8yH=qacGta++ig@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c5b71a060177e63a"
X-Mailman-Approved-At: Fri, 28 Jul 2023 00:40:18 +0000
Subject: [bitcoin-dev] Fwd:  Blinded 2-party Musig2
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, 27 Jul 2023 13:25:49 -0000

--000000000000c5b71a060177e63a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@Jonas

OK, thanks, I get the logic now. I believe this attack can be mitigated (at
least in the case of using this scheme for statechains) by the receiver of
a coin verifying the construction of all previous challenges.

So in this case, the sender of a coin would record R2[K-1] in addition to m
(and any c blinding nonce used) for the signature it generates with the
server. It would then send this (and all previous R2 values i =3D 0, ...,
K-2) to the receiver.

The receiver would then query the server for the full set (i =3D 0, ..., K-=
1)
of R1[i] values it has generated, and the corresponding (blinded) c[i]
values used for each co-signing it has performed on this key. The
receiver would then verify that each previous c[i] (i =3D 0, ... K-1) has
been correctly formed and includes the server generated R1[i].

If any of the c values fail to verify against the values of R1 provided by
the server, then the coin is invalid.

On Thu, Jul 27, 2023 at 9:08=E2=80=AFAM Jonas Nick <jonasdnick@gmail.com> w=
rote:

> No, proof of knowledge of the r values used to generate each R does not
> prevent
> Wagner's attack. I wrote
>
>  >   Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>  >    c[0] + ... + c[K-1] =3D c[K].
>
> You can think of this as actually choosing scalars r2[0], ..., r2[K-1] an=
d
> define R2[i] =3D r2[i]*G. The attacker chooses r2[i]. The attack wouldn't
> make
> sense if he didn't.
>

--000000000000c5b71a060177e63a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr"><div><a cl=
ass=3D"gmail_plusreply" id=3D"m_3497204169207510401plusReplyChip-2">@Jonas<=
/a><br></div><div><br></div><div>OK, thanks, I get the logic now. I believe=
 this attack can be mitigated (at least in the case of using this scheme fo=
r statechains) by the receiver of a coin verifying the construction of all =
previous challenges.=C2=A0</div><div><br></div><div>So in this case, the se=
nder of a coin would record R2[K-1] in addition to m (and any c blinding no=
nce used) for the signature it generates with the server. It would then sen=
d this (and all previous R2 values i =3D 0, ..., K-2) to the receiver.=C2=
=A0</div><div><br></div><div>The receiver would then query the server for t=
he full set (i =3D 0, ..., K-1) of R1[i] values it has generated, and the c=
orresponding (blinded) c[i] values used for each co-signing it has performe=
d on this key. The receiver=C2=A0would then verify that each previous c[i] =
(i =3D 0, ... K-1) has been correctly formed and includes the server genera=
ted R1[i].=C2=A0</div><div><br></div><div>If any of the c values fail to ve=
rify against the values of R1 provided by the server, then the coin is inva=
lid.=C2=A0<a class=3D"gmail_plusreply"><br></a></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 27, 2023 at 9:08=
=E2=80=AFAM Jonas Nick &lt;<a href=3D"mailto:jonasdnick@gmail.com" target=
=3D"_blank">jonasdnick@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">No, proof of knowledge of the r values use=
d to generate each R does not prevent<br>
Wagner&#39;s attack. I wrote<br>
<br>
=C2=A0&gt;=C2=A0 =C2=A0Using Wagner&#39;s algorithm, choose R2[0], ..., R2[=
K-1] such that<br>
=C2=A0&gt;=C2=A0 =C2=A0 c[0] + ... + c[K-1] =3D c[K].<br>
<br>
You can think of this as actually choosing scalars r2[0], ..., r2[K-1] and<=
br>
define R2[i] =3D r2[i]*G. The attacker chooses r2[i]. The attack wouldn&#39=
;t make<br>
sense if he didn&#39;t.<br>
</blockquote></div></div>
</div></div>

--000000000000c5b71a060177e63a--