Subject: Re: [bitcoindev] Consensus Cleanup BIP draft

From: jeremy <[email-masked]>
Date: Thu, 27 Mar 2025 13:45:19 -0700 (PDT)

> 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 
confidence to move forward with every single one of those. Otherwise i 
would not have proposed this BIP in the first place.

I'd recommend taking a much more flexible mindset at this stage. The set of 
eyeballs you get at a pre-BIP and BIP stage, and the level of attention are 
very different, and this type of messaging is very discouraging for someone 
with expertise to care to put review in v.s. disregarding the effort as 
non-constructive.

Critically:

In your "discussed at length" proposal, you failed to realize that there 
were indeed 64 byte transactions on-chain until it was pointed out to you 7 
days ago.

You also include a hack using coinbase nSequence -- have you bothered to 
talk to anyone in the mining business how they feel about that? Are you 
sure no ASIC in the wild don't hardcode a field that never needed to be set 
before?

I'm also personally strongly against removing 64-byte transactions. It's a 
wart in how transactions work, and future upgrades (especially around tx 
programmability) might integrate very poorly with this kind of edge 
condition.

regards,

Jeremy

On Thursday, March 27, 2025 at 3:36:13 PM UTC-4 Antoine Poinsot wrote:

> 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 and overall impede progress on this proposal.
>
> we've successfully activated multiple BIPs within a single soft fork in 
> the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP342, and 
> BIP343 in Taproot.
>
>
> 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.
>
> if one of the proposed changes turns out to be controversial, we could 
> remove 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 
> confidence to move forward with every single one of those. Otherwise i 
> would not have proposed this BIP in the first place.
>
> Now, even if somehow we should drop one of the mitigations from the 
> proposal, 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_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=@protonmail.com
> On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart <
> [email-masked]> 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 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’ve heard about splitting this BIP is that deploying 
> 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—e.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 
> 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 PM 'Antoine Poinsot' via Bitcoin Development 
> Mailing List <[email-masked]> 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 
>> Consensus 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/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com
>> [1] 
>> https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/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 [email-masked].
>> To view this discussion visit 
>> https://groups.google.com/d/msgid/bitcoindev/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.com
>> .
>>
>
>

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-99c2-279173a440f3n%40googlegroups.com.