summaryrefslogtreecommitdiff
path: root/cc/958954c6d23cac8813a4c64673ae90e42c16d1
blob: 5205120fc8fe6557497cb0050a1caf8d2cab1c29 (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
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
Delivery-date: Thu, 27 Feb 2025 18:41:15 -0800
Received: from mail-qt1-f187.google.com ([209.85.160.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBQGEQS7AMGQE4J5IIKQ@googlegroups.com>)
	id 1tnqJN-0004qg-LV
	for bitcoindev@gnusha.org; Thu, 27 Feb 2025 18:41:15 -0800
Received: by mail-qt1-f187.google.com with SMTP id d75a77b69052e-472107c4b5esf31496411cf.1
        for <bitcoindev@gnusha.org>; Thu, 27 Feb 2025 18:41:13 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1740710468; cv=pass;
        d=google.com; s=arc-20240605;
        b=fcY68ipxIYI2blhBhPsZ+82r22W7VuuVssZq/0cpvWVMRk5mEjI80DSU/3G3jn29Hw
         W5clUK2pJGBGU/rVwrMwB/qkv3DXfl2CE4w9SjtqOG6uNwwAGFDKqEJCtzu8kE6BdhS+
         WZnc7ItIqbC8+9giJWKxhw88eVdK4u7PfO4dMZJy0erYpDOqCdqt8hN3PitdwUdH+jRL
         IHrLvjcqsmpqkdKtl8PWg2PGtH0JsvYf9MYgogwuASvygIZfrDZT4lvWzquvk7SS+jTG
         dkRUXKw67WLTgWrDB2ZLp6auNXSnYNOKEoRR4xrESTGxYx+KiKxq1BdDbCZPaxsEL7XH
         2ARQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=Cf2ez/1Q9wx0up2EFIec7+jPK4bfhA2KbUFHFBz/Bx8=;
        fh=nfbBokmQJyeaxYN1cme6klSfBH5qKeCXYQduRG1iiV8=;
        b=IDTY/vFE8wyBWJl4j+Wi+6Rq4lzLJQwZ73BHwV7H8F6jl3VOvyFbIad2b2NEc3M+0T
         ChxtRac955or6r9ZGPfEA3Zy/YykkoIzzGhA30F7xCUrD7+wIJ4eBBkA3MAdqlX+h404
         Vw3yQ9V8px8VjXnPguMFxMSUI9H71n/FAQBNqQ+ZTeGBM0eEdkGTmCu2nFiRncKzzCsC
         sN0rxoFwcUPd8wGY4A0bWKNojaFYiMZe7RJc0yjOEWPB9ZHGG4E+UGfS+J6KKpQlIXYi
         r4IJS0zcCkacNlGMpMwKRPgdZ+fzIMZ/r7X4+3xiaUyEmQIuRELk1lKAQxPYuFD3502z
         2oFg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=leSKFpNk;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1740710468; x=1741315268; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=Cf2ez/1Q9wx0up2EFIec7+jPK4bfhA2KbUFHFBz/Bx8=;
        b=upGWUIhIgdg5MQGZklieA4vwwRNhREJ1h88trsw89NH+jTig5XNr1jEZDYVLZgYgkJ
         p1E/huXUmdTQEKIjdSZmm2+t87kzZpMu1BEs4LybJa9fiNwT23N38K7ckxXvFNGBR41Q
         i0WwyuhMM9TbCZdKiNghxal3yfIy1tSx+JgJYhbzPjgbZ5coTM0ASiiiLTpdEw/MMucK
         5dR0bK8CiKVUNQIvaOAfYQI17bbRivSy+qL9AuMnFiozxMktzxr9UJwMsfvGwOWoBoXs
         UOAjJnWNNPMOUzniwjjd/nrDxog/xvfthniukx0dBMHIBUzOQpJJWITdiqMCSoLAoOXS
         e3aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1740710468; x=1741315268;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Cf2ez/1Q9wx0up2EFIec7+jPK4bfhA2KbUFHFBz/Bx8=;
        b=k0dfWtB/QKBiSSJTOoPMSeaLJOsY5/MLNGboH4zkFmtTv/a+zxiAED7si1nHXrBmv3
         U3SbWrEkPslzBZFXeOV2qCZwa/g2z13bjIebtlyv/fjIPvZNIyaBej5Vw4diFeUd7DZM
         0mN5AhJPgg+K+eadut9hD4FBy+vKjxtHvYHoK6UaPhP6ZVJiZaA6lUA1XtzMLyIiLRZ6
         uUUVpeVmdXHZWk9CakdLKJ93aje1ge/MWJHG3fO/E2oBj3YRAyY19cg64JuqtWcHIpJM
         qOnYVL7HdKiNyZa7JaXP41W+fT71wIixqD5q3OulVP9Zda4cjxAWTIKf1D/Q+ZjLzkU9
         2vZg==
X-Forwarded-Encrypted: i=2; AJvYcCW6xPfNXNljVPIHEOPQ7R34sAiDqLSZJR+3LPXaL+zqQHixWHoNjsyJGXv88abNTZkMhpCrE2NAimgw@gnusha.org
X-Gm-Message-State: AOJu0Yye8YW7GTsVl9tIt+nYkocGr3VVrmD38YE8r7qgNi59FQbnZ2DZ
	t734SdbKtPdy1KJ9Z5kpUEWR4AMODlCO2h83B+BHQNJaovTisSnC
X-Google-Smtp-Source: AGHT+IEQ4VqIJBpt6tSsuuGwVK00s/WEsT5o5rExzNiJXJYFE7dzpMEKMvxffItyC2UQm1wv7zQt4A==
X-Received: by 2002:a05:622a:20b:b0:471:f9bc:fe53 with SMTP id d75a77b69052e-473e55b6a2cmr97988631cf.26.1740710467582;
        Thu, 27 Feb 2025 18:41:07 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGkCSpve9Cjqatr3LJ1VFp8FLYVVdO96s0HQ7T4SypNvQ==
Received: by 2002:a05:622a:153:b0:471:b736:6cc1 with SMTP id
 d75a77b69052e-473ced96a3als31359351cf.1.-pod-prod-00-us; Thu, 27 Feb 2025
 18:41:04 -0800 (PST)
X-Received: by 2002:a05:620a:44c2:b0:7c0:770a:d19 with SMTP id af79cd13be357-7c39bbf597emr340014385a.8.1740710464220;
        Thu, 27 Feb 2025 18:41:04 -0800 (PST)
Received: by 2002:a05:600c:1391:b0:439:96ac:b8c8 with SMTP id 5b1f17b1804b1-43abe2e3f6fms5e9;
        Thu, 27 Feb 2025 09:23:17 -0800 (PST)
X-Received: by 2002:a05:600c:1c93:b0:439:a1ef:c238 with SMTP id 5b1f17b1804b1-43ba6704511mr268155e9.13.1740676995531;
        Thu, 27 Feb 2025 09:23:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1740676995; cv=none;
        d=google.com; s=arc-20240605;
        b=NC2YepJdNyMJuHTeMivF2bNm27bHW5nZ7x0nAUeamA+GJZfyJVn9WZJOvuYQFkxMA4
         13gWpSjrzyjjJEkbOyCyGgvIa3ft4nf7s8MGO9WuPhTtdxpVx8CWRjPpLrGOmsfQR3cy
         HhoKUwXAfm+8ioT8voENU0jRI102F8AfG3CVzT+BOpHWgkSypV6fuuEzXGpCvrk1GCZB
         70+DjoxFk348DP8G7gnB37T9wNg8Tn73ufpcw21A5jMSEf7g3xeqdhEhuzbRonGJPmkw
         Ayrw6ytVFTfFYc9BOQG3mITFkhXvtvx6kw7GndG6t2MpRHoA/XmsxtOCE4hWQKUJn5sC
         ONoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=hqjnCOI3DQ3WsLEg7UTixKrNC8tTqRGYOCOq1IfSAWQ=;
        fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=;
        b=JpfHKatsWpIuZm7lG1+xeDNOAgAtrFFNCIqhrw/PMZMSbXCnlelY3DfQJceDwbf2xP
         ansGuI8wrOXySP4EXtgwImdAJHWQcZDRWF/ONsrGaX1jRiIbGdEw7tKO1CN59RVwze7C
         TiiReNecm84HJ2iq65oCVa5fCBwuyFin4FWx2wQelTAzxhKLmHHkDtBxZ1mMkQid/3za
         35woi1AVVQ9olQ48Hmb0OrVOEIIsdPT/1+OawCWwt4nQ0sx2w0wNaV+gaVWYL48vVupM
         w1FNQJkgzuz+1fFVx6/aNcrqcRDPZqRMTyF2jrhpCqqJtM9jmRpWnQSW0Y04dF/VVOiY
         GjXw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=leSKFpNk;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-43ab374a2adsi4630315e9.1.2025.02.27.09.23.15
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 27 Feb 2025 09:23:15 -0800 (PST)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16;
Date: Thu, 27 Feb 2025 17:23:10 +0000
To: Matt Corallo <lf-lists@mattcorallo.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
Message-ID: <ew40Tlhu4YmctmFLj3YtwQ_6qxYCUr_uZFfZtfFl-n-noA9mCZh0jZviy_gJDbY8AsS3jOnjFRCKnouaEzv-DJ_KqMW0BfFeYe679s_JZaM=@protonmail.com>
In-Reply-To: <58247311-171f-4228-8db9-53363f764880@mattcorallo.com>
References: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com> <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com> <VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYbWns5nP4TANCWvPJYu1ew_yxQSaudizzk=@protonmail.com> <58247311-171f-4228-8db9-53363f764880@mattcorallo.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: fb290c5c557e759d966443e74dff4a4da0a8a769
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_j0kvk0HCUh1GXndNxVuumohPA7L9qH6MoQPwuhT6bI"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=leSKFpNk;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.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: -1.0 (-)

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

> Okay! That's a much better outcome than I was thinking. I assume this was=
 with parallelization
> across the 4+8 available cores?

Yes, this is using all 16-1 threads.

> Do you happen to have numbers handy for the worst-case with, forexample, =
one block of prep?

The validation cost with the mitigation is proportional to the number of pr=
eparation blocks [0]. So the validation time for one block prep the runtime=
 should be about 112ms.

As an another point of comparison the worst case using Taproot presents abo=
ut the same validation cost as the worst case with legacy with my proposed =
mitigation and about 6 or 7 preparation blocks. Except for Taproot it does =
not need any preparation block and the operations cannot be parallelized.

Antoine

[0] See the graph in this message in the private thread: [https://delvingbi=
tcoin.org/t/worst-block-validation-time-inquiry/711/70](https://delvingbitc=
oin.org/t/worst-block-validation-time-inquiry/711/70?u=3Dantoinep).

On Wednesday, February 26th, 2025 at 2:11 PM, Matt Corallo lf-lists@mattcor=
allo.com wrote:

> On 2/23/25 5:35 PM, Antoine Poinsot wrote:
>
>> A 40x decrease to a validation time of 30 seconds probably is worth a bi=
t of risk for a further
>> improvement.
>>
>> Depends on what hardware. I don't think a worst case of 30 seconds for e=
nd users is worth more
>> risks. A worst case of 30 seconds for miners would probably be concernin=
g.
>
> Sure, I'm not super concerned with an RPi. I am concerned with relatively=
 cheap miner hardware, tho.
>
>> In addition, although the worst case is important to limit the damage an=
 attacker can do without
>> being economically rational, what we care about for miners attacking eac=
h other is economically
>> viable attacks. At the moment the optimal "validation time / cost to att=
acker" ratio is not the
>> worst case, by a large margin [0].
>>
>> I believe we should take into account the worst case to miners even if n=
ot economically viable for
>> an attacker as a safety margin. But we should keep in mind this is alrea=
dy overestimating the attack
>> risk since in this scenario what we should look at is the worst case val=
idation time of blocks that
>> may have positive returns to an attacker.
>
> Fair enough.
>
>> Can you put numbers to this?
>>
>> Sure. Using my functional test which runs the worst case today and the w=
orst case under various
>> mitigations [1] on a Dell XPS 15 9520 laptop (the model with an i5-12500=
H) i get 120 seconds for the
>> worst case today and 10 seconds for the worst block with a limited of 25=
00 (potentially) executed
>> sigops per transaction. To (maybe, they could be running more powerful m=
achines than my laptop)
>> impose such a validation time to other miners an attacker would have to =
invest 89 (!!) preparation
>> blocks. Sure, with low fees the opportunity cost of mining preparation t=
ransactions is not as high
>> as it could be. But still.
>
> Okay! That's a much better outcome than I was thinking. I assume this was=
 with parallelization
> across the 4+8 available cores? Do you happen to have numbers handy for t=
he worst-case with, for
> example, one block of prep?
>
> Matt
>
>> [0] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711=
/70 <https://
>> delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70?u=3Danto=
inep>
>> [1] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711=
/61 <https://
>> delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/61?u=3Danto=
inep>
>> On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo lf-lists@mattc=
orallo.com wrote:
>>
>>> In the delving post you said =E2=80=9CThis provides a 40x decrease in t=
he worst case validation time with
>>> a straightforward and flexible rule minimizing the confiscatory surface=
. A further 7x decrease is
>>> possible by combining it with another rule, which is in my opinion not =
worth the additional
>>> confiscatory surface.=E2=80=9D
>>>
>>> Can you put numbers to this? How long does it take to validate a full b=
lock with this 40x decrease
>>> and how long would it take with the further 7x decrease?
>>>
>>> A 40x decrease to a validation time of 30 seconds probably is worth a b=
it of risk for a further
>>> improvement. A 40x decrease to 1 second is obviously fine :).
>>>
>>>> On Feb 5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin Development Ma=
iling List
>>>> bitcoindev@googlegroups.com wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> A bit over a year ago i started working on revisiting the 2019 Great C=
onsensus Cleanup proposal from
>>>> Matt Corallo [0]. His proposal included:
>>>> - making <=3D64 bytes transactions invalid to fix merkle tree weakness=
es;
>>>> - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARA=
TOR and non-standard sighash
>>>> types fail script validation to mitigate the worst case block validati=
on time;
>>>> - restrict the nTime field of the first block in each difficulty adjus=
tment interval to be no less
>>>> than 600 seconds lower than the previous block's;
>>>>
>>>> I set out to research the impact of each of the vulnerabilities this i=
ntended to patch, the
>>>> alternative fixes possible for each and finally if there was any other=
 protocol bug fix we'd want to
>>>> include if we went through the considerable effort of soft forking Bit=
coin already.
>>>>
>>>> Later in March i shared some first findings on Delving [1] and adverti=
zed the effort on this mailing
>>>> list [2]. I also created a companion thread on Delving, kept private, =
to discuss the details of the
>>>> worst case block validation time [3]. As one would expect due to the l=
arger design space available
>>>> to fix this issue, this private thread is where most of the discussion=
 would happen. Thank you to
>>>> everyone who contributed feedback, insights, ideas and argumented opin=
ions on the different issues
>>>> all along the process.
>>>>
>>>> Now i would like to update the broader Bitcoin development community o=
n the outcome of this effort.
>>>> I believe a Consensus Cleanup proposal should include the following.
>>>> - A fix for vulnerabilities surrounding the use of timestamps in the d=
ifficulty adjustment
>>>> algorithm. In particular, a fix for the timewarp attack with a 7200 se=
conds grace period as well
>>>> as a fix for the Murch-Zawy attack [4] by making invalid any difficult=
y adjustment period with a
>>>> negative duration.
>>>> - A fix for long block validation times with a minimal "confiscation s=
urface", by introducing a
>>>> per-transaction limit on the number of legacy sigops in the inputs.
>>>> - A fix for merkle tree weaknesses by making transactions which serial=
ize to exactly 64 bytes
>>>> invalid.
>>>> - A fix for duplicate transactions to supplement BIP34 in order to avo=
id resuming unnecessary BIP30
>>>> validation in the future. This is achieved by mandating the nLockTime =
field of coinbase
>>>> transaction to be set to the height of their block minus 1.
>>>>
>>>> I have started drafting a BIP draft with the detailed specs for this.
>>>>
>>>> Antoine Poinsot
>>>>
>>>> [0] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d219=
7d3eabe661050c2/bip-
>>>> XXXX.mediawiki
>>>> [1] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
>>>> [2] https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAA=
J
>>>> [3] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/7=
11
>>>> [4] https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1=
062#variant-on-zawys-attack-2
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Gro=
ups "Bitcoin Development
>>>> Mailing List" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
 an email to
>>>> bitcoindev+unsubscribe@googlegroups.com.
>>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoi=
ndev/
>>>> jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOC=
G0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40protonmail.com.

--=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 visit https://groups.google.com/d/msgid/bitcoindev/=
ew40Tlhu4YmctmFLj3YtwQ_6qxYCUr_uZFfZtfFl-n-noA9mCZh0jZviy_gJDbY8AsS3jOnjFRC=
KnouaEzv-DJ_KqMW0BfFeYe679s_JZaM%3D%40protonmail.com.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><blockquote=
 style=3D"border-left: 3px solid rgb(200, 200, 200); border-color: rgb(200,=
 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"><span>Okay! Tha=
t's a much better outcome than I was thinking. I assume this was with paral=
lelization</span><div><span>across the 4+8 available cores?</span></div></b=
lockquote><div><br></div><div>Yes, this is using all 16-1 threads.<br></div=
><div><span><br></span></div><blockquote style=3D"border-left: 3px solid rg=
b(200, 200, 200); border-color: rgb(200, 200, 200); padding-left: 10px; col=
or: rgb(102, 102, 102);"><div><span>Do you happen to have numbers handy for=
 the worst-case with, for</span></div><span>example, one block of prep?</sp=
an></blockquote><div style=3D"font-family: Arial, sans-serif; font-size: 14=
px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14p=
x;">The validation cost with the mitigation is proportional to the number o=
f preparation blocks [0]. So the validation time for one block prep the run=
time should be about 112ms.</div><div style=3D"font-family: Arial, sans-ser=
if; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-seri=
f; font-size: 14px;">As an another point of comparison the worst case using=
 Taproot presents about the same validation cost as the worst case with leg=
acy with my proposed mitigation and about 6 or 7 preparation blocks. Except=
 for Taproot it does not need any preparation block and the operations cann=
ot be parallelized.</div><div style=3D"font-family: Arial, sans-serif; font=
-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-=
size: 14px;">Antoine<br></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<br>
[0] See the graph in this message in the private thread: <span><a target=3D=
"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://delvingbitcoi=
n.org/t/worst-block-validation-time-inquiry/711/70?u=3Dantoinep">https://de=
lvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70</a></span>.<b=
r>
<br>
<br>
<br>
On Wednesday, February 26th, 2025 at 2:11 PM, Matt Corallo <a href=3D"mailt=
o:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a> wrote:<p></p>
<p></p>
<blockquote>
<p>On 2/23/25 5:35 PM, Antoine Poinsot wrote:</p>
<blockquote>
<p>A 40x decrease to a validation time of 30 seconds probably is worth a bi=
t of risk for a further<br>
improvement.</p>
<p>Depends on what hardware. I don't think a worst case of 30 seconds for e=
nd users is worth more<br>
risks. A worst case of 30 seconds for miners would probably be concerning.<=
/p>
</blockquote>
<p>Sure, I'm not super concerned with an RPi. I am concerned with relativel=
y cheap miner hardware, tho.</p>
<blockquote>
<p>In addition, although the worst case is important to limit the damage an=
 attacker can do without<br>
being economically rational, what we care about for miners attacking each o=
ther is economically<br>
viable attacks. At the moment the optimal "validation time / cost to attack=
er" ratio is not the<br>
worst case, by a large margin [0].</p>
<p>I believe we should take into account the worst case to miners even if n=
ot economically viable for<br>
an attacker as a safety margin. But we should keep in mind this is already =
overestimating the attack<br>
risk since in this scenario what we should look at is the worst case valida=
tion time of blocks that<br>
may have positive returns to an attacker.</p>
</blockquote>
<p>Fair enough.</p>
<blockquote>
<p>Can you put numbers to this?</p>
<p>Sure. Using my functional test which runs the worst case today and the w=
orst case under various<br>
mitigations [1] on a Dell XPS 15 9520 laptop (the model with an i5-12500H) =
i get 120 seconds for the<br>
worst case today and 10 seconds for the worst block with a limited of 2500 =
(potentially) executed<br>
sigops per transaction. To (maybe, they could be running more powerful mach=
ines than my laptop)<br>
impose such a validation time to other miners an attacker would have to inv=
est 89 (!!) preparation<br>
blocks. Sure, with low fees the opportunity cost of mining preparation tran=
sactions is not as high<br>
as it could be. But still.</p>
</blockquote>
<p>Okay! That's a much better outcome than I was thinking. I assume this wa=
s with parallelization<br>
across the 4+8 available cores? Do you happen to have numbers handy for the=
 worst-case with, for<br>
example, one block of prep?</p>
<p>Matt</p>
<blockquote>
<p>[0] <a href=3D"https://delvingbitcoin.org/t/worst-block-validation-time-=
inquiry/711/70">https://delvingbitcoin.org/t/worst-block-validation-time-in=
quiry/711/70</a> &lt;https://<br>
<a href=3D"http://delvingbitcoin.org/t/worst-block-validation-time-inquiry/=
711/70?u=3Dantoinep">delvingbitcoin.org/t/worst-block-validation-time-inqui=
ry/711/70?u=3Dantoinep</a>&gt;<br>
[1] <a href=3D"https://delvingbitcoin.org/t/worst-block-validation-time-inq=
uiry/711/61">https://delvingbitcoin.org/t/worst-block-validation-time-inqui=
ry/711/61</a> &lt;https://<br>
<a href=3D"http://delvingbitcoin.org/t/worst-block-validation-time-inquiry/=
711/61?u=3Dantoinep">delvingbitcoin.org/t/worst-block-validation-time-inqui=
ry/711/61?u=3Dantoinep</a>&gt;<br>
On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo <a href=3D"mailto=
:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a> wrote:</p>
<blockquote>
<p>In the delving post you said =E2=80=9CThis provides a 40x decrease in th=
e worst case validation time with<br>
a straightforward and flexible rule minimizing the confiscatory surface. A =
further 7x decrease is<br>
possible by combining it with another rule, which is in my opinion not wort=
h the additional<br>
confiscatory surface.=E2=80=9D</p>
<p>Can you put numbers to this? How long does it take to validate a full bl=
ock with this 40x decrease<br>
and how long would it take with the further 7x decrease?</p>
<p>A 40x decrease to a validation time of 30 seconds probably is worth a bi=
t of risk for a further<br>
improvement. A 40x decrease to 1 second is obviously fine :).</p>
<blockquote>
<p>On Feb 5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin Development Mail=
ing List<br>
<a href=3D"mailto:bitcoindev@googlegroups.com">bitcoindev@googlegroups.com<=
/a> wrote:</p>
<p>Hi everyone,</p>
<p>A bit over a year ago i started working on revisiting the 2019 Great Con=
sensus Cleanup proposal from<br>
Matt Corallo [0]. His proposal included:<br>
- making &lt;=3D64 bytes transactions invalid to fix merkle tree weaknesses=
;<br>
- making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARATOR a=
nd non-standard sighash<br>
types fail script validation to mitigate the worst case block validation ti=
me;<br>
- restrict the nTime field of the first block in each difficulty adjustment=
 interval to be no less<br>
than 600 seconds lower than the previous block's;</p>
<p>I set out to research the impact of each of the vulnerabilities this int=
ended to patch, the<br>
alternative fixes possible for each and finally if there was any other prot=
ocol bug fix we'd want to<br>
include if we went through the considerable effort of soft forking Bitcoin =
already.</p>
<p>Later in March i shared some first findings on Delving [1] and advertize=
d the effort on this mailing<br>
list [2]. I also created a companion thread on Delving, kept private, to di=
scuss the details of the<br>
worst case block validation time [3]. As one would expect due to the larger=
 design space available<br>
to fix this issue, this private thread is where most of the discussion woul=
d happen. Thank you to<br>
everyone who contributed feedback, insights, ideas and argumented opinions =
on the different issues<br>
all along the process.</p>
<p>Now i would like to update the broader Bitcoin development community on =
the outcome of this effort.<br>
I believe a Consensus Cleanup proposal should include the following.<br>
- A fix for vulnerabilities surrounding the use of timestamps in the diffic=
ulty adjustment<br>
algorithm. In particular, a fix for the timewarp attack with a 7200 seconds=
 grace period as well<br>
as a fix for the Murch-Zawy attack [4] by making invalid any difficulty adj=
ustment period with a<br>
negative duration.<br>
- A fix for long block validation times with a minimal "confiscation surfac=
e", by introducing a<br>
per-transaction limit on the number of legacy sigops in the inputs.<br>
- A fix for merkle tree weaknesses by making transactions which serialize t=
o exactly 64 bytes<br>
invalid.<br>
- A fix for duplicate transactions to supplement BIP34 in order to avoid re=
suming unnecessary BIP30<br>
validation in the future. This is achieved by mandating the nLockTime field=
 of coinbase<br>
transaction to be set to the height of their block minus 1.</p>
<p>I have started drafting a BIP draft with the detailed specs for this.</p=
>
<p>Antoine Poinsot</p>
<p>[0] <a href=3D"https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943=
a0cc6d2197d3eabe661050c2/bip-">https://github.com/TheBlueMatt/bips/blob/7f9=
670b643b7c943a0cc6d2197d3eabe661050c2/bip-</a><br>
XXXX.mediawiki<br>
[1] <a href=3D"https://delvingbitcoin.org/t/great-consensus-cleanup-revival=
/710">https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710</a><=
br>
[2] <a href=3D"https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3B=
iOuAAAJ">https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAA=
J</a><br>
[3] <a href=3D"https://delvingbitcoin.org/t/worst-block-validation-time-inq=
uiry/711">https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/=
711</a><br>
[4] <a href=3D"https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-at=
tack/1062#variant-on-zawys-attack-2">https://delvingbitcoin.org/t/zawy-s-al=
ternating-timestamp-attack/1062#variant-on-zawys-attack-2</a></p>
<p>--<br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development<br>
Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to<br>
<a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsub=
scribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/">https://groups.google.com/d/msgid/bitcoindev/</a><br>
jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_W=
Iz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%<a href=3D"http://40protonmail.com">40p=
rotonmail.com</a>.</p>
</blockquote>
</blockquote>
</blockquote>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; 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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/ew40Tlhu4YmctmFLj3YtwQ_6qxYCUr_uZFfZtfFl-n-noA9mCZh0jZviy_gJDbY8=
AsS3jOnjFRCKnouaEzv-DJ_KqMW0BfFeYe679s_JZaM%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
ew40Tlhu4YmctmFLj3YtwQ_6qxYCUr_uZFfZtfFl-n-noA9mCZh0jZviy_gJDbY8AsS3jOnjFRC=
KnouaEzv-DJ_KqMW0BfFeYe679s_JZaM%3D%40protonmail.com</a>.<br />

--b1=_j0kvk0HCUh1GXndNxVuumohPA7L9qH6MoQPwuhT6bI--