Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival

From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <[email-masked]>
Date: Mon, 10 Feb 2025 16:28:32 +0000

Hi "evil" Ariard,

I believe it is important to bundle all fixes together to make up for the substantial fixed cost of deploying a soft fork. It also seems absurd to deploy a soft fork aimed at patching security bugs, but only fix some of them and leave the protocol partly vulnerable. While it is technically possible it is not something i want to encourage.

Regarding the confiscation surface, please note the specific concerns raised about the 2019 proposal do not apply to the fix proposed here. The new approach to mitigating the worst case validation time is extremely conservative in this regard: no opcodes or other Script functionality get disabled. Only a limit is introduced at the transaction level, which allows to pinpoint exactly the harmful behaviour without rendering any innocent transaction invalid.

Best,
Antoine (the non-evil-one?)

On Sunday, February 9th, 2025 at 7:15 PM, Antoine Riard <[email-masked]> wrote:

> Hi Darosior,
>
> Thanks for the work on reviving the Great Consensus Cleanup.
>
>> Now i would like to update the broader Bitcoin development community on the 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 difficulty adjustment
>> algorithm. In particular, a fix for the timewarp attack with a 7200 seconds 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 surface", 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 field of coinbase
>> transaction to be set to the height of their block minus 1.
>>
>> I have started drafting a BIP draft with the detailed specs for this.
>
> So assuming some hypothetical future BIP-9-based deployment, there can be multiple soft-forks
> activation at the same time (up to 30), as a soft-fork can be assigned distinct block nVersion
> bit. While BIP-9 recommends a 95% activation threshold on mainnet, it's one line change to
> adjust the `nThreshold` variable to another value. For the fix about timewarp vulnerabilities,
> as it's an additional constraint on the validity of mined blocks allowed the current reward
> schedule, there could be some reluctance in adopting the new consensus rules, and this fix
> could deserve a specific threshold of its own - imho.
>
> Additionally, the proposed soft-fork fixes are very different than the 3 set of rules than
> have been activated under the DEPLOYMENT_TAPROOT flag. While BIP340, BIP341 and BIP342 are
> building on top of each other in a modular fashion, this is not the case here with the 4
> proposed fixes ("timewarp"/"worst-block-time"/"merkle-tree-weakness"/"enhanced-duplicated-txn",
> as adoption of one fix is not necessitated to adopt the other fixes. There could be some
> community consensus on "timewarp"/"merke-tree-weakness"/"enhanced-duplicated-txn", while
> the minimal "confiscation surface" (which was very controversial when the GCC was proposed
> the 1st time in 2019), not suiting a wide majority of folks, or even people who have use-cases
> potentially affected.
>
> For those reasons, I think it's wiser to spread each fix in its own BIP and patchset of
> code changes to not only have discussions of each fix in parallel, though also eventually
> enable separate activation of each consensus fix, in the optic that each fix might gather
> different level of consensus, whatever the reasons.
>
> This might be a stylistic note, though I could point in bitcoin core code today implemented
> check in the script interpreter right in the crux of consensus code paths that is just stale
> due to a never-activated BIP (-- yes I'm starring at you SIGPUSHONLY).
>
> Best,
> Antoine (the "evil" one)
>
> OTS hash: 6c809fde007a53f380af41f0e22f3b9e95c83da24c2718ac2de0004570f94990
>
> Le jeudi 6 février 2025 à 21:46:42 UTC, Murch a écrit :
>
>> Thank you for the update and your work on the Great Consensus Cleanup. I
>> am looking forward to reading your BIP, and would hope that you could
>> share here or in the BIP’s Rationale what convinced you to change the
>> grace period from 600 seconds to 7200 seconds and how the nLockTime of
>> height-1 won out.
>>
>> Cheers,
>> Murch
>>
>> On 2025-02-05 13:09, 'Antoine Poinsot' via Bitcoin Development Mailing
>> List wrote:
>>> Hi everyone,
>>>
>>> A bit over a year ago i started working on revisiting the 2019 Great Consensus Cleanup proposal from
>>> Matt Corallo [0]. His proposal included:
>>> - making <=64 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 adjustment interval to be no less
>>> than 600 seconds lower than the previous block's;
>>>
>>> I set out to research the impact of each of the vulnerabilities this intended to patch, the
>>> alternative fixes possible for each and finally if there was any other protocol bug fix we'd want to
>>> include if we went through the considerable effort of soft forking Bitcoin already.
>>>
>>> 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 larger design space available
>>> to fix this issue, this private thread is where most of the discussion would happen. Thank you to
>>> everyone who contributed feedback, insights, ideas and argumented opinions on the different issues
>>> all along the process.
>>>
>>> Now i would like to update the broader Bitcoin development community on the 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 difficulty adjustment
>>> algorithm. In particular, a fix for the timewarp attack with a 7200 seconds 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 surface", 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 field of coinbase
>>> transaction to be set to the height of their block minus 1.
>>>
>>> I have started drafting a BIP draft with the detailed specs for this.
>>>
>>> Antoine Poinsot
>>>
>>>
>>> [0] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/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
>>>
>
> --
> 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/53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.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/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc%3D%40protonmail.com.