Okay! That's a much better outcome than I was thinking. I assume this was with parallelization

across the 4+8 available cores?

Do you happen to have numbers handy for the worst-case with, for

example, one block of prep?

On 2/23/25 5:35 PM, Antoine Poinsot wrote:

A 40x decrease to a validation time of 30 seconds probably is worth a bit of risk for a further
improvement.

Depends on what hardware. I don't think a worst case of 30 seconds for end users is worth more
risks. A worst case of 30 seconds for miners would probably be concerning.

Sure, I'm not super concerned with an RPi. I am concerned with relatively cheap miner hardware, tho.

In addition, although the worst case is important to limit the damage an attacker can do without
being economically rational, what we care about for miners attacking each other is economically
viable attacks. At the moment the optimal "validation time / cost to attacker" ratio is not the
worst case, by a large margin [0].

I believe we should take into account the worst case to miners even if not economically viable for
an attacker as a safety margin. But we should keep in mind this is already overestimating the attack
risk since in this scenario what we should look at is the worst case validation time of blocks that
may have positive returns to an attacker.

Fair enough.

Can you put numbers to this?

Sure. Using my functional test which runs the worst case today and the worst case under various
mitigations [1] on a Dell XPS 15 9520 laptop (the model with an i5-12500H) i get 120 seconds for the
worst case today and 10 seconds for the worst block with a limited of 2500 (potentially) executed
sigops per transaction. To (maybe, they could be running more powerful machines than my laptop)
impose such a validation time to other miners an attacker would have to invest 89 (!!) preparation
blocks. Sure, with low fees the opportunity cost of mining preparation transactions is not as high
as it could be. But still.

Okay! That's a much better outcome than I was thinking. I assume this was with parallelization
across the 4+8 available cores? Do you happen to have numbers handy for the worst-case with, for
example, one block of prep?

Matt

[0] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70 <https://
delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70?u=antoinep>
[1] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/61 <https://
delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/61?u=antoinep>
On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo lf-lists@mattcorallo.com wrote:

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.