path: root/fa/51b095ab2584d66074cf764b2a464e76f3d5c6

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 <bitcoindev+bncBDL4XL646QOBB5PSVC6QMGQEZXC7Q3Q@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <antoine.riard@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
Message-ID: <mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=@protonmail.com>
In-Reply-To: <53c78eb9-2050-46d5-a688-be82846135a4n@googlegroups.com>
References: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com> <ff82fe21-8e02-42df-8760-c3e358a12766@murch.one> <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 <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <antoine.riard@gmai=
l.com> 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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hi "evil" A=
riard,</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;"=
><br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">=
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.</div><div style=3D"font-family: Ar=
ial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Ari=
al, sans-serif; font-size: 14px;">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.</div><div style=3D"font-family: =
Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px;">Best,<br>Antoine (the non-evil-one?)<br=
></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div class=3D"protonmail_quote">
        On Sunday, February 9th, 2025 at 7:15 PM, Antoine Riard &lt;antoine=
.riard@gmail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            Hi Darosior,<br><br>Thanks for the work on reviving the Great C=
onsensus Cleanup.<br><br>&gt; Now i would like to update the broader Bitcoi=
n development community on the outcome of this effort.<br>&gt; I believe a =
Consensus Cleanup proposal should include the following.<br>&gt; - A fix fo=
r vulnerabilities surrounding the use of timestamps in the difficulty adjus=
tment<br>&gt; algorithm. In particular, a fix for the timewarp attack with =
a 7200 seconds grace period as well<br>&gt; as a fix for the Murch-Zawy att=
ack [4] by making invalid any difficulty adjustment period with a<br>&gt; n=
egative duration.<br>&gt; - A fix for long block validation times with a mi=
nimal "confiscation surface", by introducing a<br>&gt; per-transaction limi=
t on the number of legacy sigops in the inputs.<br>&gt; - A fix for merkle =
tree weaknesses by making transactions which serialize to exactly 64 bytes<=
br>&gt; invalid.<br>&gt; - A fix for duplicate transactions to supplement B=
IP34 in order to avoid resuming unnecessary BIP30<br>&gt; validation in the=
 future. This is achieved by mandating the nLockTime field of coinbase<br>&=
gt; transaction to be set to the height of their block minus 1.<br>&gt; <br=
>&gt; I have started drafting a BIP draft with the detailed specs for this.=
<br><br>So assuming some hypothetical future BIP-9-based deployment, there =
can be multiple soft-forks<br>activation at the same time (up to 30), as a =
soft-fork can be assigned distinct block nVersion <br>bit. While BIP-9 reco=
mmends a 95% activation threshold on mainnet, it's one line change to<br>ad=
just the `nThreshold` variable to another value. For the fix about timewarp=
 vulnerabilities,<br>as it's an additional constraint on the validity of mi=
ned blocks allowed the current reward<br>schedule, there could be some relu=
ctance in adopting the new consensus rules, and this fix<br>could deserve a=
 specific threshold of its own - imho.<br><br>Additionally, the proposed so=
ft-fork fixes are very different than the 3 set of rules than<br>have been =
activated under the DEPLOYMENT_TAPROOT flag. While BIP340, BIP341 and BIP34=
2 are<br>building on top of each other in a modular fashion, this is not th=
e case here with the 4<br>proposed fixes ("timewarp"/"worst-block-time"/"me=
rkle-tree-weakness"/"enhanced-duplicated-txn",<br>as adoption of one fix is=
 not necessitated to adopt the other fixes. There could be some<br>communit=
y consensus on "timewarp"/"merke-tree-weakness"/"enhanced-duplicated-txn", =
while<br>the minimal "confiscation surface" (which was very controversial w=
hen the GCC was proposed<br>the 1st time in 2019), not suiting a wide major=
ity of folks, or even people who have use-cases<br>potentially affected.<br=
><br>For those reasons, I think it's wiser to spread each fix in its own BI=
P and patchset of<br>code changes to not only have discussions of each fix =
in parallel, though also eventually<br>enable separate activation of each c=
onsensus fix, in the optic that each fix might gather<br>different level of=
 consensus, whatever the reasons.<br><br>This might be a stylistic note, th=
ough I could point in bitcoin core code today implemented<br>check in the s=
cript interpreter right in the crux of consensus code paths that is just st=
ale<br>due to a never-activated BIP (-- yes I'm starring at you SIGPUSHONLY=
).<br><br>Best,<br>Antoine (the "evil" one)<br><br>OTS hash: 6c809fde007a53=
f380af41f0e22f3b9e95c83da24c2718ac2de0004570f94990<br><br><div class=3D"gma=
il_quote"><div class=3D"gmail_attr" dir=3D"auto">Le jeudi 6 f=C3=A9vrier 20=
25 =C3=A0 21:46:42 UTC, Murch a =C3=A9crit :<br></div><blockquote style=3D"=
margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-lef=
t: 1ex;" class=3D"gmail_quote">Thank you for the update and your work on th=
e Great Consensus Cleanup. I
<br>am looking forward to reading your BIP, and would hope that you could
<br>share here or in the BIP=E2=80=99s Rationale what convinced you to chan=
ge the
<br>grace period from 600 seconds to 7200 seconds and how the nLockTime of
<br>height-1=E2=80=AFwon out.
<br>
<br>Cheers,
<br>Murch
<br>
<br>On 2025-02-05 13:09, 'Antoine Poinsot' via Bitcoin Development Mailing
<br>List wrote:
<br>&gt; Hi everyone,
<br>&gt;
<br>&gt; A bit over a year ago i started working on revisiting the 2019 Gre=
at Consensus Cleanup proposal from
<br>&gt; Matt Corallo [0]. His proposal included:
<br>&gt; - making &lt;=3D64 bytes transactions invalid to fix merkle tree w=
eaknesses;
<br>&gt; - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESE=
PARATOR and non-standard sighash
<br>&gt;    types fail script validation to mitigate the worst case block v=
alidation time;
<br>&gt; - restrict the nTime field of the first block in each difficulty a=
djustment interval to be no less
<br>&gt;    than 600 seconds lower than the previous block's;
<br>&gt;
<br>&gt; I set out to research the impact of each of the vulnerabilities th=
is intended to patch, the
<br>&gt; alternative fixes possible for each and finally if there was any o=
ther protocol bug fix we'd want to
<br>&gt; include if we went through the considerable effort of soft forking=
 Bitcoin already.
<br>&gt;
<br>&gt; Later in March i shared some first findings on Delving [1] and adv=
ertized the effort on this mailing
<br>&gt; list [2]. I also created a companion thread on Delving, kept priva=
te, to discuss the details of the
<br>&gt; worst case block validation time [3]. As one would expect due to t=
he larger design space available
<br>&gt; to fix this issue, this private thread is where most of the discus=
sion would happen. Thank you to
<br>&gt; everyone who contributed feedback, insights, ideas and argumented =
opinions on the different issues
<br>&gt; all along the process.
<br>&gt;
<br>&gt; Now i would like to update the broader Bitcoin development communi=
ty on the outcome of this effort.
<br>&gt; I believe a Consensus Cleanup proposal should include the followin=
g.
<br>&gt; - A fix for vulnerabilities surrounding the use of timestamps in t=
he difficulty adjustment
<br>&gt;    algorithm.  In particular, a fix for the timewarp attack with a=
 7200 seconds grace period as well
<br>&gt;    as a fix for the Murch-Zawy attack [4] by making invalid any di=
fficulty adjustment period with a
<br>&gt;    negative duration.
<br>&gt; - A fix for long block validation times with a minimal "confiscati=
on surface", by introducing a
<br>&gt;    per-transaction limit on the number of legacy sigops in the inp=
uts.
<br>&gt; - A fix for merkle tree weaknesses by making transactions which se=
rialize to exactly 64 bytes
<br>&gt;    invalid.
<br>&gt; - A fix for duplicate transactions to supplement BIP34 in order to=
 avoid resuming unnecessary BIP30
<br>&gt;    validation in the future. This is achieved by mandating the nLo=
ckTime field of coinbase
<br>&gt;    transaction to be set to the height of their block minus 1.
<br>&gt;
<br>&gt; I have started drafting a BIP draft with the detailed specs for th=
is.
<br>&gt;
<br>&gt; Antoine Poinsot
<br>&gt;
<br>&gt;
<br>&gt; [0] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&=
amp;q=3Dhttps://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197=
d3eabe661050c2/bip-XXXX.mediawiki&amp;source=3Dgmail&amp;ust=3D173901974903=
2000&amp;usg=3DAOvVaw1htn5EyxYdVM97ybzZmb61" rel=3D"noreferrer nofollow noo=
pener" target=3D"_blank" href=3D"https://github.com/TheBlueMatt/bips/blob/7=
f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki">https://github.=
com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX=
.mediawiki</a>
<br>&gt; [1] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&=
amp;q=3Dhttps://delvingbitcoin.org/t/great-consensus-cleanup-revival/710&am=
p;source=3Dgmail&amp;ust=3D1739019749032000&amp;usg=3DAOvVaw1GRs4gEnpLL9cDp=
ZwU4qzP" rel=3D"noreferrer nofollow noopener" target=3D"_blank" href=3D"htt=
ps://delvingbitcoin.org/t/great-consensus-cleanup-revival/710">https://delv=
ingbitcoin.org/t/great-consensus-cleanup-revival/710</a>
<br>&gt; [2] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&=
amp;q=3Dhttps://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ=
&amp;source=3Dgmail&amp;ust=3D1739019749032000&amp;usg=3DAOvVaw0p6kXWtCxH-h=
Fs8VOjCnao" rel=3D"noreferrer nofollow noopener" target=3D"_blank" href=3D"=
https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ">https:=
//groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ</a>
<br>&gt; [3] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&=
amp;q=3Dhttps://delvingbitcoin.org/t/worst-block-validation-time-inquiry/71=
1&amp;source=3Dgmail&amp;ust=3D1739019749032000&amp;usg=3DAOvVaw0JpBb4DEgl1=
TbouNjzazLy" rel=3D"noreferrer nofollow noopener" target=3D"_blank" href=3D=
"https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711">http=
s://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711</a>
<br>&gt; [4] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&=
amp;q=3Dhttps://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/10=
62%23variant-on-zawys-attack-2&amp;source=3Dgmail&amp;ust=3D173901974903200=
0&amp;usg=3DAOvVaw36Ds3e7_r7TwqZdqgavKhM" rel=3D"noreferrer nofollow noopen=
er" target=3D"_blank" href=3D"https://delvingbitcoin.org/t/zawy-s-alternati=
ng-timestamp-attack/1062#variant-on-zawys-attack-2">https://delvingbitcoin.=
org/t/zawy-s-alternating-timestamp-attack/1062#variant-on-zawys-attack-2</a=
>
<br>&gt;
<br>
<br></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.com" target=
=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups.google.com/=
d/msgid/bitcoindev/53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_=
kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv=
6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc%3D%40protonmail.com</a>.<br />

--b1=_Y3Iu2WXyJdHItl8v1mSm30Y72x6w24sjW2asHxdPk--