path: root/8f/ec41cef8162934d8eb5d3f2376ab8f27942b2d

Return-Path: <tom@commerceblock.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 79455C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 07:46:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4C89B40999
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 07:46:26 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4C89B40999
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=PJZ4vZJJ
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 gJPDLVjfsihg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 07:46:24 +0000 (UTC)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [IPv6:2a00:1450:4864:20::52a])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 4004640998
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 07:46:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4004640998
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5222c5d71b8so1006873a12.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 00:46:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1690184782;
 x=1690789582; 
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=rgs36B5POG5Ic3qX9ehewjb4E0liFwjG7v7gCFYUW8Q=;
 b=PJZ4vZJJT2naFA8bZtbMBVUrsAIpX4DFc66DLRc/3xZn3AN4/opIRqSjXfk2kT2cI9
 PUV8UnX9vybRwgRqrTA3CqJBzz1IGdUf9bFgTSFTvGX9kMvT/gs1lH66F2UgiZMDg3Ba
 bOsRA2cVwMwFrlLQrfQ9Au20tin/HU2RtdtrtxvXIfFIOKMfS2SxX/GFtvTx6BRSmuHk
 KtQuiMW8TshlA3KBCHw6rrE5rdwi6Zgb5H2P6tiyzVbpnLdhZRp/UtadOGuwMqr0ZkG6
 2lKa6YmqakYOvUfixQHcj9/4NoT2/qkTxV9ZVy1KjyTgm5EYpdJ+8F2Ro7nrLFSWt8Sc
 MCYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1690184782; x=1690789582;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=rgs36B5POG5Ic3qX9ehewjb4E0liFwjG7v7gCFYUW8Q=;
 b=MhDBQCRiyXRUqRNikTVyt+QxhlHgbYy/jOeZbOeYqnOq9ZYWPPjuYWd9fIOI9Sajta
 N4JKLvJEDDMavR2LLPtfZM1YVTmp35YijqDD89JYtG/dLiH86N8uEahb01Qs9tRVWNsw
 5XrnzCMhTnePVHdn8Eog/a/WywwCMLnS/ubMiX6k+Bu5+pM/NxJNru4b6H5Y5geXC80R
 iMtEE8xKPO9h2KWUOUplUbHh5BsvQ1pdaeTR7/qqG6w6LcBxQeuX7oQ4A/XnV8XFLmCG
 EY9q4gn07ZcqyHr+wlj8x0c2Y8xwHKqqgmMKiKqsjkRdM0aamQs+VfK0J1luFwIEWApf
 Puow==
X-Gm-Message-State: ABy/qLb8XZg9JZmb/RF6reQC+yGrEvv328BxGSvIOfWdukY6NldkkfTk
 c5wlCQ+fWHPH6xAVofBvxSKeV2AdVhEC+RVWsfxrr9lkoK265O5OFg==
X-Google-Smtp-Source: APBJJlEO9Kl93QfaGqs5J1kwifjK9S+x5S51x+JdvkrYEh72RKriSOXsp28nRCebIVJnRvTEWPZ9nAUWTq/qi1ugjl8=
X-Received: by 2002:a05:6402:12c4:b0:51e:f83:6de6 with SMTP id
 k4-20020a05640212c400b0051e0f836de6mr8125828edx.16.1690184781840; Mon, 24 Jul
 2023 00:46:21 -0700 (PDT)
MIME-Version: 1.0
From: Tom Trevethan <tom@commerceblock.com>
Date: Mon, 24 Jul 2023 08:46:11 +0100
Message-ID: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000086d95b060136cf76"
X-Mailman-Approved-At: Mon, 24 Jul 2023 08:58:34 +0000
Subject: [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 07:46:26 -0000

--00000000000086d95b060136cf76
Content-Type: text/plain; charset="UTF-8"

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 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 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 signatures 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#blinding-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 generator
point and point multiplication denoted as X = xG and point addition as A =
G + G):

Party 1 generates private key x1 and public key X1 = x1G. Party 2 generates
private key x2 and public key X2 = x2G. The set of pubkeys is L = {X1,X2}.
The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The shared
(aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1) and a2 =
KeyAggCoef(L,X2).

To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.

Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
Party 2 then computes 'challenge' c = H(X||R||m) and s2 = 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 final
signature seems straightforward, if party 1 doesn't not need to
independently compute and verify c = H(X||R||m) (as they are blinded from
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 = H(X||R||m) and sends it to party 1 in order to
compute s1 = 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

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

<div dir=3D"ltr">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;bl=
inded&#39; - 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 le=
arn either: 1) The aggregate public key 2) The aggregate signature and 3) T=
he message (m) being signed. <br><br>In the model of blinded statechains, t=
he security rests on the statechain server being trusted to report the NUMB=
ER of partial signatures it has generated for a particular key (as opposed =
to being trusted to enforce rules on WHAT it has signed in the unblinded ca=
se) and the full set of signatures generated being verified client side <a =
href=3D"https://github.com/commerceblock/mercury/blob/master/doc/merc_blind=
.md#blinding-considerations">https://github.com/commerceblock/mercury/blob/=
master/doc/merc_blind.md#blinding-considerations</a><br><br>Given the 2-of-=
2 musig2 protocol operates as follows (in the following description, privat=
e keys (field elements) are denoted using lower case letters, and elliptic =
curve points as uppercase letters. G is the generator point and point multi=
plication denoted as X =3D xG and point addition as A =3D G + G): <br><br>P=
arty 1 generates private key x1 and public key X1 =3D x1G. Party 2 generate=
s 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 sh=
ared (aggregate) public key X =3D a1X1 + a2X2 where a1 =3D KeyAggCoef(L,X1)=
 and a2 =3D KeyAggCoef(L,X2). <br><br>To sign a message m, party 1 generate=
s nonce r1 and R1 =3D r1G. Party 2 generates nonce r2 and R2 =3D r2G. These=
 are aggregated into R =3D R1 + R2. <br><br>Party 1 then computes &#39;chal=
lenge&#39; c =3D H(X||R||m) and s1 =3D c.a1.x1 + r1<br>Party 2 then compute=
s &#39;challenge&#39; c =3D H(X||R||m) and s2 =3D c.a2.x2 + r2 <br><br>The =
final signature is then (R,s1+s2). <br><br>In the case of blinding this for=
 party 1:<br><br>To prevent party 1 from learning of either the full public=
 key or final signature seems straightforward, if party 1 doesn&#39;t not n=
eed to independently compute and verify c =3D H(X||R||m) (as they are blind=
ed from the message in any case). <br><br>1) Key aggregation is performed o=
nly by party 2. Party 1 just sends X1 to party 2. <br>2) Nonce aggregation =
is performed only by party 2. Party 1 just sends R1 to party 2. <br>3) Part=
y 2 computes c =3D H(X||R||m) and sends it to party 1 in order to compute s=
1 =3D c.a1.x1 + r1 <br><br>Party 1 never learns the final value of (R,s1+s2=
) or m. <br><br>Any comments on this or potential issues would be appreciat=
ed. <br><br>Tom<br></div>

--00000000000086d95b060136cf76--