1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C6C86C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 11:00:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 9B4E340227
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 11:00:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9B4E340227
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=BHrfkiKS
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xSzsEMCe6gbE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 11:00:27 +0000 (UTC)
X-Greylist: delayed 593 seconds by postgrey-1.37 at util1.osuosl.org;
Mon, 24 Jul 2023 11:00:27 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8E8D440182
Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
[185.70.41.103])
by smtp2.osuosl.org (Postfix) with ESMTPS id 8E8D440182
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 11:00:27 +0000 (UTC)
Date: Mon, 24 Jul 2023 10:50:13 +0000
Authentication-Results: mail-41103.protonmail.ch;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.b="BHrfkiKS"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1690195823; x=1690455023;
bh=+v38b5yZxngRGZb5cz3eOM8aUcAlbOwIxyxHCDzhmUY=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=BHrfkiKS5ItdWhevwJc0IBh63e7jNy6/4IZVqtU6tAf5sWWHnyM5h+iLmu+AWSdFV
n7ROaX7fAxpYl3arII6Aeyvc5KjxJ5aEOu7YzS0DTJiZGJko6BH2GTOtFZAqjc1xA7
zG4nrzsJKS3aCT0mLEiq+PVgE0K9+ROH1Is4mMWEDjhW3rMuBd/LCwLkr4t6ZzA4tJ
Zd96JCFxEIe7mLU2ewKiN8EiXAbI6gTeQEoCZtzFh5WfZUP8V53w6DxL4k2OYxAUqD
IhSmLSbERPyI1e6TmgpLSmDEkdq1JSs/Lt94RZ+/YhB9sMOzJHCfFGGnB2dQdouv8m
xReOHp9p5ar6Q==
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
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 11:00:28 -0000
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
|
