From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 27 Feb 2025 18:41:15 -0800 Received: from mail-qt1-f187.google.com ([209.85.160.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tnqJN-0004qg-LV for bitcoindev@gnusha.org; Thu, 27 Feb 2025 18:41:15 -0800 Received: by mail-qt1-f187.google.com with SMTP id d75a77b69052e-472107c4b5esf31496411cf.1 for ; Thu, 27 Feb 2025 18:41:13 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1740710468; cv=pass; d=google.com; s=arc-20240605; b=fcY68ipxIYI2blhBhPsZ+82r22W7VuuVssZq/0cpvWVMRk5mEjI80DSU/3G3jn29Hw W5clUK2pJGBGU/rVwrMwB/qkv3DXfl2CE4w9SjtqOG6uNwwAGFDKqEJCtzu8kE6BdhS+ WZnc7ItIqbC8+9giJWKxhw88eVdK4u7PfO4dMZJy0erYpDOqCdqt8hN3PitdwUdH+jRL IHrLvjcqsmpqkdKtl8PWg2PGtH0JsvYf9MYgogwuASvygIZfrDZT4lvWzquvk7SS+jTG dkRUXKw67WLTgWrDB2ZLp6auNXSnYNOKEoRR4xrESTGxYx+KiKxq1BdDbCZPaxsEL7XH 2ARQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=Cf2ez/1Q9wx0up2EFIec7+jPK4bfhA2KbUFHFBz/Bx8=; fh=nfbBokmQJyeaxYN1cme6klSfBH5qKeCXYQduRG1iiV8=; b=IDTY/vFE8wyBWJl4j+Wi+6Rq4lzLJQwZ73BHwV7H8F6jl3VOvyFbIad2b2NEc3M+0T ChxtRac955or6r9ZGPfEA3Zy/YykkoIzzGhA30F7xCUrD7+wIJ4eBBkA3MAdqlX+h404 Vw3yQ9V8px8VjXnPguMFxMSUI9H71n/FAQBNqQ+ZTeGBM0eEdkGTmCu2nFiRncKzzCsC sN0rxoFwcUPd8wGY4A0bWKNojaFYiMZe7RJc0yjOEWPB9ZHGG4E+UGfS+J6KKpQlIXYi r4IJS0zcCkacNlGMpMwKRPgdZ+fzIMZ/r7X4+3xiaUyEmQIuRELk1lKAQxPYuFD3502z 2oFg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=leSKFpNk; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1740710468; x=1741315268; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=Cf2ez/1Q9wx0up2EFIec7+jPK4bfhA2KbUFHFBz/Bx8=; b=upGWUIhIgdg5MQGZklieA4vwwRNhREJ1h88trsw89NH+jTig5XNr1jEZDYVLZgYgkJ p1E/huXUmdTQEKIjdSZmm2+t87kzZpMu1BEs4LybJa9fiNwT23N38K7ckxXvFNGBR41Q i0WwyuhMM9TbCZdKiNghxal3yfIy1tSx+JgJYhbzPjgbZ5coTM0ASiiiLTpdEw/MMucK 5dR0bK8CiKVUNQIvaOAfYQI17bbRivSy+qL9AuMnFiozxMktzxr9UJwMsfvGwOWoBoXs UOAjJnWNNPMOUzniwjjd/nrDxog/xvfthniukx0dBMHIBUzOQpJJWITdiqMCSoLAoOXS e3aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740710468; x=1741315268; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Cf2ez/1Q9wx0up2EFIec7+jPK4bfhA2KbUFHFBz/Bx8=; b=k0dfWtB/QKBiSSJTOoPMSeaLJOsY5/MLNGboH4zkFmtTv/a+zxiAED7si1nHXrBmv3 U3SbWrEkPslzBZFXeOV2qCZwa/g2z13bjIebtlyv/fjIPvZNIyaBej5Vw4diFeUd7DZM 0mN5AhJPgg+K+eadut9hD4FBy+vKjxtHvYHoK6UaPhP6ZVJiZaA6lUA1XtzMLyIiLRZ6 uUUVpeVmdXHZWk9CakdLKJ93aje1ge/MWJHG3fO/E2oBj3YRAyY19cg64JuqtWcHIpJM qOnYVL7HdKiNyZa7JaXP41W+fT71wIixqD5q3OulVP9Zda4cjxAWTIKf1D/Q+ZjLzkU9 2vZg== X-Forwarded-Encrypted: i=2; AJvYcCW6xPfNXNljVPIHEOPQ7R34sAiDqLSZJR+3LPXaL+zqQHixWHoNjsyJGXv88abNTZkMhpCrE2NAimgw@gnusha.org X-Gm-Message-State: AOJu0Yye8YW7GTsVl9tIt+nYkocGr3VVrmD38YE8r7qgNi59FQbnZ2DZ t734SdbKtPdy1KJ9Z5kpUEWR4AMODlCO2h83B+BHQNJaovTisSnC X-Google-Smtp-Source: AGHT+IEQ4VqIJBpt6tSsuuGwVK00s/WEsT5o5rExzNiJXJYFE7dzpMEKMvxffItyC2UQm1wv7zQt4A== X-Received: by 2002:a05:622a:20b:b0:471:f9bc:fe53 with SMTP id d75a77b69052e-473e55b6a2cmr97988631cf.26.1740710467582; Thu, 27 Feb 2025 18:41:07 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGkCSpve9Cjqatr3LJ1VFp8FLYVVdO96s0HQ7T4SypNvQ== Received: by 2002:a05:622a:153:b0:471:b736:6cc1 with SMTP id d75a77b69052e-473ced96a3als31359351cf.1.-pod-prod-00-us; Thu, 27 Feb 2025 18:41:04 -0800 (PST) X-Received: by 2002:a05:620a:44c2:b0:7c0:770a:d19 with SMTP id af79cd13be357-7c39bbf597emr340014385a.8.1740710464220; Thu, 27 Feb 2025 18:41:04 -0800 (PST) Received: by 2002:a05:600c:1391:b0:439:96ac:b8c8 with SMTP id 5b1f17b1804b1-43abe2e3f6fms5e9; Thu, 27 Feb 2025 09:23:17 -0800 (PST) X-Received: by 2002:a05:600c:1c93:b0:439:a1ef:c238 with SMTP id 5b1f17b1804b1-43ba6704511mr268155e9.13.1740676995531; Thu, 27 Feb 2025 09:23:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1740676995; cv=none; d=google.com; s=arc-20240605; b=NC2YepJdNyMJuHTeMivF2bNm27bHW5nZ7x0nAUeamA+GJZfyJVn9WZJOvuYQFkxMA4 13gWpSjrzyjjJEkbOyCyGgvIa3ft4nf7s8MGO9WuPhTtdxpVx8CWRjPpLrGOmsfQR3cy HhoKUwXAfm+8ioT8voENU0jRI102F8AfG3CVzT+BOpHWgkSypV6fuuEzXGpCvrk1GCZB 70+DjoxFk348DP8G7gnB37T9wNg8Tn73ufpcw21A5jMSEf7g3xeqdhEhuzbRonGJPmkw Ayrw6ytVFTfFYc9BOQG3mITFkhXvtvx6kw7GndG6t2MpRHoA/XmsxtOCE4hWQKUJn5sC ONoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=hqjnCOI3DQ3WsLEg7UTixKrNC8tTqRGYOCOq1IfSAWQ=; fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=; b=JpfHKatsWpIuZm7lG1+xeDNOAgAtrFFNCIqhrw/PMZMSbXCnlelY3DfQJceDwbf2xP ansGuI8wrOXySP4EXtgwImdAJHWQcZDRWF/ONsrGaX1jRiIbGdEw7tKO1CN59RVwze7C TiiReNecm84HJ2iq65oCVa5fCBwuyFin4FWx2wQelTAzxhKLmHHkDtBxZ1mMkQid/3za 35woi1AVVQ9olQ48Hmb0OrVOEIIsdPT/1+OawCWwt4nQ0sx2w0wNaV+gaVWYL48vVupM w1FNQJkgzuz+1fFVx6/aNcrqcRDPZqRMTyF2jrhpCqqJtM9jmRpWnQSW0Y04dF/VVOiY GjXw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=leSKFpNk; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-43ab374a2adsi4630315e9.1.2025.02.27.09.23.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2025 09:23:15 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16; Date: Thu, 27 Feb 2025 17:23:10 +0000 To: Matt Corallo From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival Message-ID: In-Reply-To: <58247311-171f-4228-8db9-53363f764880@mattcorallo.com> References: <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com> <58247311-171f-4228-8db9-53363f764880@mattcorallo.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: fb290c5c557e759d966443e74dff4a4da0a8a769 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_j0kvk0HCUh1GXndNxVuumohPA7L9qH6MoQPwuhT6bI" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=leSKFpNk; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_j0kvk0HCUh1GXndNxVuumohPA7L9qH6MoQPwuhT6bI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Okay! That's a much better outcome than I was thinking. I assume this was= with parallelization > across the 4+8 available cores? Yes, this is using all 16-1 threads. > Do you happen to have numbers handy for the worst-case with, forexample, = one block of prep? The validation cost with the mitigation is proportional to the number of pr= eparation blocks [0]. So the validation time for one block prep the runtime= should be about 112ms. As an another point of comparison the worst case using Taproot presents abo= ut the same validation cost as the worst case with legacy with my proposed = mitigation and about 6 or 7 preparation blocks. Except for Taproot it does = not need any preparation block and the operations cannot be parallelized. Antoine [0] See the graph in this message in the private thread: [https://delvingbi= tcoin.org/t/worst-block-validation-time-inquiry/711/70](https://delvingbitc= oin.org/t/worst-block-validation-time-inquiry/711/70?u=3Dantoinep). On Wednesday, February 26th, 2025 at 2:11 PM, Matt Corallo lf-lists@mattcor= allo.com wrote: > On 2/23/25 5:35 PM, Antoine Poinsot wrote: > >> A 40x decrease to a validation time of 30 seconds probably is worth a bi= t of risk for a further >> improvement. >> >> Depends on what hardware. I don't think a worst case of 30 seconds for e= nd users is worth more >> risks. A worst case of 30 seconds for miners would probably be concernin= g. > > 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 eac= h other is economically >> viable attacks. At the moment the optimal "validation time / cost to att= acker" 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 n= ot economically viable for >> an attacker as a safety margin. But we should keep in mind this is alrea= dy overestimating the attack >> risk since in this scenario what we should look at is the worst case val= idation 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 w= orst case under various >> mitigations [1] on a Dell XPS 15 9520 laptop (the model with an i5-12500= H) i get 120 seconds for the >> worst case today and 10 seconds for the worst block with a limited of 25= 00 (potentially) executed >> sigops per transaction. To (maybe, they could be running more powerful m= achines 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 t= ransactions 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 t= he worst-case with, for > example, one block of prep? > > Matt > >> [0] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711= /70 > delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70?u=3Danto= inep> >> [1] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711= /61 > delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/61?u=3Danto= inep> >> On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo lf-lists@mattc= orallo.com wrote: >> >>> In the delving post you said =E2=80=9CThis provides a 40x decrease in t= he 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.=E2=80=9D >>> >>> Can you put numbers to this? How long does it take to validate a full b= lock 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 b= it 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 Ma= iling List >>>> bitcoindev@googlegroups.com wrote: >>>> >>>> Hi everyone, >>>> >>>> A bit over a year ago i started working on revisiting the 2019 Great C= onsensus Cleanup proposal from >>>> Matt Corallo [0]. His proposal included: >>>> - making <=3D64 bytes transactions invalid to fix merkle tree weakness= es; >>>> - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARA= TOR and non-standard sighash >>>> types fail script validation to mitigate the worst case block validati= on time; >>>> - restrict the nTime field of the first block in each difficulty adjus= tment 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 i= ntended 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 Bit= coin already. >>>> >>>> Later in March i shared some first findings on Delving [1] and adverti= zed 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 l= arger 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 opin= ions on the different issues >>>> all along the process. >>>> >>>> Now i would like to update the broader Bitcoin development community o= n 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 d= ifficulty adjustment >>>> algorithm. In particular, a fix for the timewarp attack with a 7200 se= conds grace period as well >>>> as a fix for the Murch-Zawy attack [4] by making invalid any difficult= y adjustment period with a >>>> negative duration. >>>> - A fix for long block validation times with a minimal "confiscation s= urface", 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 serial= ize to exactly 64 bytes >>>> invalid. >>>> - A fix for duplicate transactions to supplement BIP34 in order to avo= id 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/7f9670b643b7c943a0cc6d219= 7d3eabe661050c2/bip- >>>> XXXX.mediawiki >>>> [1] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 >>>> [2] https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAA= J >>>> [3] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/7= 11 >>>> [4] https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1= 062#variant-on-zawys-attack-2 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Gro= ups "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/bitcoi= ndev/ >>>> jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOC= G0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40protonmail.com. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= ew40Tlhu4YmctmFLj3YtwQ_6qxYCUr_uZFfZtfFl-n-noA9mCZh0jZviy_gJDbY8AsS3jOnjFRC= KnouaEzv-DJ_KqMW0BfFeYe679s_JZaM%3D%40protonmail.com. --b1=_j0kvk0HCUh1GXndNxVuumohPA7L9qH6MoQPwuhT6bI Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay! Tha= t's a much better outcome than I was thinking. I assume this was with paral= lelization
across the 4+8 available cores?

Yes, this is using all 16-1 threads.

Do you happen to have numbers handy for= the worst-case with, for
example, one block of prep?

The validation cost with the mitigation is proportional to the number o= f preparation blocks [0]. So the validation time for one block prep the run= time should be about 112ms.

As an another point of comparison the worst case using= Taproot presents about the same validation cost as the worst case with leg= acy with my proposed mitigation and about 6 or 7 preparation blocks. Except= for Taproot it does not need any preparation block and the operations cann= ot be parallelized.

Antoine
=20
=20
=20

[0] See the graph in this message in the private thread: https://de= lvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70.


On Wednesday, February 26th, 2025 at 2:11 PM, Matt Corallo lf-lists@mattcorallo.com wrote:

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

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

Depends on what hardware. I don't think a worst case of 30 seconds for e= nd users is worth more
risks. A worst case of 30 seconds for miners would probably be concerning.<= /p>

Sure, I'm not super concerned with an RPi. I am concerned with relativel= y 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 o= ther is economically
viable attacks. At the moment the optimal "validation time / cost to attack= er" 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 n= ot 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 valida= tion 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 w= orst 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 mach= ines than my laptop)
impose such a validation time to other miners an attacker would have to inv= est 89 (!!) preparation
blocks. Sure, with low fees the opportunity cost of mining preparation tran= sactions is not as high
as it could be. But still.

Okay! That's a much better outcome than I was thinking. I assume this wa= s 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-in= quiry/711/70 <https://
delvingbitcoin.org/t/worst-block-validation-time-inqui= ry/711/70?u=3Dantoinep>
[1] https://delvingbitcoin.org/t/worst-block-validation-time-inqui= ry/711/61 <https://
delvingbitcoin.org/t/worst-block-validation-time-inqui= ry/711/61?u=3Dantoinep>
On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo lf-lists@mattcorallo.com wrote:

In the delving post you said =E2=80=9CThis provides a 40x decrease in th= e 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 wort= h the additional
confiscatory surface.=E2=80=9D

Can you put numbers to this? How long does it take to validate a full bl= ock 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 bi= t 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 Mail= ing List
bitcoindev@googlegroups.com<= /a> wrote:

Hi everyone,

A bit over a year ago i started working on revisiting the 2019 Great Con= sensus Cleanup proposal from
Matt Corallo [0]. His proposal included:
- making <=3D64 bytes transactions invalid to fix merkle tree weaknesses= ;
- making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARATOR a= nd non-standard sighash
types fail script validation to mitigate the worst case block validation ti= me;
- 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 int= ended to patch, the
alternative fixes possible for each and finally if there was any other prot= ocol 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 advertize= d the effort on this mailing
list [2]. I also created a companion thread on Delving, kept private, to di= scuss 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 woul= d 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 diffic= ulty 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 adj= ustment period with a
negative duration.
- A fix for long block validation times with a minimal "confiscation surfac= e", 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 t= o exactly 64 bytes
invalid.
- A fix for duplicate transactions to supplement BIP34 in order to avoid re= suming 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/7f9= 670b643b7c943a0cc6d2197d3eabe661050c2/bip-
XXXX.mediawiki
[1] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710<= br> [2] https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAA= J
[3] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/= 711
[4] https://delvingbitcoin.org/t/zawy-s-al= ternating-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 e= mail to
bitcoindev+unsub= scribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/
jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_W= Iz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40p= rotonmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= ew40Tlhu4YmctmFLj3YtwQ_6qxYCUr_uZFfZtfFl-n-noA9mCZh0jZviy_gJDbY8AsS3jOnjFRC= KnouaEzv-DJ_KqMW0BfFeYe679s_JZaM%3D%40protonmail.com.
--b1=_j0kvk0HCUh1GXndNxVuumohPA7L9qH6MoQPwuhT6bI--