From mboxrd@z Thu Jan 1 00:00:00 1970
Delivery-date: Sun, 23 Feb 2025 15:53:18 -0800
Received: from mail-ot1-f63.google.com ([209.85.210.63])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDL4XL646QOBBY7J526QMGQECMS2LEQ@googlegroups.com>)
id 1tmLmf-0008JA-7W
for bitcoindev@gnusha.org; Sun, 23 Feb 2025 15:53:18 -0800
Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-72723b7151csf1140357a34.2
for <bitcoindev@gnusha.org>; Sun, 23 Feb 2025 15:53:16 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1740354790; cv=pass;
d=google.com; s=arc-20240605;
b=MbS/vJLkRgDkgEtNNqheB1BbFZpbWa1WWJlf7HGIVDtfEyW3fpi7xQxd8Tp1Me8dR6
AJsmOLUzLpOygtolVfkwkVG8s/XSVxEtUftb+Yzl8vOwTUFoEU+dm7EIcjrxa3reVibq
TWrE7NA+2a2Hbp92enWHGEaz6SSJeSMLqKF4LyenQ+SzjVjeke4Vz+yaiVnZ3IFVol5n
gJtmYK98tZ6hHOtqSC3Po/nba/7Ktn0zdO8MLbDDHYVT8UyXGVrXcklmrA9+JmmcLUl8
NSTRq4iHlHfJfRYdTBkgyKglxKm4b9z4Ez5wdOoOO2663WjemLz86mxZ0e4t5+ZxzqJ/
Sq2w==
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=uvPSEJc2mQLHQ3aicQOmQgvpF0IEH+AZN3fEj+wCF+s=;
fh=W47VPq2a172a+gHBZaTZm8NppdTY3jBXcgO739ED4uk=;
b=dZVqtXUWySTeG2x7jUTlATM9gJ5wSHfTNEBYD0Yc0RdLysKv/4cHZWnJhy5tWUxa+m
sxn2dae3alZEVAOuZuJ7TXNJasPaALncNRnOrZ3unDxM/+Kz+rttyZWkDwJKo8p7ojK1
PbP25ZZYm/31X0mvDfwi8Hicsx/qso6XCb9Ydqy4yrdLNkEk18DJxSzZKExar19QJfuF
4XC//ao9uEOgrFZdwCrIT8wU6BHYeNPbokJrak945lbE+cnkC0itaTkgZGIH6Qi44OEw
wAtLg+xpRt2WveSBf5VN0RbeauNLKmEhtYHEXhva87Xws6/U0n9rJFb/oczZYg21sml2
KL1w==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UI4Sz9HB;
spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.131 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=1740354790; x=1740959590; 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=uvPSEJc2mQLHQ3aicQOmQgvpF0IEH+AZN3fEj+wCF+s=;
b=crETjZDer5tv+wCenOQYDs7Pyzqexcw9sEQTbU/0XcNh9netz4fw77Ef/vSi/zrwX9
03eLIznnfYZ4XKvOBQS4Js+tRSJOGSjf9wJimjI1fMexZWn5BG7dMTs0NxWhdQm7wdyl
02pkcOxZ9U0GbftI0TTzojTSKw/sSEh4LbXh5qJuX6wWrE5fzkiKwr87SDeigtc1CCau
AfnoOKPEQ90IDE2Q2b8sXo3pZkgF9C9DLWbZXo4rPKY7K9GhVUNlSViXeqTPd/Zy3FPr
P++UX3fVIqjgagqf4IyUR4ScmIgXSlRn4hyzjOt0LrpdBi6gDx+l8CVHGpMhfOvYHQAn
5DZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1740354790; x=1740959590;
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=uvPSEJc2mQLHQ3aicQOmQgvpF0IEH+AZN3fEj+wCF+s=;
b=DvaDoAw/DK5HKf4nZUksXefZHQoq1u0ANYiyfTB89y+46PfcwEdo9iD8n39wipDizc
3xaGt25GCntnwoPYnvdDpgZU0zmOVS8oo5YSmQujCWKwvnwuw7sEPHjLCJPjUOrUx0hY
3R0KCLUPICEEWEV+dLQPwZdt6MMUGGwLfOz00nGKSTsZzE7R/9CCEiUzPtKaFbDjfG+g
eI+Fj51wPRNPNQgnXGPjnbzfPC9rJjJeqea9KcI0za8ImwsrVbgWaGn/j/sPkW6n/Zol
eaIv4Ya8RUCI6h4mgFW/AdzoOsOlIRfSWNK/rZJ8GG39aHBw4khBh/+izO7APjGRjrP1
EyJQ==
X-Forwarded-Encrypted: i=2; AJvYcCVUzrLBytM5uFDdWnz8Hw2i3MLt3XS+FdMltCcFrm8LhUCMMlYKSyT4kol7S/wUegmNRmWKAj1/jDl0@gnusha.org
X-Gm-Message-State: AOJu0YxIH6EOXf2yIMDcoTsIvDngZRY+tuiDE/ZQ/2yPChm/foX8sBZ3
Bf/NlY0Jm9J8OHPgDIRJvicWgeO3bzRUiY+ANzlHouUTgUqEo6Rl
X-Google-Smtp-Source: AGHT+IGfu/6CAsniAPhJSgPhDOnJ69HE1Y1PXzmKHxXWqHZAW7tMDhzjjwUsB/SsX7gf09OGcsRffw==
X-Received: by 2002:a05:6870:fbac:b0:29e:5cb1:b148 with SMTP id 586e51a60fabf-2bd51500124mr9374401fac.6.1740354790131;
Sun, 23 Feb 2025 15:53:10 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVEbXp01S+xMEtmrYXttWfTyYERlMshGePCgrb5T0nM1jQ==
Received: by 2002:a05:6870:a90e:b0:2b8:f3e5:a817 with SMTP id
586e51a60fabf-2bd50bf1d9bls1059548fac.2.-pod-prod-02-us; Sun, 23 Feb 2025
15:53:07 -0800 (PST)
X-Received: by 2002:a05:6808:80af:b0:3f4:756:52cf with SMTP id 5614622812f47-3f425a7e5ffmr8918473b6e.10.1740354786913;
Sun, 23 Feb 2025 15:53:06 -0800 (PST)
Received: by 2002:a05:600c:3c9c:b0:439:a596:e64 with SMTP id 5b1f17b1804b1-439ae26b649ms5e9;
Sun, 23 Feb 2025 14:36:05 -0800 (PST)
X-Received: by 2002:a05:600c:6b66:b0:439:96a4:d2a8 with SMTP id 5b1f17b1804b1-439a2fb2c41mr110368815e9.5.1740350163563;
Sun, 23 Feb 2025 14:36:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1740350163; cv=none;
d=google.com; s=arc-20240605;
b=M8novVcXa4tX/13fBX8BeuzymGTEHhBdMR7JyjuHFiqnImZlV+cj6qUR8yDzDD2sJS
LfgeN30UYEdAoKmyubM0uD5uyzDH3DfJsNxs8NbwpY53S+ToX3d5AS9SpSVg7HHE4Cwz
742N6ZZQZSso7kwxXYfmstPhh2+sSWD6SboCWlL0XMlqnmWfB9sdv0MrtVeaJ/kbX1by
w+x+GxTeHxaK0QvHdSTafWxJAygVGJiMDSWsVVrWEz1kFbl/GUCzXDiySsWzM0Ffni1h
5AAqugMY567VbnbSk5UhvPYVUDiOGiAdqjVOV2pLzv8pw6z93IdKDFnwcorqzuWv8QSH
e3tQ==
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=iQzYaODkGrcUQAj/H6lk9rdwT5JKtir1B40QEzQ7mQU=;
fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=;
b=bzJZhUlK0cZKcb2zOqv9qnfjybz9dZeD2tWAwe6SEIN8YxGyjiASsfTfB+urvX+IWc
SPfI+TJk+RbgpnSOc3E7bRno9CKjnGoZo3i/yOfQLsejYKXODMKkX0UpR0J8kVEZMvO8
mfz34sceML0EaRPmqyOb0jDRFjWmoILpKrYmGhr9Vmfr1CHg5v3qm/vCq4t16X8X6wvM
BHntgW77dpeGnG6r6uiKQatMzd02ddzaiPF5zdNAN/MrAR7Z4lhVXN2Undn405tXs+Gp
GMqmhyynKdawrAwd3TToYN63r+mhFd4z8a1thhjCwnqePIdBIuJ+93gt3VZQOhZ6/Uyh
bJhw==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UI4Sz9HB;
spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.131 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch. [185.70.40.131])
by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4399bea9edesi8269645e9.0.2025.02.23.14.36.03
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 23 Feb 2025 14:36:03 -0800 (PST)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.40.131 as permitted sender) client-ip=185.70.40.131;
Date: Sun, 23 Feb 2025 22:35:59 +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: <VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYbWns5nP4TANCWvPJYu1ew_yxQSaudizzk=@protonmail.com>
In-Reply-To: <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com>
References: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com> <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 52246b72b46a52236668a264b6b46f5bcb597d96
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1=_YwUdvv4IHL6z7x5zyDJd4pP51qxIeu07qSbwExzNs"
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=UI4Sz9HB;
spf=pass (google.com: domain of darosior@protonmail.com designates
185.70.40.131 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=_YwUdvv4IHL6z7x5zyDJd4pP51qxIeu07qSbwExzNs
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> A 40x decrease to a validation time of 30 seconds probably is worth a bit=
of risk for a further improvement.
Depends on what hardware. I don't think a worst case of 30 seconds for end =
users is worth more risks. A worst case of 30 seconds for miners would prob=
ably be concerning.
In addition, although the worst case is important to limit the damage an at=
tacker can do without being economically rational, what we care about for m=
iners attacking each other is economically viable attacks. At the moment th=
e optimal "validation time / cost to attacker" 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 not =
economically viable for an attacker as a safety margin. But we should keep =
in mind this is already overestimating the attack risk since in this scenar=
io what we should look at is the worst case validation time of blocks that =
may have positive returns to an attacker.
> Can you put numbers to this?
Sure. Using my functional test which runs the worst case today and the wors=
t case under various mitigations [1] on a Dell XPS 15 9520 laptop (the mode=
l with an i5-12500H) i get 120 seconds for the worst case today and 10 seco=
nds for the worst block with a limited of 2500 (potentially) executed sigop=
s per transaction. To (maybe, they could be running more powerful machines =
than my laptop) impose such a validation time to other miners an attacker w=
ould have to invest 89 (!!) preparation blocks. Sure, with low fees the opp=
ortunity cost of mining preparation transactions is not as high as it could=
be. But still.
[0] [https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/7=
0](https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70?=
u=3Dantoinep)
[1] [https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/6=
1](https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/61?=
u=3Dantoinep)
On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo <lf-lists@mattcor=
allo.com> wrote:
> In the delving post you said =E2=80=9CThis provides a 40x decrease in the=
worst case validation time with a straightforward and flexible rule minimi=
zing the confiscatory surface. A further 7x decrease is possible by combini=
ng it with another rule, which is in my opinion not worth the additional co=
nfiscatory surface.=E2=80=9D
>
> Can you put numbers to this? How long does it take to validate a full blo=
ck with this 40x decrease and how long would it take with the further 7x de=
crease?
>
> A 40x decrease to a validation time of 30 seconds probably is worth a bit=
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 Mail=
ing List <bitcoindev@googlegroups.com> wrote:
>
>> =EF=BB=BFHi everyone,
>>
>> A bit over a year ago i started working on revisiting the 2019 Great Con=
sensus Cleanup proposal from
>> Matt Corallo [0]. His proposal included:
>> - making <=3D64 bytes transactions invalid to fix merkle tree weaknesses=
;
>> - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARATO=
R and non-standard sighash
>> types fail script validation to mitigate the worst case block validation=
time;
>> - restrict the nTime field of the first block in each difficulty adjustm=
ent 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 int=
ended to patch, the
>> alternative fixes possible for each and finally if there was any other p=
rotocol bug fix we'd want to
>> include if we went through the considerable effort of soft forking Bitco=
in already.
>>
>> Later in March i shared some first findings on Delving [1] and advertize=
d 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 lar=
ger design space available
>> to fix this issue, this private thread is where most of the discussion w=
ould happen. Thank you to
>> everyone who contributed feedback, insights, ideas and argumented opinio=
ns on the different issues
>> all along the process.
>>
>> Now i would like to update the broader Bitcoin development community on =
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 dif=
ficulty adjustment
>> algorithm. In particular, a fix for the timewarp attack with a 7200 seco=
nds grace period as well
>> as a fix for the Murch-Zawy attack [4] by making invalid any difficulty =
adjustment period with a
>> negative duration.
>> - A fix for long block validation times with a minimal "confiscation sur=
face", 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 serializ=
e to exactly 64 bytes
>> invalid.
>> - A fix for duplicate transactions to supplement BIP34 in order to avoid=
resuming unnecessary BIP30
>> validation in the future. This is achieved by mandating the nLockTime fi=
eld 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/7f9670b643b7c943a0cc6d2197d=
3eabe661050c2/bip-XXXX.mediawiki
>> [1] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
>> [2] https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ
>> [3] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711
>> [4] https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/106=
2#variant-on-zawys-attack-2
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoind=
ev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0=
B_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/=
VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYb=
Wns5nP4TANCWvPJYu1ew_yxQSaudizzk%3D%40protonmail.com.
--b1=_YwUdvv4IHL6z7x5zyDJd4pP51qxIeu07qSbwExzNs
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<blockquote style=3D"border-left: 3px solid rgb(200, 200, 200); border-colo=
r: rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"><div=
style=3D"font-family: Arial, sans-serif; font-size: 14px;"><span dir=3D"lt=
r"><span style=3D"font-size: 16px; color: rgb(42, 42, 43); background-color=
: rgb(255, 255, 255);">A 40x decrease to a validation time of 30 seconds pr=
obably is worth a bit of risk for a further improvement.</span></span><br><=
/div></blockquote>
<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>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><=
div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Depends on w=
hat hardware. I don't think a worst case of 30 seconds for end users is wor=
th more risks. A worst case of 30 seconds for miners would probably be conc=
erning.</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;"=
>In addition, although the worst case is important to limit the damage an a=
ttacker can do without being economically rational, what we care about for =
miners attacking each other is economically viable attacks. At the moment t=
he optimal "validation time / cost to attacker" ratio is not the worst case=
, by a large margin [0].</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;">I believe we should take into account the worst case to m=
iners even if not economically viable for an attacker as a safety margin. B=
ut we should keep in mind this is already overestimating the attack risk si=
nce in this scenario what we should look at is the worst case validation ti=
me of blocks that may have positive returns to an attacker.</div><div style=
=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><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);"><div style=3D"f=
ont-family: Arial, sans-serif; font-size: 14px;"><span style=3D"font-size: =
16px; color: rgb(42, 42, 43); background-color: rgb(255, 255, 255);">Can yo=
u put numbers to this?</span></div></blockquote><div style=3D""><br></div><=
div style=3D"">Sure. Using my functional test which runs the worst case tod=
ay and the worst case under various mitigations [1] on a <span>Dell XPS 15 =
9520</span> laptop (the model with an i5-12500H) i get 120 seconds for the =
worst case today and 10 seconds for the worst block with a limited of 2500 =
(potentially) executed sigops per transaction. To (maybe, they could be run=
ning more powerful machines than my laptop) impose such a validation time t=
o other miners an attacker would have to invest 89 (!!) preparation blocks.=
Sure, with low fees the opportunity cost of mining preparation transaction=
s is not as high as it could be. But still.<br></div><div style=3D"font-fam=
ily: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-fami=
ly: Arial, sans-serif; font-size: 14px;">[0] <span><a target=3D"_blank" rel=
=3D"noreferrer nofollow noopener" href=3D"https://delvingbitcoin.org/t/wors=
t-block-validation-time-inquiry/711/70?u=3Dantoinep">https://delvingbitcoin=
.org/t/worst-block-validation-time-inquiry/711/70</a></span></div><div styl=
e=3D"font-family: Arial, sans-serif; font-size: 14px;">[1] <span><a target=
=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://delvingbit=
coin.org/t/worst-block-validation-time-inquiry/711/61?u=3Dantoinep">https:/=
/delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/61</a></span>=
<br></div><div class=3D"protonmail_quote">
On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo <lf-li=
sts@mattcorallo.com> wrote:<br>
<blockquote class=3D"protonmail_quote" type=3D"cite">
<div dir=3D"ltr"></div><div dir=3D"ltr"><div dir=3D"ltr">In the=
delving post you said =E2=80=9C<span style=3D"caret-color: rgb(42, 42, 43)=
; color: rgb(42, 42, 43); font-family: Arial, sans-serif; font-size: 16px; =
-webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);">This=
provides a 40x decrease in the worst case validation time with a straightf=
orward and flexible rule minimizing the confiscatory surface. A further 7x =
decrease is possible by combining it with another rule, which is in my opin=
ion not worth the additional confiscatory surface.=E2=80=9D</span></div><di=
v dir=3D"ltr"><span style=3D"caret-color: rgb(42, 42, 43); color: rgb(42, 4=
2, 43); font-family: Arial, sans-serif; font-size: 16px; -webkit-text-size-=
adjust: 100%; background-color: rgb(255, 255, 255);"><br></span></div><div =
dir=3D"ltr"><span style=3D"caret-color: rgb(42, 42, 43); color: rgb(42, 42,=
43); font-family: Arial, sans-serif; font-size: 16px; -webkit-text-size-ad=
just: 100%; background-color: rgb(255, 255, 255);">Can you put numbers to t=
his? How long does it take to validate a full block with this 40x decrease =
and how long would it take with the further 7x decrease?</span></div><div d=
ir=3D"ltr"><span style=3D"caret-color: rgb(42, 42, 43); color: rgb(42, 42, =
43); font-family: Arial, sans-serif; font-size: 16px; -webkit-text-size-adj=
ust: 100%; background-color: rgb(255, 255, 255);"><br></span></div><div dir=
=3D"ltr"><span style=3D"caret-color: rgb(42, 42, 43); color: rgb(42, 42, 43=
); font-family: Arial, sans-serif; font-size: 16px; -webkit-text-size-adjus=
t: 100%; background-color: rgb(255, 255, 255);">A 40x decrease to a validat=
ion time of 30 seconds probably is worth a bit of risk for a further improv=
ement. A 40x decrease to 1 second is obviously fine :).</span></div></div><=
div dir=3D"ltr"><br><div dir=3D"ltr"></div><blockquote type=3D"cite">On Feb=
5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin Development Mailing List =
<bitcoindev@googlegroups.com> wrote:<br><br></blockquote></div><block=
quote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<span>Hi everyone,</span><br>=
<span></span><br><span>A bit over a year ago i started working on revisitin=
g the 2019 Great Consensus Cleanup proposal from</span><br><span>Matt Coral=
lo [0]. His proposal included:</span><br><span>- making <=3D64 bytes tra=
nsactions invalid to fix merkle tree weaknesses;</span><br><span>- making n=
on-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARATOR and non-sta=
ndard sighash</span><br><span> types fail script validation to mitiga=
te the worst case block validation time;</span><br><span>- restrict the nTi=
me field of the first block in each difficulty adjustment interval to be no=
less</span><br><span> than 600 seconds lower than the previous block=
's;</span><br><span></span><br><span>I set out to research the impact of ea=
ch of the vulnerabilities this intended to patch, the</span><br><span>alter=
native fixes possible for each and finally if there was any other protocol =
bug fix we'd want to</span><br><span>include if we went through the conside=
rable effort of soft forking Bitcoin already.</span><br><span></span><br><s=
pan>Later in March i shared some first findings on Delving [1] and advertiz=
ed the effort on this mailing</span><br><span>list [2]. I also created a co=
mpanion thread on Delving, kept private, to discuss the details of the</spa=
n><br><span>worst case block validation time [3]. As one would expect due t=
o the larger design space available</span><br><span>to fix this issue, this=
private thread is where most of the discussion would happen. Thank you to<=
/span><br><span>everyone who contributed feedback, insights, ideas and argu=
mented opinions on the different issues</span><br><span>all along the proce=
ss.</span><br><span></span><br><span>Now i would like to update the broader=
Bitcoin development community on the outcome of this effort.</span><br><sp=
an>I believe a Consensus Cleanup proposal should include the following.</sp=
an><br><span>- A fix for vulnerabilities surrounding the use of timestamps =
in the difficulty adjustment</span><br><span> algorithm. In par=
ticular, a fix for the timewarp attack with a 7200 seconds grace period as =
well</span><br><span> as a fix for the Murch-Zawy attack [4] by makin=
g invalid any difficulty adjustment period with a</span><br><span> ne=
gative duration.</span><br><span>- A fix for long block validation times wi=
th a minimal "confiscation surface", by introducing a</span><br><span> &nbs=
p;per-transaction limit on the number of legacy sigops in the inputs.</span=
><br><span>- A fix for merkle tree weaknesses by making transactions which =
serialize to exactly 64 bytes</span><br><span> invalid.</span><br><sp=
an>- A fix for duplicate transactions to supplement BIP34 in order to avoid=
resuming unnecessary BIP30</span><br><span> validation in the future=
. This is achieved by mandating the nLockTime field of coinbase</span><br><=
span> transaction to be set to the height of their block minus 1.</sp=
an><br><span></span><br><span>I have started drafting a BIP draft with the =
detailed specs for this.</span><br><span></span><br><span>Antoine Poinsot</=
span><br><span></span><br><span></span><br><span>[0] https://github.com/The=
BlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediaw=
iki</span><br><span>[1] https://delvingbitcoin.org/t/great-consensus-cleanu=
p-revival/710</span><br><span>[2] https://groups.google.com/g/bitcoindev/c/=
CAfm7D5ppjo/m/bYJ3BiOuAAAJ</span><br><span>[3] https://delvingbitcoin.org/t=
/worst-block-validation-time-inquiry/711</span><br><span>[4] https://delvin=
gbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#variant-on-zawys-at=
tack-2</span><br><span></span><br><span>-- </span><br><span>You received th=
is message because you are subscribed to the Google Groups "Bitcoin Develop=
ment Mailing List" group.</span><br><span>To unsubscribe from this group an=
d stop receiving emails from it, send an email to bitcoindev+unsubscribe@go=
oglegroups.com.</span><br><span>To view this discussion visit https://group=
s.google.com/d/msgid/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJ=
svK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40proto=
nmail.com.</span><br></div></blockquote>
</blockquote><br>
</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/VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMe=
J4Nqv1VOrYbWns5nP4TANCWvPJYu1ew_yxQSaudizzk%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYb=
Wns5nP4TANCWvPJYu1ew_yxQSaudizzk%3D%40protonmail.com</a>.<br />
--b1=_YwUdvv4IHL6z7x5zyDJd4pP51qxIeu07qSbwExzNs--