path: root/9e/c7770cf54fce768258f40caa5ef4426cceba2f

Return-Path: <tom@commerceblock.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7748CC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Aug 2023 00:55:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 4ECA381A73
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Aug 2023 00:55:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4ECA381A73
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=AKzXQYhU
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 7yv9xCVn3N9p
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Aug 2023 00:55:52 +0000 (UTC)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [IPv6:2a00:1450:4864:20::436])
 by smtp1.osuosl.org (Postfix) with ESMTPS id EC0C68127D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Aug 2023 00:55:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org EC0C68127D
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-31427ddd3fbso3101500f8f.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 06 Aug 2023 17:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1691369750;
 x=1691974550; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=VNgx+TId/IKNZQIZ/v0yXyst518Kgm+/D1UUX+Bv1yQ=;
 b=AKzXQYhUhOGmtI74/ZRjAlwejtkmTAVaSx21rKulOnUl+cR+QjNZBxVDVzmDH0lVib
 Iomf0e0baogBsE8Jq05jeNDU7rZ98DWy9osGvRu0i0HskCHUYKmjPOaGAqvTVlkSE8pg
 Is9A9bw7gEz/jMmrcQcaS5V8c1CaE9azOof79t0FzeXBwzv+73lOl1wZAupfAeHWxiMc
 QsoNBUlwaWnffX1c4j75cM0dGtcaIvGN9B1azFxVnkGlD+tOmdITIN/3SboRmRXtBf3J
 J8sWWWBokFpzd2bKiqNKwBcfKS9UMqWdXqZaFL1y22OSyeLT3Jqw2IbFCBhBY5TANyPS
 XeLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1691369750; x=1691974550;
 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=VNgx+TId/IKNZQIZ/v0yXyst518Kgm+/D1UUX+Bv1yQ=;
 b=krJBk5nUXr7SFjgufIe2f8YYl+oHp6EqNcf+bb2VWwLJyXSy1zTN8USklUjdWKZV8v
 BdJZC58ohSlpRzC370fvpRhz6sAsrQFK+o8m6/n5i9bLwx0RLUXAC51pJIDNGEtknAB3
 odvAgpR8/KmT0EfSAjXucMP6nWA61BaD9RsJjTqh8hYH9/FkCXalH9mHkNLY2mEZm8CT
 n6YNafhM+pFGRWjd82SzylTT824C3cKyjcYQDNNcUXZDS6edNYy7j+sef3suXCFV4Dnv
 YLDPOstcuhjPSziksJw6/nvsLeVPXZyCbHkeg6gFnV4T5jOkS+OuKfYLUha5++RL/6Mr
 j7Yw==
X-Gm-Message-State: AOJu0YxqDyfIB9bQMd3EqSxbju/KCUVcwv+7wRS6EH5644WLJZFM/8+F
 P9FjquERKgvcKieLyIVaFb5g2wjdgSSFtLYfM7rhpFOMMhwHxhpJrw==
X-Google-Smtp-Source: AGHT+IGc4JVhfKaDNbYNetxFS2MSQjVH8ZYs2SrZhYXU/y1al6eQhjYFpM3urwGHQPSyUcxIlTNDTqUNXUAsyUWtrjw=
X-Received: by 2002:a5d:42c4:0:b0:314:1d53:f3aa with SMTP id
 t4-20020a5d42c4000000b003141d53f3aamr4501732wrr.50.1691369749134; Sun, 06 Aug
 2023 17:55:49 -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>
 <CAJvkSsea+aKJFkNpNxHPAGCxrYwU+8wXOzV-8yH=qacGta++ig@mail.gmail.com>
In-Reply-To: <CAJvkSsea+aKJFkNpNxHPAGCxrYwU+8wXOzV-8yH=qacGta++ig@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Mon, 7 Aug 2023 01:55:38 +0100
Message-ID: <CAJvkSsduvkdhpi=KtTpzXan-wdZrCu9AMbfeZUjuZmfCY774mA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000014d2eb06024ab5e3"
X-Mailman-Approved-At: Tue, 08 Aug 2023 14:06:48 +0000
Subject: Re: [bitcoin-dev] 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: Mon, 07 Aug 2023 00:55:53 -0000

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

A follow up to this, I have updated the blinded statechain protocol
description to include the mitigation to the Wagner attack by requiring the
server to send R1 values only after commitments made to the server of the
R2 values used by the user, and that all the previous computed c values are
verified by each new statecoin owner.
https://github.com/commerceblock/mercury/blob/master/layer/protocol.md

Essentially, the attack is possible because the server cannot verify that
the blinded challenge (c) value it has been sent by the user has been
computed honestly (i.e. c =3D SHA256(X1 + X2, R1 + R2, m) ), however this C=
AN
be verified by each new owner of a statecoin for all the previous
signatures.

Each time an owner cooperates with the server to generate a signature on a
backup tx, the server will require that the owner send a commitment to
their R2 value: e.g. SHA256(R2). The server will store this value before
responding with it's R1 value. This way, the owner cannot choose the value
of R2 (and hence c).

When the statecoin is received by a new owner, they will receive ALL
previous signed backup txs for that coin from the sender, and all the
corresponding R2 values used for each signature. They will then ask the
server (for each previous signature), the commitments SHA256(R2) and the
corresponding server generated R1 value and c value used. The new owner
will then verify that each backup tx is valid, and that each c value was
computed c =3D SHA256(X1 + X2, R1 + R2, m)  and each commitment equals
SHA256(R2). This ensures that a previous owner could not have generated
more valid signatures than the server has partially signed.

On Thu, Jul 27, 2023 at 2:25=E2=80=AFPM Tom Trevethan <tom@commerceblock.co=
m> wrote:

>
> On Thu, Jul 27, 2023 at 9:08=E2=80=AFAM Jonas Nick <jonasdnick@gmail.com>=
 wrote:
>
>> 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] a=
nd
>> define R2[i] =3D r2[i]*G. The attacker chooses r2[i]. The attack wouldn'=
t
>> make
>> sense if he didn't.
>>
>

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

<div dir=3D"ltr"><div>A follow up to this, I have updated the blinded state=
chain protocol description to include the mitigation to the Wagner attack b=
y requiring=C2=A0the server to send R1 values only after commitments made t=
o the server of the R2 values used by the user, and that all the previous c=
omputed c values are verified by each new statecoin=C2=A0owner.=C2=A0</div>=
<div><a href=3D"https://github.com/commerceblock/mercury/blob/master/layer/=
protocol.md">https://github.com/commerceblock/mercury/blob/master/layer/pro=
tocol.md</a></div><div><br></div><div>Essentially, the attack is possible b=
ecause the server cannot verify that the blinded challenge (c) value it has=
 been sent by the user has been computed honestly=C2=A0(i.e. c =3D SHA256(X=
1 + X2, R1 + R2, m) ), however this CAN be verified by each new owner of a =
statecoin=C2=A0for all the previous signatures.=C2=A0</div><div><br></div><=
div>Each time an owner cooperates with the server to generate a signature o=
n a backup tx, the server will require that the owner send a commitment to =
their R2 value: e.g. SHA256(R2). The server will store this value before re=
sponding with it&#39;s R1 value. This way, the owner cannot choose the valu=
e of R2 (and hence c).=C2=A0</div><div><br></div><div>When the statecoin is=
 received by a new owner, they will receive ALL previous signed backup txs =
for that coin from the sender, and all the corresponding R2 values used for=
 each signature. They will then ask the server (for each previous signature=
), the commitments SHA256(R2) and the corresponding server generated R1 val=
ue and c value used. The new owner will then verify that each backup tx is =
valid, and that each c value was computed c =3D SHA256(X1 + X2, R1 + R2, m)=
=C2=A0 and each commitment equals SHA256(R2). This ensures that a previous =
owner could not have generated more valid signatures than the server has pa=
rtially signed.=C2=A0</div><div><br></div><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 27, 2023 at 2:25=E2=80=AFPM Tom=
 Trevethan &lt;<a href=3D"mailto:tom@commerceblock.com">tom@commerceblock.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div><br></d=
iv><div class=3D"gmail_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:jonasdnic=
k@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 rgb(204,204,204);padding-left:1ex">No, proof of knowledge o=
f the r values used 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>
</blockquote></div></div>

--00000000000014d2eb06024ab5e3--