summaryrefslogtreecommitdiff
path: root/fa/206d5e51e2e70bd27cf626566150c1e638a2ab
blob: e7a58fb86d24210cf9999e9e2f4bd2eb6a25439f (plain)
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
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
Return-Path: <g.andrew.stone@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EC053C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Dec 2023 04:52:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id C316483DE0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Dec 2023 04:52:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C316483DE0
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=JlORJ8WP
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Hj6TOuvKMHhR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Dec 2023 04:52:21 +0000 (UTC)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com
 [IPv6:2607:f8b0:4864:20::1034])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 401F883DAF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 22 Dec 2023 04:52:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 401F883DAF
Received: by mail-pj1-x1034.google.com with SMTP id
 98e67ed59e1d1-28b09aeca73so1071617a91.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Dec 2023 20:52:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1703220740; x=1703825540;
 darn=lists.linuxfoundation.org; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=knpTT66wbOajKor9wXNZAK9SxjE+DbBKkaqUaR4+YEc=;
 b=JlORJ8WPbs67NMrR4v0OjTPsD3afX9KbxFnpzRlgUnpPgd9v+5p+g8SLwhOJzAzp2p
 dAUEPePe145FeqrzDwb6VlbfbEUIvnVcDDj4gc/86qewQM4OoX/32YWMgeBGhbYpYRE5
 a/1bhBbnRgk6tWkwDUq9L+jZD0CXIkZ/UyE7iVdQ3ymTuriChiiO6T5/5y+MpnnnjBEG
 ahUd5jwp64GvebTik9bNezPwHyxEryP/Y5eNVVx/wpre0RMvW6z0yPcOst/mCMx6+ztD
 kUxzsHf0gWg0dng6+dOYUYYr3QKUrzRV/OJaMIUgWw3FSeZ5aWW1TblnKSchigwDw0oR
 XkCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1703220740; x=1703825540;
 h=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=knpTT66wbOajKor9wXNZAK9SxjE+DbBKkaqUaR4+YEc=;
 b=sDrCkA2Sqi+m/KK5VX3w3yR6yL1ZfmntLXCs4Cyq1OTjIPdMYrDI/O+xgEpRPIksqe
 u3MtOcnybhd8qtPVY+SgZZPgcZIkox4R4i8JK3oU0UzBhq+ICnTkFpH2OC5abWeGDTmD
 mZnMhQD+jyWAgrn01qgQJlb6VKHf3brA8+YQJRhSwB2JGQgGTAGB3M78Ywf8Ujkr+R69
 tw2tOdHQl+vbX4jIWmDQDTYgfBh3Lm5uFAb3rQ4B5PiioC7YUZ0kKrD0mu9+n/QG2TFV
 mhDzNPmnE8s/asGZ1QIXFsr+s2h9BkuJdUWwwjNTqDo599T/C16ntYSWOMoF3hpBdwmU
 Jm+Q==
X-Gm-Message-State: AOJu0YwqnMmHdW2GIwQQpM4rbQk7VZwLbB/cyriWMqmDfQNYeaUds/82
 vReYzXUwoJjcw+STiq3DH7P06tV29BYm0MBricM=
X-Google-Smtp-Source: AGHT+IHCn3UD7SSR1tpmYZRRnHcXA2RFl7UrxU88VGIgqUTQbySzmBKmb/yFQaKIbKB6Vj/YCFHmGW1h68uc0nb0l3I=
X-Received: by 2002:a17:90a:72c1:b0:28b:c0a1:f324 with SMTP id
 l1-20020a17090a72c100b0028bc0a1f324mr863424pjk.18.1703220740423; Thu, 21 Dec
 2023 20:52:20 -0800 (PST)
MIME-Version: 1.0
References: <nvbG12_Si7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi_rWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=@pm.me>
 <CAFC_Vt5xqhuXjNVeSGE2Pn=0N0MuB6pOnREzGhSQSpk+hTUUSg@mail.gmail.com>
 <-lH1AcjRwuxfuqLPFOh_oga10Qm12fb7Se9imDeS5ft6CU3y8KTQa3tBP0twJJBFSHgj7FC8EIxvEser3oZdWvkeitRwERQl_cCdgAWtbTU=@pm.me>
 <CAFC_Vt7B1oV0_uAwKe3NQLWE2jdQ_MF1W4fnVqkf8s=YHyfVyQ@mail.gmail.com>
 <1aHuuO-k0Qo7Bt2-Hu5qPFHXi4RgRASpf9hWshaypHtdN-N9jkubcvmf-aUcFEA6-7L9FNXoilIyydCs41eK4v67GVflEd9WIuEF9t5rE8w=@pm.me>
 <CAFC_Vt644Wqn7EcvoZwFscPMov8T5kO9ss_QRgNgVNir-bBA0Q@mail.gmail.com>
 <ue8nChOuMtyW_JM-WxikLpWUSn9I99UHI5ukFVfLOEmQtCo4noetzyVKercbrwjr_EqNotDsR1QZ0oijMu11TO2jpEjlJF71OjLlNoZ-00Y=@pm.me>
 <CAFC_Vt5PcqqcREJ67Jzcg=K+Agd02a9f5uSit8LwkYHshbvF7A@mail.gmail.com>
 <HG9-9VDKRd3-0v0x9QP05_Cjyk9Y3UW-94A1RHsT3xMQYmb7Y6sk9-wTUlqVZzm6ACigM7aM-B6NB-z6jVCCXhQIGEYkEcBKryzP587FlIo=@pm.me>
 <CAFC_Vt6vqZkeenfrsqSj4T3+4+L2KMam0o0FeWJ4VzBEWE=HfA@mail.gmail.com>
 <I11FZ_ZpfwpnQBh5hbBZMHsQt_cKwF9My49X4-MMRIYvaJEoIwta-GEaDNN1EtQxST4gQFAvqfOZElDvIpPrlAVknyN52IMnJKNy5kT8sUE=@pm.me>
In-Reply-To: <I11FZ_ZpfwpnQBh5hbBZMHsQt_cKwF9My49X4-MMRIYvaJEoIwta-GEaDNN1EtQxST4gQFAvqfOZElDvIpPrlAVknyN52IMnJKNy5kT8sUE=@pm.me>
From: "G. Andrew Stone" <g.andrew.stone@gmail.com>
Date: Thu, 21 Dec 2023 23:52:08 -0500
Message-ID: <CAHUwRvuyhQDN5RF0ysMAJgWS2V7vv-3yHzKcLspk_HzQY=tt2Q@mail.gmail.com>
To: yurisvb@pm.me, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003507bf060d11fbbf"
Subject: Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
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: Fri, 22 Dec 2023 04:52:23 -0000

--0000000000003507bf060d11fbbf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Does this affect the security model WRT chain reorganizations?  In the
classic doublespend attack, an attacker can only redirect UTXOs that they
spent.  With this proposal, if I understand it correctly, an attacker could
redirect all funds that have "matured" (revealed the previous preimage in
the hash chain) to themselves.  The # blocks to maturity in your proposal
becomes the classic "embargo period" and every coin spent by anyone between
the fork point and the maturity depth is available to the attacker to
doublespend?

On Thu, Dec 21, 2023, 8:05=E2=80=AFPM Yuri S VB via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> You are right to point out that my proposal was lacking defense against
> rainbow-table, because there is a simple solution for it:
> To take nonces from recent blocks, say, T0-6, ..., T0-13, for salting
> LSIG, and ECCPUB to salt LAMPPUB. Salts don't need to be secret, only
> unknown by the builder of rainbow table while they made it, which is the
> case, since here we have 8*32=3D256 bits for LSIG, and the entropy of ECC=
PUB
> in the second.
>
> With rainbow table out of our way, there is only brute-force analysis to
> mind. Honestly, Guess I should find a less 'outrageously generous' upper
> bound for adversary's model, than just assume they have a magic wand to
> convert SHA256 ASICS into CPU with the same hashrate for memory- and
> serial-work-hard hashes (therefore giving away hash hardness). That's
> because with such 'magic wand' many mining pools would, not only be capab=
le
> of cracking 2^48 hashes far within the protocol's prescribed 48 hours, bu=
t
> also 2^64 within a block time, which would invalidate a lot of what is
> still in use today.
>
> Please, allow me a few days to think that through.
>
> YSVB
>
> Sent with Proton Mail secure email.
>
> On Wednesday, December 20th, 2023 at 10:33 PM, Nagaev Boris <
> bnagaev@gmail.com> wrote:
>
>
> > On Tue, Dec 19, 2023 at 6:22=E2=80=AFPM yurisvb@pm.me wrote:
> >
> > > Thank you for putting yourself through the working of carefully
> analyzing my proposition, Boris!
> > >
> > > 1) My demonstration concludes 12 bytes is still a very conservative
> figure for the hashes. I'm not sure where did you get the 14 bytes figure=
.
> This is 2*(14-12) =3D 4 bytes less.
> >
> >
> > I agree. It should have been 12.
> >
> > > 2) Thank you for pointing out that ECCPUB is necessary. That's exactl=
y
> right and I failed to realize that. To lessen the exposure, and the risk =
of
> miner of LSIG, it can be left to be broadcast together with LAMPPRI.
> > >
> > > 3) I avail to advocate for economizing down the fingerprint to just
> 128 bits for the weakest-link-principle, since 128 bits is a nearly
> ubiquitous standard, employed even by the majority of seeds. Not an
> argument against plain Schnorr, because Schnorr keys could use it too, bu=
t,
> compared with current implementations, we have that would be 20-16=3D4 by=
tes
> less.
> >
> >
> > I think that the digest size for hash should be 2x key size for
> > symmetric encryption. To find a collision (=3D break) for a hash
> > function with digest size 128 bits one needs to calculate ~ 2^64
> > hashes because of the birthday paradox.
> >
> > > 4) [Again, argument against plain, because it cuts for both sides:] T=
o
> economize even further, there is also the entropy-derivation cost trade-o=
ff
> of N times costlier derivation for log2(N) less bits. If applied to the
> Address, we could shave away another byte.
> > >
> > > 5) T0 is just the block height of burying of LSIG doesn't need to be
> buried. T2 can perfectly be hard-coded to always be the block equivalent =
of
> T0 + 48 hours (a reasonable spam to prevent innocent defaulting on
> commitment due to network unavailability). T1 is any value such as T0 < T=
1
> < T2, (typically T1 <=3D T0+6) of user's choosing, to compromise between,=
 on
> one hand, the convenience of unfreezing UTXO and having TX mining complet=
ed
> ASAP and, on the other, avoiding the risk of blockchain forking causing
> LAMPPRI to be accidentally leaked in the same block height as LSIG, which
> allows for signatures to be forged. So this is 16 bytes less.
> > >
> > > Miners would keep record of unconfirmed BL's, because of the reward o=
f
> mining either possible outcome of it (successful transaction or execution
> of commitment). Everything is paid for.
> > >
> > > So, unless I'm forgetting something else, all other variables kept
> equal, we have 20 bytes lighter than Schnorr; and up to 25 bytes less the
> current implementation of Schnorr, if items 3 and 4 are implemented too.
> Already we have a reduction of between 21% and 26%, while, so far, nobody
> in the mailing list has disputed how 'outrageously' conservative the 12
> bytes figure is.
> >
> >
> > 26% reduction of block space utilization would be great, but the price
> > of relying on 12 bytes hashes (only need 2^48 hashes to find a
> > collision) is too much for that, IMHO.
> >
> > Another consideration is about 12 byte hashes. Let's try to figure out
> > if they are resistant to rainbow table attack by a large organization.
> > Let's assume that the rainbow table has a chain length of 1024^3
> (billion).
> > What storage size is needed? 2^96 * 12 / 1024^3 =3D 900 exabytes.
> > Both chain length and storage size seems prohibitively high for today,
> > but tomorrow the hash function can be optimized, memory can be
> > optimized, storage can become cheaper etc. And this attack may be
> > affordable for state level attackers.
> >
> > > Any other objections?
> > >
> > > YSVB
> >
> >
> >
> > --
> > Best regards,
> > Boris Nagaev_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">Does this affect the security model WRT chain reorganizat=
ions?=C2=A0 In the classic doublespend attack, an attacker can only redirec=
t UTXOs that they spent.=C2=A0 With this proposal, if I understand it corre=
ctly, an attacker could redirect all funds that have &quot;matured&quot; (r=
evealed the previous preimage in the hash chain) to themselves.=C2=A0 The #=
 blocks to maturity in your proposal becomes the classic &quot;embargo peri=
od&quot; and every coin spent by anyone between the fork point and the matu=
rity depth is available to the attacker to doublespend?</div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 21, 2023=
, 8:05=E2=80=AFPM Yuri S VB via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">You are right to point out =
that my proposal was lacking defense against rainbow-table, because there i=
s a simple solution for it:<br>
To take nonces from recent blocks, say, T0-6, ..., T0-13, for salting LSIG,=
 and ECCPUB to salt LAMPPUB. Salts don&#39;t need to be secret, only unknow=
n by the builder of rainbow table while they made it, which is the case, si=
nce here we have 8*32=3D256 bits for LSIG, and the entropy of ECCPUB in the=
 second.<br>
<br>
With rainbow table out of our way, there is only brute-force analysis to mi=
nd. Honestly, Guess I should find a less &#39;outrageously generous&#39; up=
per bound for adversary&#39;s model, than just assume they have a magic wan=
d to convert SHA256 ASICS into CPU with the same hashrate for memory- and s=
erial-work-hard hashes (therefore giving away hash hardness). That&#39;s be=
cause with such &#39;magic wand&#39; many mining pools would, not only be c=
apable of cracking 2^48 hashes far within the protocol&#39;s prescribed 48 =
hours, but also 2^64 within a block time, which would invalidate a lot of w=
hat is still in use today.<br>
<br>
Please, allow me a few days to think that through.<br>
<br>
YSVB<br>
<br>
Sent with Proton Mail secure email.<br>
<br>
On Wednesday, December 20th, 2023 at 10:33 PM, Nagaev Boris &lt;<a href=3D"=
mailto:bnagaev@gmail.com" target=3D"_blank" rel=3D"noreferrer">bnagaev@gmai=
l.com</a>&gt; wrote:<br>
<br>
<br>
&gt; On Tue, Dec 19, 2023 at 6:22=E2=80=AFPM <a href=3D"mailto:yurisvb@pm.m=
e" target=3D"_blank" rel=3D"noreferrer">yurisvb@pm.me</a> wrote:<br>
&gt;<br>
&gt; &gt; Thank you for putting yourself through the working of carefully a=
nalyzing my proposition, Boris!<br>
&gt; &gt;<br>
&gt; &gt; 1) My demonstration concludes 12 bytes is still a very conservati=
ve figure for the hashes. I&#39;m not sure where did you get the 14 bytes f=
igure. This is 2*(14-12) =3D 4 bytes less.<br>
&gt;<br>
&gt;<br>
&gt; I agree. It should have been 12.<br>
&gt;<br>
&gt; &gt; 2) Thank you for pointing out that ECCPUB is necessary. That&#39;=
s exactly right and I failed to realize that. To lessen the exposure, and t=
he risk of miner of LSIG, it can be left to be broadcast together with LAMP=
PRI.<br>
&gt; &gt;<br>
&gt; &gt; 3) I avail to advocate for economizing down the fingerprint to ju=
st 128 bits for the weakest-link-principle, since 128 bits is a nearly ubiq=
uitous standard, employed even by the majority of seeds. Not an argument ag=
ainst plain Schnorr, because Schnorr keys could use it too, but, compared w=
ith current implementations, we have that would be 20-16=3D4 bytes less.<br=
>
&gt;<br>
&gt;<br>
&gt; I think that the digest size for hash should be 2x key size for<br>
&gt; symmetric encryption. To find a collision (=3D break) for a hash<br>
&gt; function with digest size 128 bits one needs to calculate ~ 2^64<br>
&gt; hashes because of the birthday paradox.<br>
&gt;<br>
&gt; &gt; 4) [Again, argument against plain, because it cuts for both sides=
:] To economize even further, there is also the entropy-derivation cost tra=
de-off of N times costlier derivation for log2(N) less bits. If applied to =
the Address, we could shave away another byte.<br>
&gt; &gt;<br>
&gt; &gt; 5) T0 is just the block height of burying of LSIG doesn&#39;t nee=
d to be buried. T2 can perfectly be hard-coded to always be the block equiv=
alent of T0 + 48 hours (a reasonable spam to prevent innocent defaulting on=
 commitment due to network unavailability). T1 is any value such as T0 &lt;=
 T1 &lt; T2, (typically T1 &lt;=3D T0+6) of user&#39;s choosing, to comprom=
ise between, on one hand, the convenience of unfreezing UTXO and having TX =
mining completed ASAP and, on the other, avoiding the risk of blockchain fo=
rking causing LAMPPRI to be accidentally leaked in the same block height as=
 LSIG, which allows for signatures to be forged. So this is 16 bytes less.<=
br>
&gt; &gt;<br>
&gt; &gt; Miners would keep record of unconfirmed BL&#39;s, because of the =
reward of mining either possible outcome of it (successful transaction or e=
xecution of commitment). Everything is paid for.<br>
&gt; &gt;<br>
&gt; &gt; So, unless I&#39;m forgetting something else, all other variables=
 kept equal, we have 20 bytes lighter than Schnorr; and up to 25 bytes less=
 the current implementation of Schnorr, if items 3 and 4 are implemented to=
o. Already we have a reduction of between 21% and 26%, while, so far, nobod=
y in the mailing list has disputed how &#39;outrageously&#39; conservative =
the 12 bytes figure is.<br>
&gt;<br>
&gt;<br>
&gt; 26% reduction of block space utilization would be great, but the price=
<br>
&gt; of relying on 12 bytes hashes (only need 2^48 hashes to find a<br>
&gt; collision) is too much for that, IMHO.<br>
&gt;<br>
&gt; Another consideration is about 12 byte hashes. Let&#39;s try to figure=
 out<br>
&gt; if they are resistant to rainbow table attack by a large organization.=
<br>
&gt; Let&#39;s assume that the rainbow table has a chain length of 1024^3 (=
billion).<br>
&gt; What storage size is needed? 2^96 * 12 / 1024^3 =3D 900 exabytes.<br>
&gt; Both chain length and storage size seems prohibitively high for today,=
<br>
&gt; but tomorrow the hash function can be optimized, memory can be<br>
&gt; optimized, storage can become cheaper etc. And this attack may be<br>
&gt; affordable for state level attackers.<br>
&gt;<br>
&gt; &gt; Any other objections?<br>
&gt; &gt;<br>
&gt; &gt; YSVB<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Best regards,<br>
&gt; Boris Nagaev_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000003507bf060d11fbbf--