Date: Mon, 24 Jul 2023 10:50:13 +0000
To: Tom Trevethan <tom@commerceblock.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com>
In-Reply-To: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Precedence: list

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 combinin=
g them using the MuSig() public key compose function.
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.
(it is the reason why MuSig1 requires 3 round trips, and why MuSig2 require=
s 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 <bitco=
in-dev@lists.linuxfoundation.org> wrote:


> We are implementing a version of 2-of-2 Schnorr Musig2 for statechains wh=
ere the server (party 1 in the 2-of-2) will be fully 'blinded' - in that 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 aggr=
egate public key 2) The aggregate signature and 3) The message (m) being si=
gned.
>=20
> In the model of blinded statechains, the security rests on the statechain=
 server being trusted to report the NUMBER of partial signatures it has gen=
erated for a particular key (as opposed to being trusted to enforce rules o=
n WHAT it has signed in the unblinded case) and the full set of signatures =
generated being verified client side https://github.com/commerceblock/mercu=
ry/blob/master/doc/merc_blind.md#blinding-considerations
>=20
> Given the 2-of-2 musig2 protocol operates as follows (in the following de=
scription, private keys (field elements) are denoted using lower case lette=
rs, and elliptic curve points as uppercase letters. G is the generator poin=
t and point multiplication denoted as X =3D xG and point addition as A =3D =
G + G):
>=20
> Party 1 generates private key x1 and public key X1 =3D x1G. Party 2 gener=
ates 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 KeyAggCoef(L,=
X1) and a2 =3D KeyAggCoef(L,X2).
>=20
> To sign a message m, party 1 generates nonce r1 and R1 =3D r1G. Party 2 g=
enerates nonce r2 and R2 =3D r2G. These are aggregated into R =3D R1 + R2.
>=20
> Party 1 then computes 'challenge' c =3D H(X||R||m) and s1 =3D c.a1.x1 + r=
1
> Party 2 then computes 'challenge' c =3D H(X||R||m) and s2 =3D c.a2.x2 + r=
2
>=20
> The final signature is then (R,s1+s2).
>=20
> In the case of blinding this for party 1:
>=20
> To prevent party 1 from learning of either the full public key or final s=
ignature seems straightforward, if party 1 doesn't not need to independentl=
y compute and verify c =3D H(X||R||m) (as they are blinded from the message=
 in any case).
>=20
> 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
>=20
> Party 1 never learns the final value of (R,s1+s2) or m.
>=20
> Any comments on this or potential issues would be appreciated.
>=20
> Tom