From mboxrd@z Thu Jan 1 00:00:00 1970
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> <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>><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> <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>><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 <=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" 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--