MIME-Version: 1.0
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
 <b770096c-e8c4-70f7-8cd7-d74c27181413@gmail.com>
In-Reply-To: <b770096c-e8c4-70f7-8cd7-d74c27181413@gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Mon, 24 Jul 2023 17:22:15 +0100
Message-ID: <CAJvkSscdAw8-Z7quKexjFk1gdXmwpKpP5Q1XEuHbHROGdMBpKg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002cbc5c06013e05de"
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Precedence: list

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

Hi Jonas,

Seems you are right: for every tx, compute c from the on-chain data, and
the server can match the c to the m (tx). So there would need to be a
method for blinding the value of c.

On Mon, Jul 24, 2023 at 4:39=E2=80=AFPM Jonas Nick <jonasdnick@gmail.com> w=
rote:

>  > Party 1 never learns the final value of (R,s1+s2) or m.
>
> Actually, it seems like a blinding step is missing. Assume the server
> (party 1)
> received some c during the signature protocol. Can't the server scan the
> blockchain for signatures, compute corresponding hashes c' =3D H(R||X||m)=
 as
> in
> signature verification and then check c =3D=3D c'? If true, then the serv=
er
> has the
> preimage for the c received from the client, including m.
>

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

<div dir=3D"ltr">Hi Jonas,<div><br></div><div>Seems you are right: for ever=
y tx, compute c from the on-chain data, and the server can match the c to t=
he m (tx). So there would need to be a method for blinding the value of c.=
=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Mon, Jul 24, 2023 at 4:39=E2=80=AFPM Jonas Nick &lt;<a href=
=3D"mailto:jonasdnick@gmail.com">jonasdnick@gmail.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0&gt; Party 1 nev=
er learns the final value of (R,s1+s2) or m.<br>
<br>
Actually, it seems like a blinding step is missing. Assume the server (part=
y 1)<br>
received some c during the signature protocol. Can&#39;t the server scan th=
e<br>
blockchain for signatures, compute corresponding hashes c&#39; =3D H(R||X||=
m) as in<br>
signature verification and then check c =3D=3D c&#39;? If true, then the se=
rver has the<br>
preimage for the c received from the client, including m.<br>
</blockquote></div>

--0000000000002cbc5c06013e05de--