From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 09 Feb 2025 16:15:58 -0800 Received: from mail-yw1-f183.google.com ([209.85.128.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1thHSv-0007aq-27 for bitcoindev@gnusha.org; Sun, 09 Feb 2025 16:15:58 -0800 Received: by mail-yw1-f183.google.com with SMTP id 00721157ae682-6f6f2db824bsf41724847b3.3 for ; Sun, 09 Feb 2025 16:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1739146551; x=1739751351; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=DiFM/SO5RIcoaYLgBk2wtwpmgOVXvXmqB7D6NtT+XWU=; b=XqsnXN8jwkepv+2tDrBqglDc2pRy+h5Py/z1mBcR7hHmrfeJoUYYnITafkNMzmmpM4 1ux30u3m9z5PeFNDXR8AW6dDEoY4aRDLy2PCOQDg2EB+K9P6XGXBXSD6XpELXav1CpZ5 JzI1xexhYpHosZ6M6cJQwEOEHJxrbwjpz+p1dZ67KL2V3rxI/sNC6/MtYAnNIl7Wv5h+ XczyDEArtk/8tQFnazn6KrZF3gbqfsdNyyEozWfzS3H1mcrpUXGGkfC7sqhvDVUZ7vm3 3iI90z3JGw0lBGju/EeL15PyQx7lZAwSPeoB6/OFD+Th+5eZn8ZL1fSMyN+BIYsk69UF M3EQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739146551; x=1739751351; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=DiFM/SO5RIcoaYLgBk2wtwpmgOVXvXmqB7D6NtT+XWU=; b=a2XHDieCQ/vcsLzPWsQq9v3kjNFJyErhI/wlU/TOSoscCH/H8V1eD6fB8rkD9DHpLu wg1rdelJJurVbo2XkLhSiaRYdP8NlXAj5WZipm+jbzjKFpyYh0xKiJ9Tk1/Kq2fHkFXm IjUi47QSsB3kmDpUPXOmu95LbsyKDLR5GzMhrdJFZQ5QRgAX3+0ZaNlcC8bbr2EQQ3rA KKS5SAUBnUsts2ZezxxmUiQNCrFnPoZFjxyTwIEOe+Eds/eSjaEN/IyfC8bhysPqBc8o oYUg7Dmye3Y/f4ALRGqlexQ0InSKtCfh0Wzf5ZpiyzgwYLx6Bm3QWimC/ip+wPAbO3iQ WNJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739146551; x=1739751351; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=DiFM/SO5RIcoaYLgBk2wtwpmgOVXvXmqB7D6NtT+XWU=; b=D0RXBUDPSSgSym1GsJKuix/m6JjmwKygmFAwV9Ta7ya/qU9LO0DtlexP9Z8ixeX24r TqY12wKqgG1R3V7052gBPvCkviTZ2EPqHtI7gHHB+3BpZ2nTxxeSe6QEPRfDkN/Q0l7N 8uU4gVF9MfVH2Lqli/WU+4Av4/jO4IosI6tPe0fhcXX4aUcy3IXUtjsyYzDwFSiYn7Ng anLHlQLjpdwtVqu92oqY+H09YWY2ndLwPQI07YG/a6U7th4RpfGHOwII//mRrFwKOOs9 zyafBmBprkLAmbY8YHjwOwePqbRXm063eEUoJ3E3jZm7xPXwZonbbIhu+i3AsnBZcMR0 vpwA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUXim8CTltWJBZURF6vZGzCb/6q3PgEz2enKoQ2t5am8V1KxpQJ84aOHYyeLN+7tOMMsfsDVXoDZKNi@gnusha.org X-Gm-Message-State: AOJu0YxrYvCPHQv2eOqh25+uW434M8p3zjNlSDTcN/mgBZ9aYXA2Vgqr LS/WC3g7SsQmMDf8QUYd25lZ6aZ5kvrqHXDZnFG7L9EUPa5BThlg X-Google-Smtp-Source: AGHT+IFR9jdYZdDtXrxnB1GU+H9swTKivM0iklf6RXBiYwp09jeZQW0T6EdQfOoXBmowyXg7lRMfjA== X-Received: by 2002:a05:6902:1246:b0:e54:9cb1:21a6 with SMTP id 3f1490d57ef6-e5b4618a4e5mr8354738276.11.1739146551059; Sun, 09 Feb 2025 16:15:51 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:abab:0:b0:e5b:3adb:a133 with SMTP id 3f1490d57ef6-e5b46087877ls574041276.1.-pod-prod-03-us; Sun, 09 Feb 2025 16:15:47 -0800 (PST) X-Received: by 2002:a05:690c:9989:b0:6ef:6a71:aa55 with SMTP id 00721157ae682-6f9b2345b63mr104776317b3.0.1739146547245; Sun, 09 Feb 2025 16:15:47 -0800 (PST) Received: by 2002:a05:690c:4448:b0:6f9:a930:a709 with SMTP id 00721157ae682-6f9b1de8b9ams7b3; Fri, 7 Feb 2025 05:02:49 -0800 (PST) X-Received: by 2002:a05:690c:6c02:b0:6f9:938a:57a2 with SMTP id 00721157ae682-6f9b2802027mr27049957b3.1.1738933366508; Fri, 07 Feb 2025 05:02:46 -0800 (PST) Date: Fri, 7 Feb 2025 05:02:46 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <53c78eb9-2050-46d5-a688-be82846135a4n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_53614_404128117.1738933366152" X-Original-Sender: antoine.riard@gmail.com 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: -0.5 (/) ------=_Part_53614_404128117.1738933366152 Content-Type: multipart/alternative; boundary="----=_Part_53615_1853040815.1738933366152" ------=_Part_53615_1853040815.1738933366152 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Darosior, Thanks for the work on reviving the Great Consensus Cleanup. > Now i would like to update the broader Bitcoin development community on= =20 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=20 difficulty adjustment > algorithm. In particular, a fix for the timewarp attack with a 7200=20 seconds grace period as well > as a fix for the Murch-Zawy attack [4] by making invalid any difficulty= =20 adjustment period with a > negative duration. > - A fix for long block validation times with a minimal "confiscation=20 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= =20 to exactly 64 bytes > invalid. > - A fix for duplicate transactions to supplement BIP34 in order to avoid= =20 resuming unnecessary BIP30 > validation in the future. This is achieved by mandating the nLockTime=20 field of coinbase > transaction to be set to the height of their block minus 1. >=20 > 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= =20 multiple soft-forks activation at the same time (up to 30), as a soft-fork can be assigned=20 distinct block nVersion=20 bit. While BIP-9 recommends a 95% activation threshold on mainnet, it's one= =20 line change to adjust the `nThreshold` variable to another value. For the fix about=20 timewarp vulnerabilities, as it's an additional constraint on the validity of mined blocks allowed=20 the current reward schedule, there could be some reluctance in adopting the new consensus=20 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=20 set of rules than have been activated under the DEPLOYMENT_TAPROOT flag. While BIP340, BIP341= =20 and BIP342 are building on top of each other in a modular fashion, this is not the case=20 here with the 4 proposed fixes=20 ("timewarp"/"worst-block-time"/"merkle-tree-weakness"/"enhanced-duplicated-= txn", as adoption of one fix is not necessitated to adopt the other fixes. There= =20 could be some community consensus on=20 "timewarp"/"merke-tree-weakness"/"enhanced-duplicated-txn", while the minimal "confiscation surface" (which was very controversial when the= =20 GCC was proposed the 1st time in 2019), not suiting a wide majority of folks, or even people= =20 who have use-cases potentially affected. For those reasons, I think it's wiser to spread each fix in its own BIP and= =20 patchset of code changes to not only have discussions of each fix in parallel, though= =20 also eventually enable separate activation of each consensus fix, in the optic that each=20 fix might gather different level of consensus, whatever the reasons. This might be a stylistic note, though I could point in bitcoin core code= =20 today implemented check in the script interpreter right in the crux of consensus code paths= =20 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=C3=A9vrier 2025 =C3=A0 21:46:42 UTC, Murch a =C3=A9crit : > Thank you for the update and your work on the Great Consensus Cleanup. I= =20 > am looking forward to reading your BIP, and would hope that you could=20 > share here or in the BIP=E2=80=99s Rationale what convinced you to change= the=20 > grace period from 600 seconds to 7200 seconds and how the nLockTime of=20 > height-1=E2=80=AFwon out. > > Cheers, > Murch > > On 2025-02-05 13:09, 'Antoine Poinsot' via Bitcoin Development Mailing=20 > List wrote: > > Hi everyone, > >=20 > > A bit over a year ago i started working on revisiting the 2019 Great=20 > Consensus Cleanup proposal from > > Matt Corallo [0]. His proposal included: > > - making <=3D64 bytes transactions invalid to fix merkle tree weaknesse= s; > > - making non-pushonly scriptSigs, FindAndDelete matches,=20 > OP_CODESEPARATOR and non-standard sighash > > types fail script validation to mitigate the worst case block validatio= n=20 > time; > > - restrict the nTime field of the first block in each difficulty=20 > adjustment interval to be no less > > than 600 seconds lower than the previous block's; > >=20 > > I set out to research the impact of each of the vulnerabilities this=20 > intended to patch, the > > alternative fixes possible for each and finally if there was any other= =20 > protocol bug fix we'd want to > > include if we went through the considerable effort of soft forking=20 > Bitcoin already. > >=20 > > Later in March i shared some first findings on Delving [1] and=20 > advertized the effort on this mailing > > list [2]. I also created a companion thread on Delving, kept private, t= o=20 > discuss the details of the > > worst case block validation time [3]. As one would expect due to the=20 > larger design space available > > to fix this issue, this private thread is where most of the discussion= =20 > would happen. Thank you to > > everyone who contributed feedback, insights, ideas and argumented=20 > opinions on the different issues > > all along the process. > >=20 > > Now i would like to update the broader Bitcoin development community on= =20 > 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=20 > difficulty adjustment > > algorithm. In particular, a fix for the timewarp attack with a 7200=20 > seconds grace period as well > > as a fix for the Murch-Zawy attack [4] by making invalid any difficulty= =20 > adjustment period with a > > negative duration. > > - A fix for long block validation times with a minimal "confiscation=20 > 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=20 > serialize to exactly 64 bytes > > invalid. > > - A fix for duplicate transactions to supplement BIP34 in order to avoi= d=20 > resuming unnecessary BIP30 > > validation in the future. This is achieved by mandating the nLockTime= =20 > field of coinbase > > transaction to be set to the height of their block minus 1. > >=20 > > I have started drafting a BIP draft with the detailed specs for this. > >=20 > > Antoine Poinsot > >=20 > >=20 > > [0]=20 > https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe= 661050c2/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/71= 1 > > [4]=20 > https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#var= iant-on-zawys-attack-2 > >=20 > > --=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/= 53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.com. ------=_Part_53615_1853040815.1738933366152 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Darosior,

Thanks for the work on reviving the Great Consensus= Cleanup.

> Now i would like to update the broader Bitcoin de= velopment community on the outcome of this effort.
> I believe a Co= nsensus Cleanup proposal should include the following.
> - A fix fo= r vulnerabilities surrounding the use of timestamps in the difficulty adjus= tment
> algorithm. In particular, a fix for the timewarp attack wit= h 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 w= ith a minimal "confiscation surface", by introducing a
> per-transa= ction limit on the number of legacy sigops in the inputs.
> - A fix= for merkle tree weaknesses by making transactions which serialize to exact= ly 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 fiel= d 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 BI= P-9-based deployment, there can be multiple soft-forks
activation at t= he same time (up to 30), as a soft-fork can be assigned distinct block nVer= sion
bit. While BIP-9 recommends a 95% activation threshold on mainne= t, it's one line change to
adjust the `nThreshold` variable to another= value. For the fix about timewarp vulnerabilities,
as it's an additio= nal constraint on the validity of mined blocks allowed the current rewardschedule, there could be some reluctance in adopting the new consensus = rules, and this fix
could deserve a specific threshold of its own - im= ho.

Additionally, the proposed soft-fork fixes are very differen= t than the 3 set of rules than
have been activated under the DEPLOYMEN= T_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"/"enha= nced-duplicated-txn",
as adoption of one fix is not necessitated to ad= opt the other fixes. There could be some
community consensus on "timew= arp"/"merke-tree-weakness"/"enhanced-duplicated-txn", while
the minima= l "confiscation surface" (which was very controversial when the GCC was pro= posed
the 1st time in 2019), not suiting a wide majority of folks, or = even people who have use-cases
potentially affected.

For th= ose reasons, I think it's wiser to spread each fix in its own BIP and patch= set of
code changes to not only have discussions of each fix in parall= el, though also eventually
enable separate activation of each consensu= s fix, in the optic that each fix might gather
different level of cons= ensus, whatever the reasons.

This might be a stylistic note, tho= ugh 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 s= tale
due to a never-activated BIP (-- yes I'm starring at you SIGPUSHO= NLY).

Best,
Antoine (the "evil" one)

OTS hash: 6= c809fde007a53f380af41f0e22f3b9e95c83da24c2718ac2de0004570f94990

=
Le jeudi = 6 f=C3=A9vrier 2025 =C3=A0 21:46:42 UTC, Murch a =C3=A9crit=C2=A0:
Thank you for the upd= ate and your work on the Great Consensus Cleanup. I=20
am looking forward to reading your BIP, and would hope that you could= =20
share here or in the BIP=E2=80=99s Rationale what convinced you to chan= ge the=20
grace period from 600 seconds to 7200 seconds and how the nLockTime of= =20
height-1=E2=80=AFwon out.

Cheers,
Murch

On 2025-02-05 13:09, 'Antoine Poinsot' via Bitcoin Development = Mailing=20
List wrote:
> Hi everyone,
>=20
> A bit over a year ago i started working on revisiting the 2019 Gre= at Consensus Cleanup proposal from
> Matt Corallo [0]. His proposal included:
> - making <=3D64 bytes transactions invalid to fix merkle tree w= eaknesses;
> - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESE= PARATOR and non-standard sighash
> types fail script validation to mitigate the worst case block v= alidation time;
> - restrict the nTime field of the first block in each difficulty a= djustment interval to be no less
> than 600 seconds lower than the previous block's;
>=20
> I set out to research the impact of each of the vulnerabilities th= is intended to patch, the
> alternative fixes possible for each and finally if there was any o= ther protocol bug fix we'd want to
> include if we went through the considerable effort of soft forking= Bitcoin already.
>=20
> Later in March i shared some first findings on Delving [1] and adv= ertized the effort on this mailing
> list [2]. I also created a companion thread on Delving, kept priva= te, to discuss the details of the
> worst case block validation time [3]. As one would expect due to t= he larger design space available
> to fix this issue, this private thread is where most of the discus= sion would happen. Thank you to
> everyone who contributed feedback, insights, ideas and argumented = opinions on the different issues
> all along the process.
>=20
> Now i would like to update the broader Bitcoin development communi= ty on the outcome of this effort.
> I believe a Consensus Cleanup proposal should include the followin= g.
> - A fix for vulnerabilities surrounding the use of timestamps in t= he 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 di= fficulty adjustment period with a
> negative duration.
> - A fix for long block validation times with a minimal "confi= scation surface", by introducing a
> per-transaction limit on the number of legacy sigops in the inp= uts.
> - A fix for merkle tree weaknesses by making transactions which se= rialize 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 nLo= ckTime field of coinbase
> transaction to be set to the height of their block minus 1.
>=20
> I have started drafting a BIP draft with the detailed specs for th= is.
>=20
> Antoine Poinsot
>=20
>=20
> [0] https://github.com/TheBlueMatt/bips= /blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
> [1] https://delvingbitcoin.org/t/gre= at-consensus-cleanup-revival/710
> [2] https://groups.google.co= m/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ
> [3] https://delvingbitcoin.= org/t/worst-block-validation-time-inquiry/711
> [4] https://delvingbitcoin.org/t/zawy-s-altern= ating-timestamp-attack/1062#variant-on-zawys-attack-2
>=20

--
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/bitcoind= ev/53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.com.
------=_Part_53615_1853040815.1738933366152-- ------=_Part_53614_404128117.1738933366152--