MIME-Version: 1.0
References: <mailman.125690.1690381971.956.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.125690.1690381971.956.bitcoin-dev@lists.linuxfoundation.org>
From: Tom Trevethan <tom@commerceblock.com>
Date: Wed, 26 Jul 2023 17:32:06 +0100
Message-ID: <CAJvkSsft_z6s90oVnewmFU66hiURDHSvmGdmQETVJOW1C1xEyQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002afa1006016664e3"
Subject: [bitcoin-dev]  Blinded 2-party Musig2
Precedence: list

--0000000000002afa1006016664e3
Content-Type: text/plain; charset="UTF-8"

@moonsettler

Your scheme for blinding the challenge (e in your notation) works as far as
I can tell. It is better than the way I suggested as it doesn't require
modifying the aggregated pubkey (and the blinding nonce can be different
for each signature).

@AdamISZ and @Jonas

It is not necessarily the server that would need to verify that the
challenge is 'well formed', but the receiver of a statecoin. The concept of
having a blinded statechain server is that each signature generated for a
shared public key must be verified by the receiver of the corresponding
coin. So a receiver would retrieve the number of co-signings performed by
the server (K) and then verify each of the K signatures, and K transactions
that they have received from the sender. They can additionally verify that
each of the K R values has been correctly formed with a proof of secret
value for creating R2 (along with the R1 from the server).

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><a class=3D"gmail_plusreply" id=
=3D"plusReplyChip-0">@</a>moonsettler<br>
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Your =
scheme for blinding the challenge (e in your notation) works as far as I ca=
n tell. It is better=C2=A0than the way I suggested as it doesn&#39;t requir=
e modifying the aggregated pubkey (and the blinding nonce can be different =
for each signature).=C2=A0</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote"><a class=3D"gmail_plusreply" id=3D"plusReplyChip-1">@<=
/a>AdamISZ and @Jonas<br></div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">It is not necessarily the server that would need to ver=
ify that the challenge is &#39;well formed&#39;, but the receiver=C2=A0of a=
 statecoin. The concept of having a blinded statechain server is that each =
signature generated for a shared public key must be verified by the receive=
r of the corresponding coin. So a receiver=C2=A0would retrieve the number o=
f co-signings performed by the server (K) and then verify each of the K sig=
natures, and K transactions that they have received=C2=A0from the sender. T=
hey can additionally verify that each of the K R values has been correctly =
formed with a proof of secret value for creating R2 (along with the R1 from=
 the server).=C2=A0</div></div>

--0000000000002afa1006016664e3--