Delivery-date: Thu, 27 Mar 2025 05:19:38 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) client-ip=2607:f8b0:4864:20::1134;
MIME-Version: 1.0
References: <uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g=@protonmail.com>
In-Reply-To: <uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g=@protonmail.com>
From: Chris Stewart <stewart.chris1234@gmail.com>
Date: Thu, 27 Mar 2025 05:46:52 -0500
Message-ID: <CAGL6+mFQqTS21cQZ_aU=hXtMaKkw5ygAk2PT9hQpdB4THz9X_A@mail.gmail.com>
Subject: Re: [bitcoindev] Consensus Cleanup BIP draft
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000a488c4063150acd7"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

Hi Antoine,

First off, concept ACK. My concerns are procedural rather than objections
to the individual security fixes themselves.

The "Great Consensus Cleanup" is a fantastic brand for communicating these
protocol changes to non-technical users. However, since this is a technical
forum and we are producing BIPs intended for technical audiences, I believe
we should document these changes in separate BIPs.

The proposed security fixes are largely unrelated from a technical
standpoint:

   1.

   Timewarp attack mitigation
   2.

   Worst-case block validation constraints
   3.

   Disallowing 64-byte transactions
   4.

   Avoiding duplicate transactions

We should absolutely retain the "Great Consensus Cleanup" branding while
independently documenting each security enhancement.

A common concern I=E2=80=99ve heard about splitting this BIP is that deploy=
ing soft
forks is difficult, so all changes should be bundled together. While soft
fork deployment is indeed challenging, we've successfully activated
multiple BIPs within a single soft fork in the past=E2=80=94e.g., BIP141 an=
d BIP143
in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the
community reaches consensus, we can still deploy all these changes
together, even if they are documented separately.

This approach also provides flexibility: if one of the proposed changes
turns out to be controversial, we could remove it without holding up the
rest of the improvements. Additionally, once these fixes are deployed,
there will likely be significant research and documentation to incorporate,
and maintaining independent BIPs will make it easier to manage that growth.

I do see merit in implementing all the security fixes in a single PR for
Bitcoin Core. More active contributors to the project may have stronger
opinions on the best approach there.

-Chris
------------------------------


On Wed, Mar 26, 2025 at 1:23=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Devel=
opment
Mailing List <bitcoindev@googlegroups.com> wrote:

> Hi everyone,
>
> About two months ago i shared an update on this list about my (and
> others', really) work on the
> Consensus Cleanup [0]. I am now ready to share a BIP draft for a Consensu=
s
> Cleanup soft fork.
>
> The BIP draft can be found here:
> https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
>
> It includes the following fixes:
> - a restriction on the timestamp of the first and last blocks of a
> difficulty adjustment period to
>   address the Timewarp and Murch-Zawy attacks;
> - a limit on the number of legacy signature operations that may be
> executed in validating a single
>   transaction to address long block validation times;
> - making 64 bytes transactions invalid to address weaknesses in the block
> Merkle tree construction;
> - mandating coinbase transactions be timelocked to their block height to
> prevent future transaction
>   duplication without resorting to BIP30 validation.
>
> This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt
> Corallo [1]. A number of
> people contributed ideas, testing, data or useful discussions. This
> includes Ava Chow, Matt Corallo,
> Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony
> Towns, Greg Sanders, Chris
> Stewart, Eric Voskuil, @0xb10c and others.
>
> Antoine Poinsot
>
> [0]
> https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeID=
JVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=3D@prot=
onmail.com
> [1]
> https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe=
661050c2/bip-XXXX.mediawiki
>
> --
> 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/bitcoindev/uDAujRxk4oWnEGYX9lBD3e0V7a4V=
4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Z=
ne4g%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/=
CAGL6%2BmFQqTS21cQZ_aU%3DhXtMaKkw5ygAk2PT9hQpdB4THz9X_A%40mail.gmail.com.

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

<div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi=
 Antoine,
<p>First off, concept ACK. My concerns are procedural rather than objection=
s to the individual security fixes themselves.</p>
<p>The &quot;Great Consensus Cleanup&quot; is a fantastic brand for communi=
cating these protocol changes to non-technical users. However, since this i=
s a technical forum and we are producing BIPs intended for technical audien=
ces, I believe we should document these changes in separate BIPs.</p>
<p>The proposed security fixes are largely unrelated from a technical stand=
point:</p>
<ol><li>
<p>Timewarp attack mitigation</p>
</li><li>
<p>Worst-case block validation constraints</p>
</li><li>
<p>Disallowing 64-byte transactions</p>
</li><li>
<p>Avoiding duplicate transactions</p>
</li></ol>
<p>We should absolutely retain the &quot;Great Consensus Cleanup&quot; bran=
ding while independently documenting each security enhancement.</p>
<p>A common concern I=E2=80=99ve heard about splitting this BIP is that dep=
loying soft forks is difficult, so all changes should be bundled together. =
While soft fork deployment is indeed challenging, we&#39;ve successfully ac=
tivated multiple BIPs within a single soft fork in the past=E2=80=94e.g., B=
IP141 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproo=
t. If the community reaches consensus, we can still deploy all these change=
s together, even if they are documented separately.</p>
<p>This approach also provides flexibility: if one of the proposed changes =
turns out to be controversial, we could remove it without holding up the re=
st of the improvements. Additionally, once these fixes are deployed, there =
will likely be significant research and documentation to incorporate, and m=
aintaining independent BIPs will make it easier to manage that growth.</p>
<p>I do see merit in implementing all the security fixes in a single PR for=
 Bitcoin Core. More active contributors to the project may have stronger op=
inions on the best approach there.<br><br></p><p>-Chris <br></p><hr><div><b=
r></div><div><br></div><div><br></div></div></div></div></div></div><div><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 26, 2025 at 1:23=E2=
=80=AFPM &#39;Antoine Poinsot&#39; via Bitcoin Development Mailing List &lt=
;<a href=3D"mailto:bitcoindev@googlegroups.com" target=3D"_blank">bitcoinde=
v@googlegroups.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style=
:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi everyone,<br=
>
<br>
About two months ago i shared an update on this list about my (and others&#=
39;, really) work on the<br>
Consensus Cleanup [0]. I am now ready to share a BIP draft for a Consensus =
Cleanup soft fork.<br>
<br>
The BIP draft can be found here: <a href=3D"https://github.com/darosior/bip=
s/blob/consensus_cleanup/bip-cc.md" rel=3D"noreferrer" target=3D"_blank">ht=
tps://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md</a><br>
<br>
It includes the following fixes:<br>
- a restriction on the timestamp of the first and last blocks of a difficul=
ty adjustment period to<br>
=C2=A0 address the Timewarp and Murch-Zawy attacks;<br>
- a limit on the number of legacy signature operations that may be executed=
 in validating a single<br>
=C2=A0 transaction to address long block validation times;<br>
- making 64 bytes transactions invalid to address weaknesses in the block M=
erkle tree construction;<br>
- mandating coinbase transactions be timelocked to their block height to pr=
event future transaction<br>
=C2=A0 duplication without resorting to BIP30 validation.<br>
<br>
This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt Coral=
lo [1]. A number of<br>
people contributed ideas, testing, data or useful discussions. This include=
s Ava Chow, Matt Corallo,<br>
Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony Towns,=
 Greg Sanders, Chris<br>
Stewart, Eric Voskuil, @0xb10c and others.<br>
<br>
Antoine Poinsot<br>
<br>
[0] <a href=3D"https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZ=
DQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3Mo=
puATI=3D@protonmail.com" rel=3D"noreferrer" target=3D"_blank">https://gnush=
a.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT=
46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=3D@protonmail.com</a><=
br>
[1] <a href=3D"https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0c=
c6d2197d3eabe661050c2/bip-XXXX.mediawiki" rel=3D"noreferrer" target=3D"_bla=
nk">https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3ea=
be661050c2/bip-XXXX.mediawiki</a><br>
<br>
-- <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%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpB=
vQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.com" rel=3D"nor=
eferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/uDA=
ujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91i=
KFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.com</a>.<br>
</blockquote></div></div>
</div>
</div>
</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/CAGL6%2BmFQqTS21cQZ_aU%3DhXtMaKkw5ygAk2PT9hQpdB4THz9X_A%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAGL6%2BmFQqTS21cQZ_aU%3DhXtMaKkw5ygAk2PT9hQpdB4THz9X_A%=
40mail.gmail.com</a>.<br />

--000000000000a488c4063150acd7--