Delivery-date: Thu, 27 Mar 2025 12:36:20 -0700
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.30 as permitted sender) client-ip=79.135.106.30;
Date: Thu, 27 Mar 2025 19:05:15 +0000
To: Chris Stewart <stewart.chris1234@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Consensus Cleanup BIP draft
Message-ID: <TD8gP8PKw3th-0DrZznBXrXFILRkwr66wVRoiPC2di_e-NivCRKVjooVZIh7JJSV_C9rJEkKTvudWSG8CJsq16jPhQBjM0eVmPe8rir50Y4=@protonmail.com>
In-Reply-To: <CAGL6+mFQqTS21cQZ_aU=hXtMaKkw5ygAk2PT9hQpdB4THz9X_A@mail.gmail.com>
References: <uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g=@protonmail.com> <CAGL6+mFQqTS21cQZ_aU=hXtMaKkw5ygAk2PT9hQpdB4THz9X_A@mail.gmail.com>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_fHzgokfmYhE6vVmdb3WdF9hvRcFl9bXl9vFl4wzCK2M"
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

Hi Chris,

As i already explained on this very list 2 months ago [0], i don't find the=
 argument for splitting my BIP convincing. On the contrary i think it would=
 be counterproductive as it would create more churn, invite bikeshedding an=
d overall impede progress on this proposal.

> we've successfully activated multiple BIPs within a single soft fork in t=
he past=E2=80=94e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP34=
2, and BIP343 in Taproot.

Those BIPs had much more content to them. The specifications of the Consens=
us Cleanup is trivial in comparison: they fit in less than a dozen lines of=
 text when described in details. Splitting them in 4 different BIPs with a =
single or a couple lines of specifications would just introduce unnecessary=
 overhead.

> if one of the proposed changes turns out to be controversial, we could re=
move it without holding up the rest of the improvements.

First of all, i do not expect to remove any of the mitigations from the BIP=
 at this stage. The fact that each of these mitigations was researched and =
discussed at length by multiple people over the past year gives me confiden=
ce to move forward with every single one of those. Otherwise i would not ha=
ve proposed this BIP in the first place.

Now, even if somehow we should drop one of the mitigations from the proposa=
l, having them in separate BIPs does not make that any easier.

> More active contributors to the project may have stronger opinions on the=
 best approach there.

Yes.

Best,
Antoine

[0] https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFF=
Ny0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=3D@pr=
otonmail.com
On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart <stewart.chris1234@=
gmail.com> wrote:

> 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 thes=
e protocol changes to non-technical users. However, since this is a technic=
al forum and we are producing BIPs intended for technical audiences, I beli=
eve we should document these changes in separate BIPs.
>
> The proposed security fixes are largely unrelated from a technical standp=
oint:
>
> -
>
> Timewarp attack mitigation
>
> -
>
> Worst-case block validation constraints
>
> -
>
> Disallowing 64-byte transactions
>
> -
>
> 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 depl=
oying soft forks is difficult, so all changes should be bundled together. W=
hile soft fork deployment is indeed challenging, we've successfully activat=
ed multiple BIPs within a single soft fork in the past=E2=80=94e.g., BIP141=
 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If=
 the community reaches consensus, we can still deploy all these changes tog=
ether, even if they are documented separately.
>
> This approach also provides flexibility: if one of the proposed changes t=
urns out to be controversial, we could remove it without holding up the res=
t of the improvements. Additionally, once these fixes are deployed, there w=
ill likely be significant research and documentation to incorporate, and ma=
intaining 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 opi=
nions on the best approach there.
>
> -Chris
>
> ---------------------------------------------------------------
>
> On Wed, Mar 26, 2025 at 1:23=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Dev=
elopment Mailing List <bitcoindev@googlegroups.com> wrote:
>
>> Hi everyone,
>>
>> About two months ago i shared an update on this list about my (and other=
s', really) work on the
>> Consensus Cleanup [0]. I am now ready to share a BIP draft for a Consens=
us Cleanup soft fork.
>>
>> The BIP draft can be found here: https://github.com/darosior/bips/blob/c=
onsensus_cleanup/bip-cc.md
>>
>> It includes the following fixes:
>> - a restriction on the timestamp of the first and last blocks of a diffi=
culty adjustment period to
>> address the Timewarp and Murch-Zawy attacks;
>> - a limit on the number of legacy signature operations that may be execu=
ted in validating a single
>> transaction to address long block validation times;
>> - making 64 bytes transactions invalid to address weaknesses in the bloc=
k 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 Co=
rallo [1]. A number of
>> people contributed ideas, testing, data or useful discussions. This incl=
udes Ava Chow, Matt Corallo,
>> Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony Tow=
ns, Greg Sanders, Chris
>> Stewart, Eric Voskuil, @0xb10c and others.
>>
>> Antoine Poinsot
>>
>> [0] https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldc=
ugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=3D=
@protonmail.com
>> [1] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d=
3eabe661050c2/bip-XXXX.mediawiki
>>
>> --
>> 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](mailto:bitcoindev%2Bun=
subscribe@googlegroups.com).
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoind=
ev/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eI=
i1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%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/=
TD8gP8PKw3th-0DrZznBXrXFILRkwr66wVRoiPC2di_e-NivCRKVjooVZIh7JJSV_C9rJEkKTvu=
dWSG8CJsq16jPhQBjM0eVmPe8rir50Y4%3D%40protonmail.com.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hi Chris,</=
div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></d=
iv><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">As i alr=
eady explained on this very list 2 months ago [0], i don't find the argumen=
t for splitting my BIP convincing. On the contrary i think it would be coun=
terproductive as it would create more churn, invite bikeshedding and overal=
l impede progress on this proposal.</div><div style=3D"font-family: Arial, =
sans-serif; font-size: 14px;"><br></div><blockquote style=3D"border-left: 3=
px solid rgb(200, 200, 200); border-color: rgb(200, 200, 200); padding-left=
: 10px; color: rgb(102, 102, 102);"><div style=3D"font-family: Arial, sans-=
serif; font-size: 14px;">we've successfully activated multiple BIPs within =
a single soft fork in=20
the past=E2=80=94e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP3=
42,=20
and BIP343 in Taproot.<br></div></blockquote><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Aria=
l, sans-serif; font-size: 14px;">Those BIPs had much more content to them. =
The specifications of the Consensus Cleanup is trivial in comparison: they =
fit in less than a dozen lines of text when described in details. Splitting=
 them in 4 different BIPs with a single or a couple lines of specifications=
 would just introduce unnecessary overhead.</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); padd=
ing-left: 10px; color: rgb(102, 102, 102);"><div style=3D"font-family: Aria=
l, sans-serif; font-size: 14px;">if one of the proposed changes turns out t=
o be controversial, we could=20
remove it without holding up the rest of the improvements.<br></div></block=
quote><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br>F=
irst of all, i do not expect to remove any of the mitigations from the BIP =
at this stage.&nbsp;The fact that each of these mitigations was researched =
and discussed at length by multiple people over the past year gives me conf=
idence to move forward with every single one of those. Otherwise i would no=
t have proposed this BIP in the first place.</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;">Now, even if somehow we should drop o=
ne of the mitigations from the proposal, having them in separate BIPs does =
not make that any easier.</div><div style=3D"font-family: Arial, sans-serif=
; font-size: 14px;"><br></div><blockquote style=3D"border-left: 3px solid r=
gb(200, 200, 200); border-color: rgb(200, 200, 200); padding-left: 10px; co=
lor: rgb(102, 102, 102);"><div style=3D"font-family: Arial, sans-serif; fon=
t-size: 14px;">More active contributors to the project may have stronger op=
inions on the best approach there.<br></div></blockquote><div style=3D"font=
-family: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-=
family: Arial, sans-serif; font-size: 14px;">Yes.</div><div style=3D"font-f=
amily: Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-fa=
mily: Arial, sans-serif; font-size: 14px;">Best,<br>Antoine<br></div><div s=
tyle=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><div st=
yle=3D"font-family: Arial, sans-serif; font-size: 14px;">[0] <span><a targe=
t=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://gnusha.or=
g/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76i=
t60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=3D@protonmail.com">https:/=
/gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt=
220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=3D@protonmail.co=
m</a></span><br></div><div class=3D"protonmail_quote">
        On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart &lt;stewart=
.chris1234@gmail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=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 "Great Consensus Cleanup" is a fantastic brand for communicating the=
se protocol changes to non-technical users. However, since this is a techni=
cal forum and we are producing BIPs intended for technical audiences, I bel=
ieve 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 "Great Consensus Cleanup" branding 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've successfully activa=
ted multiple BIPs within a single soft fork in the past=E2=80=94e.g., BIP14=
1 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. I=
f the community reaches consensus, we can still deploy all these changes to=
gether, 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 class=3D"gmail_attr" dir=3D"ltr">On Wed, Mar 26, 2025 at 1:23=E2=
=80=AFPM 'Antoine Poinsot' via Bitcoin Development Mailing List &lt;<a targ=
et=3D"_blank" href=3D"mailto:bitcoindev@googlegroups.com" rel=3D"noreferrer=
 nofollow noopener">bitcoindev@googlegroups.com</a>&gt; wrote:<br></div><bl=
ockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" class=3D=
"gmail_quote">Hi everyone,<br>
<br>
About two months ago i shared an update on this list about my (and others',=
 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 target=3D"_blank" rel=3D"noreferrer nof=
ollow noopener" href=3D"https://github.com/darosior/bips/blob/consensus_cle=
anup/bip-cc.md">https://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>
  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>
  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>
  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 target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4=
hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=3D@protonmail.=
com">https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcug=
eIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=3D@p=
rotonmail.com</a><br>
[1] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c=
2/bip-XXXX.mediawiki">https://github.com/TheBlueMatt/bips/blob/7f9670b643b7=
c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki</a><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a target=3D"_blank" href=3D"mailto:bitcoindev%2Bunsubscribe@google=
groups.com" rel=3D"noreferrer nofollow noopener">bitcoindev+unsubscribe@goo=
glegroups.com</a>.<br>
To view this discussion visit <a target=3D"_blank" rel=3D"noreferrer nofoll=
ow noopener" href=3D"https://groups.google.com/d/msgid/bitcoindev/uDAujRxk4=
oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIvee=
LIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.com">https://groups.google.com/d/ms=
gid/bitcoindev/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xE=
QEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.com</a>.<br=
>
</blockquote></div></div>
</div>
</div>
</div>

        </blockquote><br>
    </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/TD8gP8PKw3th-0DrZznBXrXFILRkwr66wVRoiPC2di_e-NivCRKVjooVZIh7JJSV=
_C9rJEkKTvudWSG8CJsq16jPhQBjM0eVmPe8rir50Y4%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
TD8gP8PKw3th-0DrZznBXrXFILRkwr66wVRoiPC2di_e-NivCRKVjooVZIh7JJSV_C9rJEkKTvu=
dWSG8CJsq16jPhQBjM0eVmPe8rir50Y4%3D%40protonmail.com</a>.<br />

--b1=_fHzgokfmYhE6vVmdb3WdF9hvRcFl9bXl9vFl4wzCK2M--