path: root/48/cbab32f34814aea960df8946ba8f59474d1723

Return-Path: <tom@commerceblock.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 87DC0C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Jul 2023 16:06:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 52CC340980
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Jul 2023 16:06:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 52CC340980
Authentication-Results: smtp4.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=gxu/SBH6
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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id sPpy18AhRDw8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Jul 2023 16:06:02 +0000 (UTC)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [IPv6:2a00:1450:4864:20::52f])
 by smtp4.osuosl.org (Postfix) with ESMTPS id A5B144097A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Jul 2023 16:06:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A5B144097A
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-51d95aed33aso8151189a12.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Jul 2023 09:06:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1690301159;
 x=1690905959; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=cwIQutjVbkCblv74bsqbMRodjQnwImHYTMULAxoiNMc=;
 b=gxu/SBH6E2HvX6PJ6nzao66wdvDgCMrPbli/0hRcB3oqA7yghdXMb9KaDNN//S+v3p
 eDZNAT3i7KpG4mOFfdZH/MBEfQ11t4RP6wMM2rf3J6erMulWpKPLH0U8PUxTqfo/SaDc
 Vc2qVJ3Cf0R7smfW+ROOhJMts0wcq8zLuHY0pQq9mcxj+yFTiwpy+LvttOmiZiXunxU9
 MqY1FH2uMHyvyKh4DndsS133cxUi9oQvqxLajpbyVhLPJnaSSE+53KEXYGPQGFymbn8L
 mHkUa18qMCilOUWGpinSJy6Gs3Y28sOJjc+J+Q4JKzR452177HRhxVD0naLJ/szSEKpf
 TKbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1690301159; x=1690905959;
 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=cwIQutjVbkCblv74bsqbMRodjQnwImHYTMULAxoiNMc=;
 b=AkfX7o5jKuT5PbyoOK23mr6+DG3fhQXxuUgtxaXoFu4kPLvRf5f/XtQ0h2bk4fBat+
 6YYWgezoE/xENJHldpeQvhF5uNNnlgz8RwXYiGMqXSKFRfp5CVEGmTPi6Lu8XaT+dlB6
 s888nN3EJkMU4SjZpwxGDHLYRua5dbY+ofAQ+yUGIsPh1dF2+OqV2p3NUao6mBFKLvAp
 qw0T3R71ECOCcagmdGKpDFGhn4L7QKt9kdhU+TK5M1b1H+Hs3vDdQAaIDQBeCyYSIGga
 5FK9UR45afpsON/VKJi2FEs7RSO1q9DkgmY7Ydo8dL39HwESXAA+asqXDQ6Y5ZJlZnis
 A1ww==
X-Gm-Message-State: ABy/qLY66vPs2+wVIZFy0RB5zlRUWKrcqShFgYBjOrNsbO1DkY5259aG
 wZEj6+mUyNuo82lyjyfS6Iz300JIyLsoIfyjFgqT7oHNrPM/RACTlw==
X-Google-Smtp-Source: APBJJlGiDB2rG2PYQ5QBtLxl1Z176Jnyki22hSjUd9S3o4x+egURFf3jZVBeVijEuwYlAZ05m1fOEKIvZGfWSqdRrQY=
X-Received: by 2002:a17:906:30c3:b0:994:19ed:e92b with SMTP id
 b3-20020a17090630c300b0099419ede92bmr11600421ejb.20.1690301159257; Tue, 25
 Jul 2023 09:05:59 -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>
In-Reply-To: <CAJowKgJ61nWBHMfNVx7J+C1QwZZMQ9zUaFQnAw1roXiPfi5O6A@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Tue, 25 Jul 2023 17:05:48 +0100
Message-ID: <CAJvkSsdAVFf44XXXXhXqV7JcnmV796vttHEtNEp=v-zxehUofw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000296970060151e850"
X-Mailman-Approved-At: Tue, 25 Jul 2023 21:18:41 +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: Tue, 25 Jul 2023 16:06:04 -0000

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

Thanks for the replies. As I understand it, the v=3D2 nonces signing protoc=
ol
of musig2 prevents the Wagner attack. Also, that the challenge value c must
be blinded from the server to prevent the server from being able to
determine the signature from the on-chain state.

In addition, in order to update the server (party 1) keyshare when a
statecoin is transferred between users, the key aggregation coefficient
must be set to 1 for each key. The purpose of this coefficient in the
Musig2 protocol is to prevent 'rogue key attacks' where one party can
choose a public key derived from both their own secret key and the inverse
of the other party's public key giving them the ability to unilaterally
produce a valid signature over the aggregate key. However this can be
prevented by the party producing a proof of knowledge of the private key
corresponding to their supplied public key. This can be a signature, which
is produced in any case by signing the statechain state in the mercury
protocol. This signature must be verified by the receiver of a coin (who
must also verify the server pubkey combines with the sender pubkey to get
the coin address) which proves that the server is required to co-sign to
generate any signature for this address.

Here is a modified protocol:

Keygen:

Server generates private key x1 and public key X1 =3D x1.G and sends X1 to
user (party 2)
User generates private key x2 and public key X2 =3D x2.G and (random)
blinding nonce z and computes the aggregate public key X =3D z.(X1 + X2)
(server never learns of X, X2 or z).

Signing:

Server generates nonces r11 and r12 and R11 =3D r11.G and R12 =3D r12.G and
sends R11 and R12 to the user.
User generates nonces r21 and r22 and R21 =3D r21.G and R22 =3D r22.G
User computes R1 =3D R11 + R21 and R2 =3D R12 + R22 and b =3D H(X,(R1,R2),m=
) and
R =3D R1 + b.R2 and c =3D (X,R,m)
User sends the values y =3D cz and b to the server.
Server computes s1 =3D yx1 + r11 + br12 and sends it to the user.
User computes s2 =3D yx2 + r21 + br22 and s =3D s1 + s2 and signature (s,R)

Transfer:

In a statecoin transfer, when receiving a statecoin, in order to verify
that the coin address (i.e. aggregate public key) is shared correctly
between the previous owner and the server, the client must verify the
following:

Retrieve the CURRENT public key from the server for this coin X1.
Retrieve the public key X2 and the blinding nonce z from the sender.
Verify that z.X1 + X2 =3D P the address of the statecoin.
Verify that the sender has the private key used to generate X2: this is
done by verifying the statechain signature over the receiver public key X3
from X2.
This proves that the address P was generated (aggregated) with the server
and can only be signed with cooperation with the server, i.e. no previous
owner can hold the full key.

In order to update the key shares on transfer, the following protocol can
be used:

Server (party 1) generates a random blinding nonce e and sends it to user.
User adds their private key to the nonce: t1 =3D e + x2
Client sends t1 and z to the reciever as part of transfer_msg (encrypted
with the receiver public key X3 =3D x3.G).
Receiver client decrypts t1 and then subtracts their private key x3: t2 =3D=
 e
+ x2 - x3.
Receiver client sends t2 to the server as part of transfer_receiver.
Server the updates the private key share x1_2 =3D x1 + t2 - e =3D x1 + e + =
x2 -
x3 - e =3D x1 + x2 - x3
So now, x1_2 + x3 (the aggregation of the new server key share with the new
client key share) is equal to x1 + x2 (the aggregation of the old server
key share with the old client key share).
The server deletes x1.

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

> posk is "proof of secret key".   so you cannot use wagner to select R
>
> On Mon, Jul 24, 2023 at 1:59=E2=80=AFPM AdamISZ via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> @ZmnSCPxj:
>>
>> yes, Wagner is the attack you were thinking of.
>>
>> And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the
>> R commitments.
>>
>> @Tom:
>> As per above it seems you were more considering MuSig1 here, not MuSig2.
>> At least in this version. So you need the initial commitments to R.
>>
>> Jonas' reply clearly has covered a lot of what matters here, but I wante=
d
>> to mention (using your notation):
>>
>> in s1 =3D c * a1 * x1 + r1, you expressed the idea that the challenge c
>> could be given to the server, to construct s1, but since a1 =3D H(L, X1)=
 and
>> L is the serialization of all (in this case, 2) keys, that wouldn't work
>> for blinding the final key, right?
>> But, is it possible that this addresses the other problem?
>> If the server is given c1*a1 instead as the challenge for signing (with
>> their "pure" key x1), then perhaps it avoids the issue? Given what's on =
the
>> blockchain ends up allowing calculation of 'c' and the aggregate key a1X=
1 +
>> a2X2, is it the case that you cannot find a1 and therefore you cannot
>> correlate the transaction with just the quantity 'c1*a1' which the serve=
r
>> sees?
>>
>> But I agree with Jonas that this is just the start, i.e. the fundamental
>> requirement of a blind signing scheme is there has to be some guarantee =
of
>> no 'one more forgery' possibility, so presumably there has to be some pr=
oof
>> that the signing request is 'well formed' (Jonas expresses it below as a
>> ZKP of a SHA2 preimage .. it does not seem pretty but I agree that on th=
e
>> face of it, that is what's needed).
>>
>> @Jonas, Erik:
>> 'posk' is probably meant as 'proof of secret key' which may(?) be a mixu=
p
>> with what is sometimes referred to in the literature as "KOSK" (iirc the=
y
>> used it in FROST for example). It isn't clear to me yet how that factors
>> into this scenario, although ofc it is for sure a potential building blo=
ck
>> of these constructions.
>>
>> Sent with Proton Mail secure email.
>>
>> ------- Original Message -------
>> On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> > Hi Tom,
>> >
>> > I'm not convinced that this works. As far as I know blind musig is
>> still an open
>> > research problem. What the scheme you propose appears to try to preven=
t
>> is that
>> > the server signs K times, but the client ends up with K+1 Schnorr
>> signatures for
>> > the aggregate of the server's and the clients key. I think it's
>> possible to
>> > apply a variant of the attack that makes MuSig1 insecure if the nonce
>> commitment
>> > round was skipped or if the message isn't determined before sending th=
e
>> nonce.
>> > Here's how a malicious client would do that:
>> >
>> > - Obtain K R-values R1[0], ..., R1[K-1] from the server
>> > - Let
>> > R[i] :=3D R1[i] + R2[i] for all i <=3D K-1
>> > R[K] :=3D R1[0] + ... + R1[K-1]
>> > c[i] :=3D H(X, R[i], m[i]) for all i <=3D K.
>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>> > c[0] + ... + c[K-1] =3D c[K].
>> > - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
>> > - Let
>> > s[K] =3D s[0] + ... + s[K-1].
>> > Then (s[K], R[K]) is a valid signature from the server, since
>> > s[K]G =3D R[K] + c[K]a1X1,
>> > which the client can complete to a signature for public key X.
>> >
>> > What may work in your case is the following scheme:
>> > - Client sends commitment to the public key X2, nonce R2 and message m
>> to the
>> > server.
>> > - Server replies with nonce R1 =3D k1G
>> > - Client sends c to the server and proves in zero knowledge that c =3D
>> > SHA256(X1 + X2, R1 + R2, m).
>> > - Server replies with s1 =3D k1 + c*x1
>> >
>> > However, this is just some quick intuition and I'm not sure if this
>> actually
>> > works, but maybe worth exploring.
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">Thanks for the replies. As I understand it, the v=3D2 nonc=
es signing protocol of musig2 prevents the Wagner attack. Also, that the ch=
allenge value c must be blinded from the server to prevent the server from =
being able to determine the signature from the on-chain state. <br><br>In a=
ddition, in order to update the server (party 1) keyshare when a statecoin =
is transferred between users, the key aggregation coefficient must be set t=
o 1 for each key. The purpose of this coefficient in the Musig2 protocol is=
 to prevent &#39;rogue key attacks&#39; where one party can choose a public=
 key derived from both their own secret key and the inverse of the other pa=
rty&#39;s public key giving them the ability to unilaterally produce a vali=
d signature over the aggregate key. However this can be prevented by the pa=
rty producing a proof of knowledge of the private key corresponding to thei=
r supplied public key. This can be a signature, which is produced in any ca=
se by signing the statechain state in the mercury protocol. This signature =
must be verified by the receiver of a coin (who must also verify the server=
 pubkey combines with the sender pubkey to get the coin address) which prov=
es that the server is required to co-sign to generate any signature for thi=
s address. <br><br>Here is a modified protocol:<br><br>Keygen:<br><br>Serve=
r generates private key x1 and public key X1 =3D x1.G and sends X1 to user =
(party 2)<br>User generates private key x2 and public key X2 =3D x2.G and (=
random) blinding nonce z and computes the aggregate public key X =3D z.(X1 =
+ X2) (server never learns of X, X2 or z). <br><br>Signing:<br><br>Server g=
enerates nonces r11 and r12 and R11 =3D r11.G and R12 =3D r12.G and sends R=
11 and R12 to the user. <br>User generates nonces r21 and r22 and R21 =3D r=
21.G and R22 =3D r22.G<br>User computes R1 =3D R11 + R21 and R2 =3D R12 + R=
22 and b =3D H(X,(R1,R2),m) and R =3D R1 + b.R2 and c =3D (X,R,m)<br>User s=
ends the values y =3D cz and b to the server. <br>Server computes s1 =3D yx=
1 + r11 + br12 and sends it to the user. <br>User computes s2 =3D yx2 + r21=
 + br22 and s =3D s1 + s2 and signature (s,R)<br><br>Transfer:<br><br>In a =
statecoin transfer, when receiving a statecoin, in order to verify that the=
 coin address (i.e. aggregate public key) is shared correctly between the p=
revious owner and the server, the client must verify the following:<br><br>=
Retrieve the CURRENT public key from the server for this coin X1.<br>Retrie=
ve the public key X2 and the blinding nonce z from the sender. <br>Verify t=
hat z.X1 + X2 =3D P the address of the statecoin.<br>Verify that the sender=
 has the private key used to generate X2: this is done by verifying the sta=
techain signature over the receiver public key X3 from X2.<br>This proves t=
hat the address P was generated (aggregated) with the server and can only b=
e signed with cooperation with the server, i.e. no previous owner can hold =
the full key.<br><br>In order to update the key shares on transfer, the fol=
lowing protocol can be used:<br><br>Server (party 1) generates a random bli=
nding nonce e and sends it to user.<br>User adds their private key to the n=
once: t1 =3D e + x2<br>Client sends t1 and z to the reciever as part of tra=
nsfer_msg (encrypted with the receiver public key X3 =3D x3.G).<br>Receiver=
 client decrypts t1 and then subtracts their private key x3: t2 =3D e + x2 =
- x3.<br>Receiver client sends t2 to the server as part of transfer_receive=
r.<br>Server the updates the private key share x1_2 =3D x1 + t2 - e =3D x1 =
+ e + x2 - x3 - e =3D x1 + x2 - x3<br>So now, x1_2 + x3 (the aggregation of=
 the new server key share with the new client key share) is equal to x1 + x=
2 (the aggregation of the old server key share with the old client key shar=
e).<br>The server deletes x1.<br></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 25, 2023 at 3:12=E2=80=AFPM Er=
ik Aronesty &lt;<a href=3D"mailto:erik@q32.com">erik@q32.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
">posk is &quot;proof of secret key&quot;.=C2=A0 =C2=A0so you cannot use wa=
gner to select R</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Mon, Jul 24, 2023 at 1:59=E2=80=AFPM AdamISZ via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">@ZmnSCPxj:<br>
<br>
yes, Wagner is the attack you were thinking of.<br>
<br>
And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the R =
commitments.<br>
<br>
@Tom:<br>
As per above it seems you were more considering MuSig1 here, not MuSig2. At=
 least in this version. So you need the initial commitments to R.<br>
<br>
Jonas&#39; reply clearly has covered a lot of what matters here, but I want=
ed to mention (using your notation):<br>
<br>
in s1 =3D c * a1 * x1 + r1, you expressed the idea that the challenge c cou=
ld be given to the server, to construct s1, but since a1 =3D H(L, X1) and L=
 is the serialization of all (in this case, 2) keys, that wouldn&#39;t work=
 for blinding the final key, right?<br>
But, is it possible that this addresses the other problem?<br>
If the server is given c1*a1 instead as the challenge for signing (with the=
ir &quot;pure&quot; key x1), then perhaps it avoids the issue? Given what&#=
39;s on the blockchain ends up allowing calculation of &#39;c&#39; and the =
aggregate key a1X1 + a2X2, is it the case that you cannot find a1 and there=
fore you cannot correlate the transaction with just the quantity &#39;c1*a1=
&#39; which the server sees?<br>
<br>
But I agree with Jonas that this is just the start, i.e. the fundamental re=
quirement of a blind signing scheme is there has to be some guarantee of no=
 &#39;one more forgery&#39; possibility, so presumably there has to be some=
 proof that the signing request is &#39;well formed&#39; (Jonas expresses i=
t below as a ZKP of a SHA2 preimage .. it does not seem pretty but I agree =
that on the face of it, that is what&#39;s needed).<br>
<br>
@Jonas, Erik:<br>
&#39;posk&#39; is probably meant as &#39;proof of secret key&#39; which may=
(?) be a mixup with what is sometimes referred to in the literature as &quo=
t;KOSK&quot; (iirc they used it in FROST for example). It isn&#39;t clear t=
o me yet how that factors into this scenario, although ofc it is for sure a=
 potential building block of these constructions.<br>
<br>
Sent with Proton Mail secure email.<br>
<br>
------- Original Message -------<br>
On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
<br>
&gt; Hi Tom,<br>
&gt; <br>
&gt; I&#39;m not convinced that this works. As far as I know blind musig is=
 still an open<br>
&gt; research problem. What the scheme you propose appears to try to preven=
t is that<br>
&gt; the server signs K times, but the client ends up with K+1 Schnorr sign=
atures for<br>
&gt; the aggregate of the server&#39;s and the clients key. I think it&#39;=
s possible to<br>
&gt; apply a variant of the attack that makes MuSig1 insecure if the nonce =
commitment<br>
&gt; round was skipped or if the message isn&#39;t determined before sendin=
g the nonce.<br>
&gt; Here&#39;s how a malicious client would do that:<br>
&gt; <br>
&gt; - Obtain K R-values R1[0], ..., R1[K-1] from the server<br>
&gt; - Let<br>
&gt; R[i] :=3D R1[i] + R2[i] for all i &lt;=3D K-1<br>
&gt; R[K] :=3D R1[0] + ... + R1[K-1]<br>
&gt; c[i] :=3D H(X, R[i], m[i]) for all i &lt;=3D K.<br>
&gt; Using Wagner&#39;s algorithm, choose R2[0], ..., R2[K-1] such that<br>
&gt; c[0] + ... + c[K-1] =3D c[K].<br>
&gt; - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].<br=
>
&gt; - Let<br>
&gt; s[K] =3D s[0] + ... + s[K-1].<br>
&gt; Then (s[K], R[K]) is a valid signature from the server, since<br>
&gt; s[K]G =3D R[K] + c[K]a1X1,<br>
&gt; which the client can complete to a signature for public key X.<br>
&gt; <br>
&gt; What may work in your case is the following scheme:<br>
&gt; - Client sends commitment to the public key X2, nonce R2 and message m=
 to the<br>
&gt; server.<br>
&gt; - Server replies with nonce R1 =3D k1G<br>
&gt; - Client sends c to the server and proves in zero knowledge that c =3D=
<br>
&gt; SHA256(X1 + X2, R1 + R2, m).<br>
&gt; - Server replies with s1 =3D k1 + c*x1<br>
&gt; <br>
&gt; However, this is just some quick intuition and I&#39;m not sure if thi=
s actually<br>
&gt; works, but maybe worth exploring.<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000296970060151e850--