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
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
|
Delivery-date: Tue, 30 Apr 2024 14:18:42 -0700
Received: from mail-qv1-f56.google.com ([209.85.219.56])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDSJ7DXSQ4PRBKWAYWYQMGQEFTSMDYA@googlegroups.com>)
id 1s1us6-0005n6-Af
for bitcoindev@gnusha.org; Tue, 30 Apr 2024 14:18:42 -0700
Received: by mail-qv1-f56.google.com with SMTP id 6a1803df08f44-6a0dedea1d0sf14579856d6.3
for <bitcoindev@gnusha.org>; Tue, 30 Apr 2024 14:18:42 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1714511916; cv=pass;
d=google.com; s=arc-20160816;
b=LtZEoEMeNFH+Mp5zxqaZL9dWjP2wiQSnwgFlDcIrBFkSjOQgdzUzIk1tLhXJSiOx8Y
Fxd4ENqIkmtnjZ3kqHO3bpup8WhJ7UVPJBx0ZgdSo03TlRTgrlK0iHvKciIMv3yXuhdV
PaxqpljxkWanrZh8spfWe218ILqOwXwbCA6hOmL0a9tmfenYKWFJZ7VRXjKM1gqzd17h
66jG/aZrck0fZ5VgrRXvsjW1XvYAvwSvN0lVIBBSRuxruda4h7OJmTfqq2+8bx4M2icV
COEA2yXV+O0Pxr+MNarigL3TVKS7yAI1wTBh+Qlkzw0fK9vPoUcxPvERRFJLMryqdsis
ppkg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:sender:dkim-signature
:dkim-signature;
bh=Hh0qQyajZHB/ydpEdDKXunYr/ngbREZVnxKUt2ANOJA=;
fh=EZoeadXHwB489K/rHhZi1jJP/CXDElgMrVFCsayNjr8=;
b=kFDI8PtFxXrhlG92arQHyI138Mv58Ud2M/38Yt2PKssRSQqTEN4hIwFpyzTeqxraL8
6TSvWcbL89XnevBBZx9dRD/WRP66ys/F5fmI+ipejfnNT2BfU7oSRqQqVal1kmXvknWv
6wUJiUIa+y4vyJ4jm1fAr0y1STbnctWoapUz1OwoIPEckM/J0c4XNCQlIQOVq4shDym2
NuIKqEhMPE71UcWa5TVNebsZZLeSEdxQthfdGqyHKDRkIZf49BcfXNsCpWb1YrdqYEsO
Ly9upHIU0ybX9CSTi60Wavfw1nUujXFIqb8j3Oqt1nErB3pzmBesyqiZiLtzrgxqKPnG
SMZA==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@gmail.com header.s=20230601 header.b=DDgVD0hG;
spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=eth3rs@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1714511916; x=1715116716; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=Hh0qQyajZHB/ydpEdDKXunYr/ngbREZVnxKUt2ANOJA=;
b=oSxzo64rhCVynmy+7rHuuEP+gvTz0bF98hr3M7ZDzOTooseI3ocRh5Q2VkSndmuYwS
eDtmWysbyDIap0S3Xkm+aIFyOTq4xx9Ez00n4BOWkdVSaMztx3xNI6n++8mxpVgrJ4A6
MKt5zBe8A/hbrrgXMLYKqex9lrWT+X8y3Gf/+R39Jf8W4DigXLEc65ZpSL5RcGK4pkKk
DifNUxl8/0TWWWrbh6rZE9lcjU+43gZ6ZS8RPrunRojKyh0/qLL+agZy48OeFZWjgL8L
1JPbjPjROQ7OFI8CCP98XfOs5ChOjn91IlM5sOQGsdAuGBmN0CHYYAD5lvdMl5dWgZoP
tk2A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1714511916; x=1715116716; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=Hh0qQyajZHB/ydpEdDKXunYr/ngbREZVnxKUt2ANOJA=;
b=Uq5LZRrKr5j2DUSgsVRDqZkdBRbmLTPlNekm5ZPyq4TafyNcJuC0G+kT5jYyqCgKQl
7KiuubhxhEA0lZhNAhJu+rkN2W6vZI6NQhvxfpcovuYInA9VtA75U1XJ8cx/0elRowRD
7unMOGn6YED6yhp+15XW6ZlQSGCZQJXLrASUx6F8h+woWe92h0toDbIQcdd/WkLKpk1L
D0MyFtsKjx6zG8hkQnq3rybghvKaWL+0ZXcQTp5oy+ZEdCB/UDekNUGvCf17zPqk0NLq
wonK3kx7evGHDClLxxz0c/hLU9UVANuQe0P46qn2bwFdAdklBiffdvYbvr1rukHbDBFI
lbgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1714511916; x=1715116716;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:x-beenthere:x-gm-message-state:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=Hh0qQyajZHB/ydpEdDKXunYr/ngbREZVnxKUt2ANOJA=;
b=ZuGOf/03mfgLmppfQFuIXb8ehwCRFvIZUYPbVu+qUeP5m/wW0ysL0jidje2ceDerCQ
uXWFk29/jfUGq48BcWCszucvjclSxJG0ae9cPNq0drNtScKrkfvKy0yXPZzH3e3s3mX8
ZNu3iUgFU7oIAzSxyaPpRN80anaQLZ/dZXXe0isASIypl8Yc9rAXrYdPY8S04H2OWw5j
5L4Ym9hiC0b7572yAqPyqyXa3EG/Fr2nqdZXk/280+MBQJefE8/gYAZdVentc42y345j
PIuxdanbZhivs+1Gwlhae5hqLxj++7aMvujyRSe64PZyVr8c4sW5zFixEwzNAMvk6S76
yL7w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWfzQQXKHjUzuNAdZRCf49Qlr/gqseCvSl2wSTVlSo4bsQw8scCOWCXqvi6ko9Da0/2EcQY+GaTnNZy6mLU3sKmCnyEF+M=
X-Gm-Message-State: AOJu0YxazWZTLN4RnNYkNyrt0le6oHDwlbpY/UQQOcYAUq6IAp0mn8HV
79c5lNabD/VUJv+1r9arRiZtJ+SiJiLLk3NV9TK1vjhk6TOYaKn6
X-Google-Smtp-Source: AGHT+IFcwTXXkp9fuDZ+cZ7Gtvnrvc6hw9H4AZuBIGOAtxNqRXtrZ5JkvI/XY0ksnvvKaaUsmIv02g==
X-Received: by 2002:a05:6214:234d:b0:6a0:af07:1089 with SMTP id hu13-20020a056214234d00b006a0af071089mr717132qvb.55.1714511916051;
Tue, 30 Apr 2024 14:18:36 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6214:250c:b0:69b:a44:bb68 with SMTP id
6a1803df08f44-6a09c4a8853ls13271276d6.0.-pod-prod-00-us; Tue, 30 Apr 2024
14:18:34 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUjQIQ9JGGrONx3KwDK2RZ6mJNcQ7mjb7p0tnIHb++LdKzwTU8d22UpN5bmoXzbnp6Od7nzqnlYAQMscJle6qeupe1ZOMjVFvANB8s=
X-Received: by 2002:ad4:5969:0:b0:6a0:a98a:4878 with SMTP id eq9-20020ad45969000000b006a0a98a4878mr32233qvb.2.1714511914420;
Tue, 30 Apr 2024 14:18:34 -0700 (PDT)
Received: by 2002:a05:620a:2407:b0:790:eff4:844b with SMTP id af79cd13be357-7916dbe7bd3ms85a;
Tue, 30 Apr 2024 13:44:30 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVmYLc/PHZNHYk37ZHxd3kh8ItUVE+Y9w0Jg7aulFKqtTUYIItPd8WUhlxbUfpns0dlKyWtPhlFYW0LmelhvAei1vAKKhvNBxDcQC8=
X-Received: by 2002:adf:f48f:0:b0:345:edfd:9529 with SMTP id l15-20020adff48f000000b00345edfd9529mr578872wro.29.1714509869023;
Tue, 30 Apr 2024 13:44:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1714509869; cv=none;
d=google.com; s=arc-20160816;
b=SBfo85FcGWjkYg0LufHDsGjLe9H4LXLgiGMfbFyozjIT3rpGERrxQIKUdJsSRLGjY1
ljXFz7tRUTW62r6tK2qxiqyHF4Ax3tgyUSD4lv/eBl/FDqPAn33DASopaoyNzDrYFt8z
i7316717tryydgRMSF9lJgzIel+T4LriaAd8enuEZ1J6cPdrLJ7yJQ2k9Y7uwXt/rU5E
qnUB/Ki/WdJJKT9wW1gXiSnmI/e0bMlRdLwzCGcRiMeA3y/DmurSRgMGmtD3sCZg8Jc8
bsiIBjuacwlcSNwh1vykmlaSwcZFP6eUrSQFLH4YYv8itSGMDhmE1EWLAWBXaBjlL1Wc
f58A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:dkim-signature;
bh=TYmAibkRWmL+1ntJG+2fT5o8rPqdO2Qps5h7382JIac=;
fh=GBRPJM1ELqdk//4+4MOmMj3tieiI0Qfg7/bFVUvuWdw=;
b=JUxPYz3VC4gwTl6xf8Ns5MEusH7RITGgIQBn6UVtVxTDTFQkHgonEkXIHHNONVnZ4q
af6axOWrZ5XhSSUhmBgdxnhitrYxpMqtJxxodcMpCzExcFQF/xjobIWtIfvvaNiwuRTD
4BI22vo/dJ3ZkHU1o2MzOxDzgDK5K55nv/ALkj0gPI7I8YlwhKe2gPTfGR7idr6Kh9V/
KJZ1Am0RDA83KMoRz3yKOmD7rnRRZg8s7IoQ6vLjognh/5uD1I8Bw6uQ/Cs6jtuEu5Wu
DBRjijRdthI/1H3OipjgrvqehmwLWfskAU1YP3quIRTeNOD3PfYSnEtaX2Rk/HQyIbd8
OP6Q==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@gmail.com header.s=20230601 header.b=DDgVD0hG;
spf=pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=eth3rs@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com. [2a00:1450:4864:20::630])
by gmr-mx.google.com with ESMTPS id m11-20020a5d64ab000000b0034c09433563si488459wrp.1.2024.04.30.13.44.28
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Tue, 30 Apr 2024 13:44:28 -0700 (PDT)
Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) client-ip=2a00:1450:4864:20::630;
Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a559b919303so799161966b.1
for <bitcoindev@googlegroups.com>; Tue, 30 Apr 2024 13:44:28 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCWeLAC4/5UCPgYLIK00m08PGYDUCA3MBQdLJTUx2GBdaPegsiyux1IrpB5bwSjFX5V8xLtLnZ2MR1065CAU+fOXmbvcLykLV6URZVs=
X-Received: by 2002:a17:906:af94:b0:a55:b7e3:8bf7 with SMTP id
mj20-20020a170906af9400b00a55b7e38bf7mr572262ejb.18.1714509868293; Tue, 30
Apr 2024 13:44:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAEM=y+XyW8wNOekw13C5jDMzQ-dOJpQrBC+qR8-uDot25tM=XA@mail.gmail.com>
<CA+x5asTOTai_4yNGEgtKEqAchuWJ0jGDEgMqHFYDwactPnrgyw@mail.gmail.com> <ZjD-dMMGxoGNgzIg@camus>
In-Reply-To: <ZjD-dMMGxoGNgzIg@camus>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Tue, 30 Apr 2024 16:43:51 -0400
Message-ID: <CAEM=y+UnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw@mail.gmail.com>
Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport
Signatures (no changes needed)
To: Andrew Poelstra <apoelstra@wpsoftware.net>
Cc: Matthew Zipkin <pinheadmz@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000a9e3da0617566f3c"
X-Original-Sender: eth3rs@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@gmail.com header.s=20230601 header.b=DDgVD0hG; spf=pass
(google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::630 as
permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE
sp=QUARANTINE dis=NONE) header.from=gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
--000000000000a9e3da0617566f3c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
One could redesign this scheme to minimize the number of opcodes.
Back of the napkin scheme follows:
Alice, rather than Lamport signing the length of each ECDSA signature,
instead Lamport (or WOTS) signs a vector of the positions of the low-length
ECDSA signatures (low length here means length=3D58 rather than length=3D59=
).
Then the redeem script would only check the length of those particular
signatures and could drop the other other public keys. This saves
significantly on the number of opcodes because we only need to check the
Lamport signature on the vector, no one each signature length and we can
drop unused checked signatures without evaluating them.
Alice's advantage over the attacker is that she gets to fix the positions
of the low length ECDSA signatures after she generates them. This means if
the total number of signatures is N and the number of low length signatures
is M, her advantage over the attacker is (N choose M). For instance if
N=3DM=3D10, to generate 10 59-length signatures, Alice needs to perform
2^(8*10) work. This is because we assume the probability of generating a
58-byte ECDSA signature is 1/256 (1/2^8). However if N=3D40, M=3D10 she onl=
y
needs to perform 2^(8*10)/(40 choose 10) work.
If we assume that we want 80 bits of security, this means we need M=3D10 lo=
w
length ECDCSA signatures (2^(8*10)). The next parameter is how cheap we
want this to be for Alice to compute, we can boost Alice's signing time by
increasing N and remove log2(N choose 10) from the work she needs to
compute the signature. If we want to ensure Alice has to do no more than
2^32 work to sign, then we need N=3D46 or 46 ecdsa signatures.
On Tue, Apr 30, 2024 at 10:21=E2=80=AFAM Andrew Poelstra <apoelstra@wpsoftw=
are.net>
wrote:
> On Tue, Apr 30, 2024 at 08:32:42AM -0400, Matthew Zipkin wrote:
> > > if an attacker managed to grind a 23-byte r-value at a cost of 2^72
> > computations, it would provide the attacker some advantage.
> >
> > If we are assuming discrete log is still hard, why do we need Lamport
> > signatures at all? In a post-quantum world, finding k such that r is 21
> > bytes or less is efficient for the attacker.
> >
>
> Aside from Ethan's point that a variant of this technique is still
> secure in the case that discrete log is totally broken (or even
> partially broken...all we need is that _somebody_ is able to find the
> discrete log of the x=3D1 point and for them to publish this).
>
> Another reason this is useful is that if you have a Lamport signature on
> the stack which is composed of SIZE values, all of which are small
> enough to be manipulated with the numeric script opcodes, then you can
> do covenants in Script.
>
> (Sadly(?), I think none of this works in the context of the 201-opcode
> limit...and absent BitVM challenge-response tricks it's unlikely you can
> do much in the context of the 4MWu block size limit..), but IMO it's a
> pretty big deal that size limits are now the only reason that Bitcoin
> doesn't have covenants.)
>
> --
> Andrew Poelstra
> Director, Blockstream Research
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
>
--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CAEM%3Dy%2BUnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw%40mail.g=
mail.com.
--000000000000a9e3da0617566f3c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One could redesign this scheme to minimize the number of o=
pcodes.<br><br>Back of the napkin scheme follows:<br><br>Alice, rather than=
Lamport signing the length of each ECDSA signature, instead Lamport (or WO=
TS) signs a vector of the positions of the low-length ECDSA signatures (low=
length here means length=3D58 rather than length=3D59). Then the redeem sc=
ript would only check the length of those particular signatures and could d=
rop the other other public keys. This saves significantly on the number of =
opcodes because we only need to check the Lamport signature on the vector, =
no one each signature length and we can drop unused checked signatures with=
out evaluating them.<br><br>Alice's advantage over the attacker is that=
she gets to fix the positions of the low length ECDSA signatures after she=
generates them. This means if the total number of signatures is N and the =
number of low length signatures is M, her advantage over the attacker is (N=
choose M). For instance if N=3DM=3D10, to generate 10 59-length signatures=
, Alice=C2=A0needs to perform 2^(8*10) work. This is because we assume the =
probability of generating a 58-byte ECDSA signature is 1/256 (1/2^8). Howev=
er if N=3D40, M=3D10 she only needs to perform 2^(8*10)/(40 choose 10) work=
.<br><br>If we assume that we want 80 bits of security, this means we need =
M=3D10 low length ECDCSA signatures (2^(8*10)). The next parameter is how c=
heap we want this to be for Alice to compute, we can boost Alice's sign=
ing time by increasing N and remove log2(N choose 10) from the work she nee=
ds to compute the signature. If we want to ensure Alice has to do no more t=
han 2^32 work to sign, then we need=C2=A0N=3D46 or 46 ecdsa signatures.<br>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Tue, Apr 30, 2024 at 10:21=E2=80=AFAM Andrew Poelstra <<a href=3D"mai=
lto:apoelstra@wpsoftware.net">apoelstra@wpsoftware.net</a>> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Apr 30, 2024 =
at 08:32:42AM -0400, Matthew Zipkin wrote:<br>
> > if an attacker managed to grind a 23-byte r-value at a cost of 2^=
72<br>
> computations, it would provide the attacker some advantage.<br>
> <br>
> If we are assuming discrete log is still hard, why do we need Lamport<=
br>
> signatures at all? In a post-quantum world, finding k such that r is 2=
1<br>
> bytes or less is efficient for the attacker.<br>
><br>
<br>
Aside from Ethan's point that a variant of this technique is still<br>
secure in the case that discrete log is totally broken (or even<br>
partially broken...all we need is that _somebody_ is able to find the<br>
discrete log of the x=3D1 point and for them to publish this).<br>
<br>
Another reason this is useful is that if you have a Lamport signature on<br=
>
the stack which is composed of SIZE values, all of which are small<br>
enough to be manipulated with the numeric script opcodes, then you can<br>
do covenants in Script.<br>
<br>
(Sadly(?), I think none of this works in the context of the 201-opcode<br>
limit...and absent BitVM challenge-response tricks it's unlikely you ca=
n<br>
do much in the context of the 4MWu block size limit..), but IMO it's a<=
br>
pretty big deal that size limits are now the only reason that Bitcoin<br>
doesn't have covenants.)<br>
<br>
-- <br>
Andrew Poelstra<br>
Director, Blockstream Research<br>
Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferrer" ta=
rget=3D"_blank">wpsoftware.net</a><br>
Web:=C2=A0 =C2=A0<a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noref=
errer" target=3D"_blank">https://www.wpsoftware.net/andrew</a><br>
<br>
The sun is always shining in space<br>
=C2=A0 =C2=A0 -Justin Lewis-Webster<br>
<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CAEM%3Dy%2BUnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGf=
jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.=
google.com/d/msgid/bitcoindev/CAEM%3Dy%2BUnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6=
_WTWFYGfjw%40mail.gmail.com</a>.<br />
--000000000000a9e3da0617566f3c--
|