From: Matt Corallo <lf-lists@mattcorallo•com>
To: Antoine Poinsot <darosior@protonmail•com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
Date: Thu, 20 Feb 2025 20:22:27 -0500 [thread overview]
Message-ID: <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com> (raw)
In-Reply-To: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 4607 bytes --]
In the delving post you said “This provides a 40x decrease in the worst case validation time with a straightforward and flexible rule minimizing the confiscatory surface. A further 7x decrease is possible by combining it with another rule, which is in my opinion not worth the additional confiscatory surface.”
Can you put numbers to this? How long does it take to validate a full block with this 40x decrease and how long would it take with the further 7x decrease?
A 40x decrease to a validation time of 30 seconds probably is worth a bit of risk for a further improvement. A 40x decrease to 1 second is obviously fine :).
> On Feb 5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> 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 bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/25482CCA-1F9D-4971-914F-674DF15C3414%40mattcorallo.com.
[-- Attachment #2: Type: text/html, Size: 6954 bytes --]
next prev parent reply other threads:[~2025-02-21 10:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 18:09 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-02-06 21:34 ` Murch
2025-02-06 22:03 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-02-07 13:02 ` Antoine Riard
2025-02-10 16:28 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-02-14 17:40 ` Peter Todd
2025-02-15 21:13 ` Antoine Riard
2025-02-10 21:21 ` Chris Stewart
2025-02-11 21:20 ` Antoine Riard
2025-02-21 1:22 ` Matt Corallo [this message]
2025-02-23 22:35 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox