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:
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’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
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.com.