From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 10 Feb 2025 09:38:08 -0800 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1thXjS-0005k7-IA for bitcoindev@gnusha.org; Mon, 10 Feb 2025 09:38:08 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-29e8124e922sf7352655fac.2 for ; Mon, 10 Feb 2025 09:38:06 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1739209080; cv=pass; d=google.com; s=arc-20240605; b=kq+h02rPLKv7xx4Nm2JTcYQb6iE/NSjGpZA19iCYz1oeKxOlr9AVx07JapI41DEj10 Lq5gWVTfN9weztTmDEsSnQsuJzi/lrKdT4Fs1GQCTmgLmRPqmo1SujOa4rzO6yOt7ANN +J8RTlCIW8tDBsQqm4NrYWYyu28KLTjVsIG1K3JRwh3GDIodFmIK3QXtQTlYJEVcVks7 xPOqOomzcf42cC6AcYE5Yt6IPhwY4IIO18DGgMQ6U7bD1k1P6cnGauVry9AeOuIliEy0 ALz9u525vVYA0w7gMj6KI+BlUeO4F41pHei3spNlw/Tem3d3OcFyGYwwvGpfNTSduNTP bbtQ== 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=IL4lMXeFe3dZSPkhmuLmgggN0FmYYeptlsSZ2mWp1KA=; fh=GyuCJ8X8XUAfM2Xpp9qQct2vvwCdRoxWiqIxs5R3dA8=; b=NACD1aaDujVTg23HVWx3Hyu10hoqrgsBMh6LASd9Kn26SArSYfQmQ5roSusrWe0fZ7 5MUeRlh8iE45pfW5iYb/esdgiBOO23seixG69dNaqm7vtm5j4aXO6BdbV6iZ19l8cZ2c ZUshF8bgEWYGyTLdJOKIscE9sf/90Jy48titxMitBgEeu0pMjtkiEeDn+myx8QqHWoVj 3KbJnHrFqax+nAIufqnEuNBTIShYhOftcS+h/+XeTipkAr75uFnJpunH9KL/ZqEhd3gs w2TUI5ih06WeP2yptFc8NnB7z1X6BRjJCSYmXs08h5a/DB6yqmUirX3wJ5hEQTCfxmSr 3YEw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=DOvHvfLK; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.134 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=1739209080; x=1739813880; 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=IL4lMXeFe3dZSPkhmuLmgggN0FmYYeptlsSZ2mWp1KA=; b=f7g/UE0oq4e6P5Dh/Yjmt50UYC47XcGGFrKbaZeEkJemf5OhA/CMcwU8nwNDd6mt8V WxJYG5SND620Ox5gi2lNhyh+zj4WOpmJMbTuwKOk2XbejSnjq64Zhx1ai8EDS4A+wDMs WLJCXQmWMZn10HIuyGsao4iXJ4yr45p8tS6+24HF2828LxFRizPXKGhOPt/FV8eeW8A2 bqwxhBHPd9P/xcZY9+r99oLAkyallyAT6NOkVtBx2o5d/lM5gtnERp7GHVJ1DfkEWGEa X7vFCBPo5Zs8sB/pX79LMFACQrGP9nqOLxl5dbjUbzD08N1A8G/F9ky8lEfPWtCCzSDy Vj+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739209080; x=1739813880; 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=IL4lMXeFe3dZSPkhmuLmgggN0FmYYeptlsSZ2mWp1KA=; b=jM9nt6lGu8d6zI0aiyYn6UXQsxdCPwcBezm5vNTwlrs3GvjpeGOxy/x+bgwtyffaPK wkCEowxasF8zSTVYJTm3oewrQVG5Wp363MPP6IlbaI76OMIjodMp05TGVII6ZH2GkZqt R4o3xJq/F9ixhyWZeCrDp5ueLd37tdOIDj3UWfJsdU5QzuqQef3IvElE4B4ae/OTW+fB Sqq33CzbHMtgRXytE7OBoxnNyWE758kMscepBekXhBbNVtJflY+hwOuBMN33EM6XSDMw OyMWHJWTNaYsOoE+RhRjqwMIWN6LCJHKQM3LAo4HU0Wbvx1FhpoZBqDecUSpH4OS+kv9 naXw== X-Forwarded-Encrypted: i=2; AJvYcCVIf4atFLvEwTf93ai/RkpHdh45gs/2c5FbicuAYFZ1+K7cXWn7BXUIwPjVT3WJ4SrbAdNbGU3ez0eP@gnusha.org X-Gm-Message-State: AOJu0Ywv8HgdzddbsCkuK4GVpikaxeT6lVLFUpS2BW8iXBgCJFoXvlyE fCduNQo4baMIlVZbjkVtPoknO/IFeT6m6sUDG5krBojKDo2ckhS8 X-Google-Smtp-Source: AGHT+IEIx/NFhBW3PYf+5rN5of9asOy/it0RHGBOo3JGk+TP3cD9xsqJWMUht2fY8NOh5P0gT+7aRQ== X-Received: by 2002:a05:6871:28d:b0:29f:af5b:ef49 with SMTP id 586e51a60fabf-2b83ec12443mr9891664fac.10.1739209079961; Mon, 10 Feb 2025 09:37:59 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6870:8a20:b0:29f:aff3:65c8 with SMTP id 586e51a60fabf-2b83ba57282ls2094374fac.2.-pod-prod-08-us; Mon, 10 Feb 2025 09:37:57 -0800 (PST) X-Received: by 2002:a05:6808:1782:b0:3eb:651a:6cec with SMTP id 5614622812f47-3f392340992mr10515725b6e.31.1739209077011; Mon, 10 Feb 2025 09:37:57 -0800 (PST) Received: by 2002:a05:6504:c09:b0:287:deb:ad57 with SMTP id a1c4a302cd1d6-28e9eb87dd0msc7a; Mon, 10 Feb 2025 08:28:45 -0800 (PST) X-Received: by 2002:a05:6512:36cb:b0:545:844:42f with SMTP id 2adb3069b0e04-54508440574mr1839065e87.19.1739204922837; Mon, 10 Feb 2025 08:28:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1739204922; cv=none; d=google.com; s=arc-20240605; b=Y0ZdJM0WJJxja95z9zYiT+wd4Bez58it0QyOU2kmqaB6cqC4cJqnQyJj7Neva4oIXj mNx/XWnfZmP7b0xHgTiDv6JYlWXToxMjkrdvB1G0YZvnNv0CCirx567BKlmRJhP1QxjC IXOJXH3DyNpYuvnQSqYCpTWQyUaNt+j+J9farT+rbnFZRH6AmpLBqCpE0SBG6c9U6Dop Ce36z8apa762NJ+mJiMIbRyj8zxlQf5qdP3ttOvYS8WMaZ3iP45W6OYeAGZCmb/HclCT 1EUZcOdAIZoZGGneeggHCBHdik7UHmf8daAPmLNfcPGGKKf8U5pUZuKmmSZHZIw+yP88 Qm+Q== 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=RQ+7aTwf9Ut4EL/GGrw+CaTNzGJXFnqtIf5cYSH0ctQ=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=UEQYcc//NiI5xhf+sZcxKMa+AtN0brE847R8d2vsIhJd2GbrQl4R/zxkkhdfJNcjNU rgzIa4U4GJBenOsVyCdhLs83uCuDz6s+dYPJu3legAOlzpKXTzZZmJZluoAdDY/AbcQF XTA+WV5pmJm8a6KmgsE9Stcd+e/p/31XC9WoZb5mQ+gu/jllW5D1HDCTUEJ6Se5LK70W IQMyd64D/kuZigDmR6KizY6kHoLdjtW+gruLYnapDtJcOPhLFZX9Ybwfz6NkKXi2bbFo PxGci3421TgLmW71pqHfRyz5utbW2h0pVKGMyu7J/kVrwgB6VKhiPnlrWU0S8boun6Qx 6ZwQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=DOvHvfLK; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.134 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch. [185.70.40.134]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-54509d90636si112856e87.10.2025.02.10.08.28.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Feb 2025 08:28:42 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.40.134 as permitted sender) client-ip=185.70.40.134; Date: Mon, 10 Feb 2025 16:28:32 +0000 To: Antoine Riard From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival Message-ID: In-Reply-To: <53c78eb9-2050-46d5-a688-be82846135a4n@googlegroups.com> References: <53c78eb9-2050-46d5-a688-be82846135a4n@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: a68b5de84500a82fc9c7fa82273abb8f41539d8a MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_Y3Iu2WXyJdHItl8v1mSm30Y72x6w24sjW2asHxdPk" 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=DOvHvfLK; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.134 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=_Y3Iu2WXyJdHItl8v1mSm30Y72x6w24sjW2asHxdPk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi "evil" Ariard, I believe it is important to bundle all fixes together to make up for the s= ubstantial fixed cost of deploying a soft fork. It also seems absurd to dep= loy 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 raise= d about the 2019 proposal do not apply to the fix proposed here. The new ap= proach to mitigating the worst case validation time is extremely conservati= ve in this regard: no opcodes or other Script functionality get disabled. O= nly a limit is introduced at the transaction level, which allows to pinpoin= t 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 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 dif= ficulty adjustment >> algorithm. In particular, a fix for the timewarp attack with a 7200 seco= nds 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 sur= face", 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 serializ= e 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 fi= eld 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 di= stinct block nVersion > bit. While BIP-9 recommends a 95% activation threshold on mainnet, it's o= ne line change to > adjust the `nThreshold` variable to another value. For the fix about time= warp 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 ru= les, 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, BIP3= 41 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"/"enh= anced-duplicated-txn", > as adoption of one fix is not necessitated to adopt the other fixes. Ther= e could be some > community consensus on "timewarp"/"merke-tree-weakness"/"enhanced-duplica= ted-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 peop= le who have use-cases > potentially affected. > > For those reasons, I think it's wiser to spread each fix in its own BIP a= nd 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: 6c809fde007a53f380af41f0e22f3b9e95c83da24c2718ac2de0004570f9499= 0 > > 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 >> am looking forward to reading your BIP, and would hope that you could >> share here or in the BIP=E2=80=99s Rationale what convinced you to chang= e the >> grace period from 600 seconds to 7200 seconds and how the nLockTime of >> height-1=E2=80=AFwon 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 Co= nsensus 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, OP_CODESEPARAT= OR and non-standard sighash >>> types fail script validation to mitigate the worst case block validatio= n time; >>> - restrict the nTime field of the first block in each difficulty adjust= ment 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 in= tended 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 Bitc= oin already. >>> >>> Later in March i shared some first findings on Delving [1] and advertiz= ed the effort on this mailing >>> list [2]. I also created a companion thread on Delving, kept private, t= o discuss the details of the >>> worst case block validation time [3]. As one would expect due to the la= rger 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 opini= ons 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 di= fficulty adjustment >>> algorithm. In particular, a fix for the timewarp attack with a 7200 sec= onds 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 su= rface", 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 seriali= ze to exactly 64 bytes >>> invalid. >>> - A fix for duplicate transactions to supplement BIP34 in order to avoi= d resuming unnecessary BIP30 >>> validation in the future. This is achieved by mandating the nLockTime f= ield 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/7f9670b643b7c943a0cc6d2197= d3eabe661050c2/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] https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/10= 62#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/bitcoinde= v/53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.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/= mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv= 6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc%3D%40protonmail.com. --b1=_Y3Iu2WXyJdHItl8v1mSm30Y72x6w24sjW2asHxdPk Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi "evil" A= riard,

= I believe it is important to bundle all fixes together to make up for the s= ubstantial fixed cost of deploying a soft fork. It also seems absurd to dep= loy 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, pleas= e 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 valid= ation time is extremely conservative in this regard: no opcodes or other Sc= ript functionality get disabled. Only a limit is introduced at the transact= ion level, which allows to pinpoint exactly the harmful behaviour without r= endering any innocent transaction invalid.

Best,
Antoine (the non-evil-one?)
=20
=20
=20
On Sunday, February 9th, 2025 at 7:15 PM, Antoine Riard <antoine= .riard@gmail.com> wrote:
Hi Darosior,

Thanks for the work on reviving the Great C= onsensus Cleanup.

> Now i would like to update the broader Bitcoi= n development community on the outcome of this effort.
> I believe a = Consensus 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 with = a 7200 seconds grace period as well
> as a fix for the Murch-Zawy att= ack [4] by making invalid any difficulty adjustment period with a
> n= egative duration.
> - A fix for long block validation times with a mi= nimal "confiscation surface", by introducing a
> per-transaction limi= t on the number of legacy sigops in the inputs.
> - A fix for merkle = tree weaknesses by making transactions which serialize to exactly 64 bytes<= br>> invalid.
> - A fix for duplicate transactions to supplement B= IP34 in order to avoid resuming unnecessary BIP30
> validation in the= future. This is achieved by mandating the nLockTime field of coinbase
&= gt; 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 reco= mmends a 95% activation threshold on mainnet, it's one line change to
ad= just the `nThreshold` variable to another value. For the fix about timewarp= vulnerabilities,
as it's an additional constraint on the validity of mi= ned blocks allowed the current reward
schedule, there could be some relu= ctance in adopting the new consensus rules, and this fix
could deserve a= specific threshold of its own - imho.

Additionally, the proposed so= ft-fork fixes are very different than the 3 set of rules than
have been = activated under the DEPLOYMENT_TAPROOT flag. While BIP340, BIP341 and BIP34= 2 are
building on top of each other in a modular fashion, this is not th= e case here with the 4
proposed fixes ("timewarp"/"worst-block-time"/"me= rkle-tree-weakness"/"enhanced-duplicated-txn",
as adoption of one fix is= not necessitated to adopt the other fixes. There could be some
communit= y consensus on "timewarp"/"merke-tree-weakness"/"enhanced-duplicated-txn", = while
the minimal "confiscation surface" (which was very controversial w= hen the GCC was proposed
the 1st time in 2019), not suiting a wide major= ity 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 BI= P and patchset of
code changes to not only have discussions of each fix = in parallel, though also eventually
enable separate activation of each c= onsensus fix, in the optic that each fix might gather
different level of= consensus, whatever the reasons.

This might be a stylistic note, th= ough I could point in bitcoin core code today implemented
check in the s= cript interpreter right in the crux of consensus code paths that is just st= ale
due to a never-activated BIP (-- yes I'm starring at you SIGPUSHONLY= ).

Best,
Antoine (the "evil" one)

OTS hash: 6c809fde007a53= f380af41f0e22f3b9e95c83da24c2718ac2de0004570f94990

Le jeudi 6 f=C3=A9vrier 20= 25 =C3=A0 21:46:42 UTC, Murch a =C3=A9crit :
Thank you for the update and your work on th= e Great Consensus Cleanup. I
am looking forward to reading your BIP, and would hope that you could
share here or in the BIP=E2=80=99s Rationale what convinced you to chan= ge the
grace period from 600 seconds to 7200 seconds and how the nLockTime of
height-1=E2=80=AFwon 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 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;
>
> 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.
>
> 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.
>
> 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 "confiscati= on 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.
>
> I have started drafting a BIP draft with the detailed specs for th= is.
>
> Antoine Poinsot
>
>
> [0] https://github.= com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX= .mediawiki
> [1] https://delv= ingbitcoin.org/t/great-consensus-cleanup-revival/710
> [2] https:= //groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ
> [3] http= s://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 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= .

--
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/= mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv= 6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc%3D%40protonmail.com.
--b1=_Y3Iu2WXyJdHItl8v1mSm30Y72x6w24sjW2asHxdPk--