path: root/fa/caeddf4314e3955ae00411053c24dc7615a497

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 7E9C7C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 16:08:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 52AE081413
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 16:08:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 52AE081413
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=WD8WUcnB
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 4zaya09q4Bt9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 16:08:42 +0000 (UTC)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [IPv6:2a00:1450:4864:20::533])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 0298B8176C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 16:08:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0298B8176C
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5221c6a2d3dso3405504a12.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 09:08:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1690214920;
 x=1690819720; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=zFW80JyApkfFg44YgPYAM13l7TvsZHRI+vy96QJmL/8=;
 b=WD8WUcnBm2KyCMAXA9zAQ77BSUAsPyKiLZ7CZQDRPRoO6iX/zOuDOSRtzHO4+v1tK/
 Ykb9tgse5PxrgmFTpzWBCXXOkJ3W5UIedTTVL++bUvPxixUeENR0uHc6w5QUNCGBTe4T
 owa3Qz6Q+edKuZ2DrFxP8ITqNYxcQkCL8mdQMdqJBKcVGiz5psVH0gpXX4TVpOHHAxTm
 OFM8mIdVFGXUJuqiC04fOQ4w1kxGzbUvfpLQbsMdwDDzxe2BNMXVjGVd1GwsZ+KVdwba
 bJ+60E9+yylr518sqWzlsAtcsqf4xV1e5o24iUm3JoKzDBK+8Qs3bFTmd+9ZDddeJj5N
 Jv5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1690214920; x=1690819720;
 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=zFW80JyApkfFg44YgPYAM13l7TvsZHRI+vy96QJmL/8=;
 b=CkqY+m4PFXydiO9O8dNRReg+NVrj+hetxdRyfLl7sLWR4SjfhiXYPl8//Och9Uytro
 egS40jD+lh3k2QMneNoQIBVkSEDQpILRvv13n8392A2et8ahOeCZYquD1bx+KYJHcqKj
 Iqs0wNMTYHvxjA23xtwHzAQ20DQ4CsiFAuXYDnbocfLfreaZYOAq03YeK0LOR6M8qX/f
 0DcaXl4t8yvWji/Vrcc+rcPC5BqKCuYBq1Cj1TcCssqVlsdoKm8z5WvRItJp1VC4mUo5
 vA7Mw5+PW1kbzgp/m06f3zR6vj4WoV5FBcVJ7b6j6EyWVJzGZvVhga627XpVWR1lOCZS
 ptug==
X-Gm-Message-State: ABy/qLYm/zkvWmMFjn5w+EwF/lC1SgqLKjmuXbLHG1XA0duGl+pfpEAy
 /FdTOc5Ba1Mw2Wg/mW+1nxOVPC914BiiVlyWTU802YzSVgQW+oQ=
X-Google-Smtp-Source: APBJJlE8mJo6M/W6fMDb3sz/hXs9FQ/tWjbIOKIqWZF+IKHggIpHUoIQzG5o6I2fnvzM7wDHXJ9zs5B1tSXdzR6zdNs=
X-Received: by 2002:a05:6402:12c4:b0:51e:f83:6de6 with SMTP id
 k4-20020a05640212c400b0051e0f836de6mr9134229edx.16.1690214919586; Mon, 24 Jul
 2023 09:08:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
 <4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com>
 <CAJowKg+w+P_+tWbD_Ou7kpPT9j3Xz19mDQqYLd-J5xnM17Argg@mail.gmail.com>
In-Reply-To: <CAJowKg+w+P_+tWbD_Ou7kpPT9j3Xz19mDQqYLd-J5xnM17Argg@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Mon, 24 Jul 2023 17:08:28 +0100
Message-ID: <CAJvkSsc4+RkCFNBKg0E=X4NH9WotDm_fqWg6mPN=qG0=1x-o_A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e05c8b06013dd3c2"
X-Mailman-Approved-At: Mon, 24 Jul 2023 16:37:34 +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, 24 Jul 2023 16:08:46 -0000

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

Hi Eric,

Yes, this was my thinking. The current statechain protocol requires that
the sender of a coin sign the statechain with their public key, which is
then verified by the receiver. The receiver also verifies that this
(sender) public key aggregated with the current server public key
corresponds to the public key (TR address) of the coin. This prevents a
'rogue key' attack by the sender and verifies that this coin cannot be
spent without cooperation of the server.

On Mon, Jul 24, 2023 at 3:25=E2=80=AFPM Erik Aronesty <erik@q32.com> wrote:

> as long as all parties provide a proof of secret key along with their
> public key, that should not be possible
>
> or you can do it as a two-step process where all parties provide a
> commitment to the public key and nobody reveals a public key until that
> commitment is received
>
> or if you want to be paranoid you can do both
>
> On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Tom,
>>
>> Would this allow party 2 to itself be composed of N >=3D 2 parties?
>>
>> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
>> `R` points, not just one each, which are finally aggregated by first
>> combining them using the MuSig() public key compose function.
>> This prevents party 2 from creating an `R` that may allow it to perform
>> certain attacks whose name escapes me right now but which I used to know=
.
>> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
>> requires at least 2 `R` nonces per signatory)
>>
>> Your scheme has only one `R` per party, would it not be vulnerably to
>> that attack?
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with Proton Mail secure email.
>>
>> ------- Original Message -------
>> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
>> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in th=
at
>> it can hold a private key that is required to generate an aggregate
>> signature on an aggregate public key, but that it does not learn either:=
 1)
>> The aggregate public key 2) The aggregate signature and 3) The message (=
m)
>> being signed.
>> >
>> > In the model of blinded statechains, the security rests on the
>> statechain server being trusted to report the NUMBER of partial signatur=
es
>> it has generated for a particular key (as opposed to being trusted to
>> enforce rules on WHAT it has signed in the unblinded case) and the full =
set
>> of signatures generated being verified client side
>> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#b=
linding-considerations
>> >
>> > Given the 2-of-2 musig2 protocol operates as follows (in the following
>> description, private keys (field elements) are denoted using lower case
>> letters, and elliptic curve points as uppercase letters. G is the genera=
tor
>> point and point multiplication denoted as X =3D xG and point addition as=
 A =3D
>> G + G):
>> >
>> > Party 1 generates private key x1 and public key X1 =3D x1G. Party 2
>> generates private key x2 and public key X2 =3D x2G. The set of pubkeys i=
s L =3D
>> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) =3D H(L,X). =
The
>> shared (aggregate) public key X =3D a1X1 + a2X2 where a1 =3D KeyAggCoef(=
L,X1)
>> and a2 =3D KeyAggCoef(L,X2).
>> >
>> > To sign a message m, party 1 generates nonce r1 and R1 =3D r1G. Party =
2
>> generates nonce r2 and R2 =3D r2G. These are aggregated into R =3D R1 + =
R2.
>> >
>> > Party 1 then computes 'challenge' c =3D H(X||R||m) and s1 =3D c.a1.x1 =
+ r1
>> > Party 2 then computes 'challenge' c =3D H(X||R||m) and s2 =3D c.a2.x2 =
+ r2
>> >
>> > The final signature is then (R,s1+s2).
>> >
>> > In the case of blinding this for party 1:
>> >
>> > To prevent party 1 from learning of either the full public key or fina=
l
>> signature seems straightforward, if party 1 doesn't not need to
>> independently compute and verify c =3D H(X||R||m) (as they are blinded f=
rom
>> the message in any case).
>> >
>> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
>> to party 2.
>> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends
>> R1 to party 2.
>> > 3) Party 2 computes c =3D H(X||R||m) and sends it to party 1 in order =
to
>> compute s1 =3D c.a1.x1 + r1
>> >
>> > Party 1 never learns the final value of (R,s1+s2) or m.
>> >
>> > Any comments on this or potential issues would be appreciated.
>> >
>> > Tom
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">Hi Eric,<div><br></div><div>Yes, this was my thinking. The=
 current statechain protocol requires that the sender of a coin sign the st=
atechain with their public key, which is then verified by the receiver. The=
 receiver=C2=A0also verifies that this (sender) public key aggregated=C2=A0=
with the current server public key corresponds to the public key (TR addres=
s) of the coin. This prevents a &#39;rogue key&#39; attack by the sender an=
d verifies that this coin cannot be spent without cooperation of the server=
.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Mon, Jul 24, 2023 at 3:25=E2=80=AFPM Erik Aronesty &lt;<a h=
ref=3D"mailto:erik@q32.com">erik@q32.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">as long as all pa=
rties provide a proof of secret key along with their public key, that shoul=
d not be possible<div dir=3D"auto"><br></div><div dir=3D"auto">or you can d=
o it as a two-step process where all parties provide a commitment to the pu=
blic key and nobody reveals a public key until that commitment is received<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">or if you want to be par=
anoid you can do both</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Good morning Tom,<br>
<br>
Would this allow party 2 to itself be composed of N &gt;=3D 2 parties?<br>
<br>
MuSig2 (as opposed to MuSig1) requires that signatories provide multiple `R=
` points, not just one each, which are finally aggregated by first combinin=
g them using the MuSig() public key compose function.<br>
This prevents party 2 from creating an `R` that may allow it to perform cer=
tain attacks whose name escapes me right now but which I used to know.<br>
(it is the reason why MuSig1 requires 3 round trips, and why MuSig2 require=
s at least 2 `R` nonces per signatory)<br>
<br>
Your scheme has only one `R` per party, would it not be vulnerably to that =
attack?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
Sent with Proton Mail secure email.<br>
<br>
------- Original Message -------<br>
On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev &lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
<br>
&gt; We are implementing a version of 2-of-2 Schnorr Musig2 for statechains=
 where the server (party 1 in the 2-of-2) will be fully &#39;blinded&#39; -=
 in that it can hold a private key that is required to generate an aggregat=
e signature on an aggregate public key, but that it does not learn either: =
1) The aggregate public key 2) The aggregate signature and 3) The message (=
m) being signed.<br>
&gt; <br>
&gt; In the model of blinded statechains, the security rests on the statech=
ain server being trusted to report the NUMBER of partial signatures it has =
generated for a particular key (as opposed to being trusted to enforce rule=
s on WHAT it has signed in the unblinded case) and the full set of signatur=
es generated being verified client side <a href=3D"https://github.com/comme=
rceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/commerceblo=
ck/mercury/blob/master/doc/merc_blind.md#blinding-considerations</a><br>
&gt; <br>
&gt; Given the 2-of-2 musig2 protocol operates as follows (in the following=
 description, private keys (field elements) are denoted using lower case le=
tters, and elliptic curve points as uppercase letters. G is the generator p=
oint and point multiplication denoted as X =3D xG and point addition as A =
=3D G + G):<br>
&gt; <br>
&gt; Party 1 generates private key x1 and public key X1 =3D x1G. Party 2 ge=
nerates private key x2 and public key X2 =3D x2G. The set of pubkeys is L =
=3D {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) =3D H(L,X).=
 The shared (aggregate) public key X =3D a1X1 + a2X2 where a1 =3D KeyAggCoe=
f(L,X1) and a2 =3D KeyAggCoef(L,X2).<br>
&gt; <br>
&gt; To sign a message m, party 1 generates nonce r1 and R1 =3D r1G. Party =
2 generates nonce r2 and R2 =3D r2G. These are aggregated into R =3D R1 + R=
2.<br>
&gt; <br>
&gt; Party 1 then computes &#39;challenge&#39; c =3D H(X||R||m) and s1 =3D =
c.a1.x1 + r1<br>
&gt; Party 2 then computes &#39;challenge&#39; c =3D H(X||R||m) and s2 =3D =
c.a2.x2 + r2<br>
&gt; <br>
&gt; The final signature is then (R,s1+s2).<br>
&gt; <br>
&gt; In the case of blinding this for party 1:<br>
&gt; <br>
&gt; To prevent party 1 from learning of either the full public key or fina=
l signature seems straightforward, if party 1 doesn&#39;t not need to indep=
endently compute and verify c =3D H(X||R||m) (as they are blinded from the =
message in any case).<br>
&gt; <br>
&gt; 1) Key aggregation is performed only by party 2. Party 1 just sends X1=
 to party 2.<br>
&gt; 2) Nonce aggregation is performed only by party 2. Party 1 just sends =
R1 to party 2.<br>
&gt; 3) Party 2 computes c =3D H(X||R||m) and sends it to party 1 in order =
to compute s1 =3D c.a1.x1 + r1<br>
&gt; <br>
&gt; Party 1 never learns the final value of (R,s1+s2) or m.<br>
&gt; <br>
&gt; Any comments on this or potential issues would be appreciated.<br>
&gt; <br>
&gt; Tom<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000e05c8b06013dd3c2--