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
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4F3B6C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 May 2023 04:38:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 1485E4059D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 May 2023 04:38:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1485E4059D
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=kb8jbwVs
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-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 EGAqoO1LHf7x
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 May 2023 04:38:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D09BB40547
Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com
[IPv6:2607:f8b0:4864:20::112c])
by smtp4.osuosl.org (Postfix) with ESMTPS id D09BB40547
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 May 2023 04:38:16 +0000 (UTC)
Received: by mail-yw1-x112c.google.com with SMTP id
00721157ae682-55a64f0053fso61053067b3.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 May 2023 21:38:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1683520696; x=1686112696;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=Lwv1JmoWD7od9veF4V83yiX38Q6AAkLicLcXCb1CoT4=;
b=kb8jbwVsMK3fvNcbAaKns1lylqtn+vNFVE2l725X7EYakgh/pqhy8amaro54k/dL3L
AlzRZzqLydiGeica1umJkvh1CAtiJ4TErvDmhEKxt2dPlT4vc6Z4Cd4UqIzS3DR0EVd2
OUpRWODO9OUOuAYvwfGQhBtZ+QPU0pTkVztGssaK+214rMUV/hxY17XmVygb0zXALsgQ
Y8ELfdWPDzRrRU+RFyPZjGOuBWNxjwek4GkwqHlE+ZG/ohGMApZFlDnWp75r9pme9GLt
JjcTvmQ0sL60F/6I8BtyawxtIsVoq5x5ZEEVDQf8+ipealbhdpfXdw7rHc2ItZPaYXQJ
xVqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1683520696; x=1686112696;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=Lwv1JmoWD7od9veF4V83yiX38Q6AAkLicLcXCb1CoT4=;
b=EmySik14JuMvd4YGeYDvddt5qhMwI7EeBNYZXhhp0ZtxTchLvAdsvmIbNBxtzn5tVl
nHkBsrne17048WyAhShyrqqAcbSuGrofgn9nRlDuNSHOPcW54BSf57HFqrMCuE+bEtdw
LTmtmtilxYibAcc8paeqmn2BA0q4LFfZH51/cK/37UtEiFznHQlhaDpP+PeOdyfSkQLI
0tFxhhmwW4W/pO7p38NkUiDqxu9eyg30w5dqjO/SpL0aaEDY2muKg7Ou+0rw5JNrRhuA
SRcfMZBcQPA2atbxCzQroMP9zcO0E+RoQ9M+aPyn+NFoMAz5+M+if1ZM1awk6w5l6ZaM
scvw==
X-Gm-Message-State: AC+VfDz0rEKzFEuXsiDJ8L/GN46MVvAveEmiDvSlZTCn3DRX470b7iD9
tEIq43YC1d45prmJFtnEeSa4YdoXNZ55DIfHlzY=
X-Google-Smtp-Source: ACHHUZ7l+1m1cxXkmxPv0eQVPJzM7H78QfHTgoS7WQfVvUOPWfVdbdiraPCN38TdMpCiseGXIUKlS9An/OamqVrcPqs=
X-Received: by 2002:a81:a0d5:0:b0:54f:bec1:c106 with SMTP id
x204-20020a81a0d5000000b0054fbec1c106mr7407442ywg.45.1683520695624; Sun, 07
May 2023 21:38:15 -0700 (PDT)
MIME-Version: 1.0
References: <Vv-Zz519CQs1JkS8NgeHfI-KGaYelNTxKMikPxdeIRiELmPKlT80g_-BzDgBvpm9MMIr-BRrSyGePC-HFR18QU4uzC0rPJdMzO_hlkUhUaM=@protonmail.com>
<CAH5Bsr28mgcLjO43pJKmk7HYKqp9m2eJ0UcGfgOS+H4sFqcTYw@mail.gmail.com>
<LGjk2u_f-UzBsQzz3ZNHt4EeBrf33soxaQMXpmR5-10_zPBirPJhcNvHpNReC9JUAi806J9b4-4Gb1c7I8y77AT9KFwBC8yD2An0mh1mhUQ=@protonmail.com>
In-Reply-To: <LGjk2u_f-UzBsQzz3ZNHt4EeBrf33soxaQMXpmR5-10_zPBirPJhcNvHpNReC9JUAi806J9b4-4Gb1c7I8y77AT9KFwBC8yD2An0mh1mhUQ=@protonmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Mon, 8 May 2023 12:37:48 +0800
Message-ID: <CAH5Bsr0wQVqi1+r6z0vk8X9UpKyYVAfB_87giUpV=FesmPitrg@mail.gmail.com>
To: AdamISZ <AdamISZ@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000008e69805fb273555"
X-Mailman-Approved-At: Mon, 08 May 2023 11:54:58 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On adaptor security (in protocols)
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, 08 May 2023 04:38:18 -0000
--00000000000008e69805fb273555
Content-Type: text/plain; charset="UTF-8"
Hi Waxwing,
On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ@protonmail.com> wrote:
> Hi Lloyd,
> thanks for taking a look.
>
> > I think your view of the uselessness of single signer adaptors is too
> pessimistic. The claim you make is that they "don't provide a way to create
> enforcement that the publication of signature on a pre-defined message will
> reveal a secret'' and so are useless. I think this is wrong. If I hold a
> secret key for X and create a signature adaptor with some encryption key Y
> with message m and do not create any further signatures (adaptor or
> otherwise) on m, then any signature on m that is published necessarily
> reveals the secret on Y to me. This is very useful and has already been
> used for years by DLCs in production.
>
> I'm struggling with this one - say I hold privkey x for pubkey X. And I
> publish adaptor for a point Y (DL y) for message m, like: s' = k - y +
> H(R|X|m)x with k the nonce and R the nonce point.
>
> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of
> course the secret y is revealed.
>
> What do you mean in saying "any signature on m that is published reveals
> y"? Clearly you don't mean any signature on any key (i.e. not the key X).
> But I also can't parse it if you mean "any signature on m using key X",
> because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no
> algebraic relationship to the adaptor s' as defined above, right?
>
Yes but suppose you do *not* create another signature adaptor or otherwise
on m. Since you've only generated one adaptor signature on m and no other
signatures on m there is no possibility that a signature on m that appears
under your key would not reveal y to you. This is an useful property in
theory and in practice.
>
> I think the point of confusion is maybe about the DLC construct? I
> referenced that in Section 4.2, parenthetically, because it's analogous in
> one sense - in MuSig(2) you're fixing R via a negotiation, whereas in
> Dryja's construct you're fixing R "by definition". When I was talking about
> single key Schnorr, I was saying that's what's missing, and thereby making
> them useless.
>
>
I was not referencing the DLC oracle attestation protocol - I am pointing
out that DLC client implementations have been using single signer adaptor
signatures as signature encryption in practice for years for the
transaction signatures. There are even channel implementations using them
as well as atomic swaps doing this iirc. It's a pretty useful thing!
Cheers,
LL
--00000000000008e69805fb273555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Waxwing,<br></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Tue, 2 May 2023 at 02:37, AdamISZ &=
lt;<a href=3D"mailto:AdamISZ@protonmail.com">AdamISZ@protonmail.com</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div sty=
le=3D"font-family:Arial,sans-serif;font-size:14px"></div><span>Hi Lloyd,</s=
pan><div><span>thanks for taking a look.</span></div><div><br></div><div><s=
pan>> I think your view of the uselessness of single signer adaptors is =
too pessimistic. The claim you make is that they "don't provide a =
way to create enforcement that the publication of signature on a pre-define=
d message will reveal a secret'' and so are useless. I think this i=
s wrong. If I hold a secret key for X and create a signature adaptor with s=
ome encryption key Y with message m and do not create any further signature=
s (adaptor or otherwise) on m, then any signature on m that is published ne=
cessarily reveals the secret on Y to me. This is very useful and has alread=
y been used for years by DLCs in production.</span></div><div><br></div><di=
v><span>I'm struggling with this one - say I hold privkey x for pubkey =
X. And I publish adaptor for a point Y (DL y) for message m, like: s' =
=3D k - y + H(R|X|m)x with k the nonce and R the nonce point.</span></div><=
div><br></div><div><span>And to get the basics clear first, if I publish s =
=3D k + H(R|X|m)x then of course the secret y is revealed.</span></div><div=
><br></div><div><span>What do you mean in saying "any signature on m t=
hat is published reveals y"? Clearly you don't mean any signature =
on any key (i.e. not the key X). But I also can't parse it if you mean =
"any signature on m using key X", because if I go ahead and publi=
sh s =3D k_2 + H(R_2|X|m)x, it has no algebraic relationship to the adaptor=
s' as defined above, right?</span></div></blockquote><div><br></div><d=
iv>Yes but suppose you do *not* create another signature adaptor or otherwi=
se on m. Since you've only generated one adaptor signature on m and no =
other signatures on m there is no possibility that a signature on m that ap=
pears under your key would not reveal y to you. This is an useful property =
in theory and in practice.<br></div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div><br></div><div><span>I think the poin=
t of confusion is maybe about the DLC construct? I referenced that in Secti=
on 4.2, parenthetically, because it's analogous in one sense - in MuSig=
(2) you're fixing R via a negotiation, whereas in Dryja's construct=
you're fixing R "by definition". When I was talking about si=
ngle key Schnorr, I was saying that's what's missing, and thereby m=
aking them useless.</span></div><div><br></div></blockquote><div>=C2=A0</di=
v><div>I was not referencing the DLC oracle attestation protocol - I am poi=
nting out that DLC client implementations have been using single signer ada=
ptor signatures as signature encryption in practice for years for the trans=
action signatures. There are even channel implementations using them as wel=
l as atomic swaps doing this iirc. It's a pretty useful thing!<br></div=
><div><br></div><div>Cheers,</div><div><br></div><div>LL<br></div></div></d=
iv>
--00000000000008e69805fb273555--
|
