Delivery-date: Fri, 21 Feb 2025 02:18:39 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99;
Content-Type: multipart/alternative; boundary=Apple-Mail-E949E000-858A-4E96-9F84-B86A0E0A8E12
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
Date: Thu, 20 Feb 2025 20:22:27 -0500
Message-Id: <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com>
References: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com>
Cc: bitcoindev@googlegroups.com
In-Reply-To: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com>
To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--Apple-Mail-E949E000-858A-4E96-9F84-B86A0E0A8E12
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In the delving post you said =E2=80=9CThis provides a 40x decrease in the w=
orst case validation time with a straightforward and flexible rule minimizi=
ng the confiscatory surface. A further 7x decrease is possible by combining=
 it with another rule, which is in my opinion not worth the additional conf=
iscatory surface.=E2=80=9D

Can you put numbers to this? How long does it take to validate a full block=
 with this 40x decrease and how long would it take with the further 7x decr=
ease?

A 40x decrease to a validation time of 30 seconds probably is worth a bit o=
f risk for a further improvement. A 40x decrease to 1 second is obviously f=
ine :).

> On Feb 5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin Development Maili=
ng List <bitcoindev@googlegroups.com> wrote:
>=20
> =EF=BB=BFHi everyone,
>=20
> A bit over a year ago i started working on revisiting the 2019 Great Cons=
ensus 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_CODESEPARATOR=
 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 adjustme=
nt interval to be no less
>  than 600 seconds lower than the previous block's;
>=20
> I set out to research the impact of each of the vulnerabilities this inte=
nded to patch, the
> alternative fixes possible for each and finally if there was any other pr=
otocol bug fix we'd want to
> include if we went through the considerable effort of soft forking Bitcoi=
n already.
>=20
> Later in March i shared some first findings on Delving [1] and advertized=
 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 larg=
er design space available
> to fix this issue, this private thread is where most of the discussion wo=
uld happen. Thank you to
> everyone who contributed feedback, insights, ideas and argumented opinion=
s on the different issues
> all along the process.
>=20
> Now i would like to update the broader Bitcoin development community on t=
he 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 diff=
iculty adjustment
>  algorithm.  In particular, a fix for the timewarp attack with a 7200 sec=
onds 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 surf=
ace", 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 serialize=
 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.
>=20
> I have started drafting a BIP draft with the detailed specs for this.
>=20
> Antoine Poinsot
>=20
>=20
> [0] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3=
eabe661050c2/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/1062=
#variant-on-zawys-attack-2
>=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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B=
_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/=
25482CCA-1F9D-4971-914F-674DF15C3414%40mattcorallo.com.

--Apple-Mail-E949E000-858A-4E96-9F84-B86A0E0A8E12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><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"care=
t-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: r=
gb(255, 255, 255);">This provides a 40x decrease in the worst case validati=
on time with a straightforward and flexible rule minimizing the confiscator=
y surface. A further 7x decrease is possible by combining it with another r=
ule, which is in my opinion not worth the additional confiscatory surface.=
=E2=80=9D</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-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: 1=
6px; -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);"=
>Can you put numbers to this? How long does it take to validate a full bloc=
k with this 40x decrease and how long would it take with the further 7x dec=
rease?</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: 16=
px; -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, 4=
3); color: rgb(42, 42, 43); font-family: Arial, sans-serif; font-size: 16px=
; -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);">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 fin=
e :).</span></div></div><div dir=3D"ltr"><br><div dir=3D"ltr"></div><blockq=
uote type=3D"cite">On Feb 5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin =
Development Mailing List &lt;bitcoindev@googlegroups.com&gt; wrote:<br><br>=
</blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<spa=
n>Hi everyone,</span><br><span></span><br><span>A bit over a year ago i sta=
rted working on revisiting the 2019 Great Consensus Cleanup proposal from</=
span><br><span>Matt Corallo [0]. His proposal included:</span><br><span>- m=
aking &lt;=3D64 bytes transactions invalid to fix merkle tree weaknesses;</=
span><br><span>- making non-pushonly scriptSigs, FindAndDelete matches, OP_=
CODESEPARATOR and non-standard sighash</span><br><span> &nbsp;types fail sc=
ript validation to mitigate the worst case block validation time;</span><br=
><span>- restrict the nTime field of the first block in each difficulty adj=
ustment interval to be no less</span><br><span> &nbsp;than 600 seconds lowe=
r than the previous block's;</span><br><span></span><br><span>I set out to =
research the impact of each of the vulnerabilities this intended to patch, =
the</span><br><span>alternative fixes possible for each and finally if ther=
e was any other protocol bug fix we'd want to</span><br><span>include if we=
 went through the considerable effort of soft forking Bitcoin already.</spa=
n><br><span></span><br><span>Later in March i shared some first findings on=
 Delving [1] and advertized the effort on this mailing</span><br><span>list=
 [2]. I also created a companion thread on Delving, kept private, to discus=
s the details of the</span><br><span>worst case block validation time [3]. =
As one would expect due to the larger design space available</span><br><spa=
n>to fix this issue, this private thread is where most of the discussion wo=
uld happen. Thank you to</span><br><span>everyone who contributed feedback,=
 insights, ideas and argumented opinions on the different issues</span><br>=
<span>all along the process.</span><br><span></span><br><span>Now i would l=
ike to update the broader Bitcoin development community on the outcome of t=
his effort.</span><br><span>I believe a Consensus Cleanup proposal should i=
nclude the following.</span><br><span>- A fix for vulnerabilities surroundi=
ng the use of timestamps in the difficulty adjustment</span><br><span> &nbs=
p;algorithm. &nbsp;In particular, a fix for the timewarp attack with a 7200=
 seconds grace period as well</span><br><span> &nbsp;as a fix for the Murch=
-Zawy attack [4] by making invalid any difficulty adjustment period with a<=
/span><br><span> &nbsp;negative duration.</span><br><span>- A fix for long =
block validation times with a minimal "confiscation surface", by introducin=
g a</span><br><span> &nbsp;per-transaction limit on the number of legacy si=
gops in the inputs.</span><br><span>- A fix for merkle tree weaknesses by m=
aking transactions which serialize to exactly 64 bytes</span><br><span> &nb=
sp;invalid.</span><br><span>- A fix for duplicate transactions to supplemen=
t BIP34 in order to avoid resuming unnecessary BIP30</span><br><span> &nbsp=
;validation in the future. This is achieved by mandating the nLockTime fiel=
d of coinbase</span><br><span> &nbsp;transaction to be set to the height of=
 their block minus 1.</span><br><span></span><br><span>I have started draft=
ing a BIP draft with the detailed specs for this.</span><br><span></span><b=
r><span>Antoine Poinsot</span><br><span></span><br><span></span><br><span>[=
0] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eab=
e661050c2/bip-XXXX.mediawiki</span><br><span>[1] https://delvingbitcoin.org=
/t/great-consensus-cleanup-revival/710</span><br><span>[2] https://groups.g=
oogle.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ</span><br><span>[3] htt=
ps://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711</span><br=
><span>[4] https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack=
/1062#variant-on-zawys-attack-2</span><br><span></span><br><span>-- </span>=
<br><span>You received this message because you are subscribed to the Googl=
e Groups "Bitcoin Development Mailing List" group.</span><br><span>To unsub=
scribe from this group and stop receiving emails from it, send an email to =
bitcoindev+unsubscribe@googlegroups.com.</span><br><span>To view this discu=
ssion visit https://groups.google.com/d/msgid/bitcoindev/jiyMlvTX8BnG71f75S=
qChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qx=
nNLRBn3MopuATI%3D%40protonmail.com.</span><br></div></blockquote></body></h=
tml>

<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/25482CCA-1F9D-4971-914F-674DF15C3414%40mattcorallo.com?utm_mediu=
m=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev=
/25482CCA-1F9D-4971-914F-674DF15C3414%40mattcorallo.com</a>.<br />

--Apple-Mail-E949E000-858A-4E96-9F84-B86A0E0A8E12--