path: root/d7/4802c1410e1508f67822303afec023db9c3803

Delivery-date: Mon, 31 Mar 2025 13:50:34 -0700
Received: from mail-oo1-f58.google.com ([209.85.161.58])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC5P5KEHZQLBBEEAVS7QMGQECNSWT5I@googlegroups.com>)
	id 1tzM5Y-00029i-V3
	for bitcoindev@gnusha.org; Mon, 31 Mar 2025 13:50:34 -0700
Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-6022020de0dsf3221893eaf.0
        for <bitcoindev@gnusha.org>; Mon, 31 Mar 2025 13:50:33 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1743454227; cv=pass;
        d=google.com; s=arc-20240605;
        b=UoZi12etEc2NHMrCCagFihbaCMSyLTbzRZO1Abfad9aBBd8eVPjMRdfX1dfpIzX8cn
         Da62SRmVIYg/idj9k1LYwoRTr8rldVv9Z3bxliIUnqOapULOiillqwiZaR1M+l0LN+or
         enfugUCs77Uj59MVqlzAxXa/nBtKyaOZT6r04B4ije7Ky+UVwhNsg00K8hqvAt8Beq41
         7l5i2M2J5+UTUdS9Z5rdiuA6sw7TfH2mG+62nQxSZPA7tAMoF5P2WbbMstbouvJurhgP
         e4Abioj40JXd65tfSTiJna6zqW3E8ky2gVP6cN27qHU8acCxANb5mMo5teGaqz3M2N/F
         MfhA==
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:content-language:thread-index
         :content-transfer-encoding:mime-version:message-id:date:subject
         :in-reply-to:references:cc:to:from:sender:dkim-signature;
        bh=mY6wqiNjl+tE8O6q7QPffO/qOqOu2u6IgWmIhi7j6vE=;
        fh=96ODzq1PqV7GzZvXV/D+Hb3+KkteTBPFaEuT/ZB8sWM=;
        b=hwrR7usKNz3zk7GNpAZPsv5jX4gvRRcwxkL/QOrR7o31SZj7lGQi9NjHp3l9JVPfyi
         PCL2E6cihLpYhv7TEE2xj9diBufA1JAromOGemytSLnYsRY/DfIU0fLVHQwuaNI6Q+HS
         cxR9ZU0muBo0dCs0y2KMwrHamovG4KplKh78H0pd+f34rMOBqsZ8zyvX6SQgL2iPjUc6
         HAaf1nDnNFWNSk3ka9Lv2MAaeuW8RWlQ+ynF8IVdSmifuOnmzz5EWI6FySCk0BtL3Ewo
         h4WolL6ZGjp0D7SU6e90sVONkW2vcyHgUl8Q1QrH2Y53iv5gs9aq3WMK6DgqlwlylYny
         J0hg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@voskuil-org.20230601.gappssmtp.com header.s=20230601 header.b=BO7AXHxf;
       spf=none (google.com: eric@voskuil.org does not designate permitted sender hosts) smtp.mailfrom=eric@voskuil.org;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1743454227; x=1744059027; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-language:thread-index
         :content-transfer-encoding:mime-version:message-id:date:subject
         :in-reply-to:references:cc:to:from:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mY6wqiNjl+tE8O6q7QPffO/qOqOu2u6IgWmIhi7j6vE=;
        b=bktVBu9tQyfFKPoItQoE0E3CjJp1NH3HwYAlEQKqWbRs9FZwS+a7ZbEAbICwiivV5f
         CN01YtZKDqPHyz69g7B2cxB6wSlEzukYoVo3P8XESvC9IZFe07I7laRbPDL1HdKUd/aQ
         Q24VNHYltFBGkZpJCqFki+vuWMaz1wBEyQJl8BvUWxbqSQXwl6cagJbRwfZ6g04Ifp2u
         677gI2YNQ7ZAeCljtYQpfM1w6yJA7konnBYe12gkN6veJHy1MiucC4lYcC/GE7oXpEvq
         1sIdSfBX6yYKTTIt+0YalnSTnj925wPpRP5baHRVIedjl+gRN7IzO+QQEeEXckC3wXlB
         ujYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1743454227; x=1744059027;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-language:thread-index
         :content-transfer-encoding:mime-version:message-id:date:subject
         :in-reply-to:references:cc:to:from:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=mY6wqiNjl+tE8O6q7QPffO/qOqOu2u6IgWmIhi7j6vE=;
        b=UkAkWpawwAv9pDvHXPyCa2oozgHXb0lnuWixvUHas9X3bFV38Ky/pcuhjz8rPLUEu0
         vb0Y3MyV6wfMd753JbQwduO4FRSzpwW8Jb3Z09vnEmCRiJC0brMU2WFRVTlIlp5VBvu0
         1pVgUqVyPhMhL313uKHXHAXGFW76zPkeUeycWeNKUKeuNeTz/ICgYEUk3UIx3/UUvE/3
         Yuh3Vwex1cEOhf5K5EyzHmfsoU1rIxx8vylfj+DgBCd1MA1snNlHvD82Dltfaj/pfYc4
         nXUUTn0HNLLBN9pTrXw35bsfu1d3/PisNABpzjG3tuXqMmwg1wuoviKCJmY/sdua63o3
         mMiQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXHgtONlzXd64A/GfFnXACG2DF8vDfJDwHYZDFyL55j+ds+MfYUXMQKhSclFEpGlQBw1ORxc4u945FJ@gnusha.org
X-Gm-Message-State: AOJu0YwyWvRwDi5RIgWfB+6i60Eis+CUGlTd64qTGblyyGJ7HFQrtwKg
	mK5YkfhVB76Q2tQT79zvVS3eqh/Z6qG/bCm3UyXRiSOJj+Mom8iM
X-Google-Smtp-Source: AGHT+IFhYyCNt1UrgDoe8ZVI80ijcSCd8ixg3SIXR1HG0ag68vAV4apQ7t1YuFwhRD6gBhHwlZI9pQ==
X-Received: by 2002:a4a:ee86:0:b0:602:47ec:3df0 with SMTP id 006d021491bc7-60290f5ad74mr4829740eaf.5.1743454227316;
        Mon, 31 Mar 2025 13:50:27 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAISZ01K1xOfeYGgKoxMM3+i5pvXKd6rnaZI6TFVpL/1RQ==
Received: by 2002:a4a:eb01:0:b0:600:3635:7454 with SMTP id 006d021491bc7-60278f62f55ls1547141eaf.1.-pod-prod-07-us;
 Mon, 31 Mar 2025 13:50:24 -0700 (PDT)
X-Received: by 2002:a05:6808:180b:b0:3f6:ab0d:8dbf with SMTP id 5614622812f47-3ff0f5b4637mr6120014b6e.29.1743454224448;
        Mon, 31 Mar 2025 13:50:24 -0700 (PDT)
Received: by 2002:a05:6808:985:b0:3fa:6f09:b173 with SMTP id 5614622812f47-3feefbac77emsb6e;
        Mon, 31 Mar 2025 13:09:55 -0700 (PDT)
X-Received: by 2002:a05:6e02:3a05:b0:3d3:d965:62c4 with SMTP id e9e14a558f8ab-3d5e090e8b1mr98404865ab.10.1743451794382;
        Mon, 31 Mar 2025 13:09:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1743451794; cv=none;
        d=google.com; s=arc-20240605;
        b=I79TLLEmz4Fr8x0eUjK/ixDaMgfLmgOm8UEjzR1OELBkMfZ6AfbFwfV1nEwFuzn1B8
         wa6JWpYRcFx7WbHZinE7VL7cb3g8eoHbmPUafZinldLiWr4e2Sz/ZwXAbE0IXPI80qCj
         U7/i5EMd1jbX2pQEAVqTqfpq2yBpS/Y1SxDapXRUXRecFAsr23cskOFHss+hh6MuTgik
         nP3mfm/X+Ukva4hZ+jN3wgBRwIzCx8zkz8BoEv/1KkZwgdIK2fGoSAduWIrUldRHXCoy
         WKGtCc0g/R0FT4AKbcw0qAkttf3xxLPTwzThIQv5Ex1ktEeLSk213M6KDriTKaJjHBVI
         rBpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-language:thread-index:content-transfer-encoding
         :mime-version:message-id:date:subject:in-reply-to:references:cc:to
         :from:dkim-signature;
        bh=O2kgPM2kLadgrwaYZyefkxWEyGpcs3Np0b1OnW4cENo=;
        fh=/64FZwkMqFLK2E/F7Ae+8K7ZfKrXjiz09jBVVzL++t8=;
        b=c3ltQyR1OVShe7cPzV0ulfJVHhI6uAUy+SAOiNdK2//np4n5N/cQiwmjoDOqveab3E
         ZxvB60EkWeiSnyZYEAmfeteBnKQ2kZZ/UBwihM7qJ9YpkPGGDdqPTvF/Lu/PhBtA2Fag
         H/ndkbb0LUFJVaFVraPxR+lYqEJyghZrAlh1zqZPTOeedtO62PFX94lJt5/8oaBG+ECe
         aZP5JoIDpmr74239/UG628eIvRe7gFL+QvOiHVoO0Jp5vbeyrT48IVpKIzgBG/wsviYX
         i03qNxmQGKzHes/5no1BvPJAh6RXo1zjeR1iqKrfQ+4Ua1rDrG4IY0KDmCKiSjf5S+Kk
         hfPw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@voskuil-org.20230601.gappssmtp.com header.s=20230601 header.b=BO7AXHxf;
       spf=none (google.com: eric@voskuil.org does not designate permitted sender hosts) smtp.mailfrom=eric@voskuil.org;
       dara=pass header.i=@googlegroups.com
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com. [2607:f8b0:4864:20::735])
        by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-3d5d5ade6bcsi3806975ab.3.2025.03.31.13.09.54
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 31 Mar 2025 13:09:54 -0700 (PDT)
Received-SPF: none (google.com: eric@voskuil.org does not designate permitted sender hosts) client-ip=2607:f8b0:4864:20::735;
Received: by mail-qk1-x735.google.com with SMTP id af79cd13be357-7c55b53a459so508810985a.3
        for <bitcoindev@googlegroups.com>; Mon, 31 Mar 2025 13:09:54 -0700 (PDT)
X-Gm-Gg: ASbGnctZ4IFlX8q0ZfuD7bMX3hm7Fd3Uok3/kD6MOVDopuNraz2XwHta7aVLIdZyhIl
	A+zDXwxMPmGOeQzV+PnfJs0qlP4Os5afEFQ/y18wb08PDAQERC9IOOF/YwtZAGvhus8hkikb5DN
	QQlKggTgIa2rEau5p93TPzy/fyk2WTWyQ1bKk+Ml/9K09Qk8aDiiXVTkupSrWTevoUx+S3NFcTF
	gD4UyYgxsXE7tRfKr9TpcXqNvyrjzKM/tKSSio8xVx9bhYG2yozgGrtbFa185u37ZfIPgfT21ib
	0kViKo3P9uKBVZbn+43IQhluqje9oNreHXZ042dxr2Yc5bfkzUCemnB9Lw3ixYTEFjRCvBJ14N7
	TmFASjhUQ3g==
X-Received: by 2002:a05:620a:4720:b0:7c5:49b7:237a with SMTP id af79cd13be357-7c6865ea978mr1325568985a.19.1743451793225;
        Mon, 31 Mar 2025 13:09:53 -0700 (PDT)
Received: from ERICDESKTOP (c-73-227-67-43.hsd1.nh.comcast.net. [73.227.67.43])
        by smtp.gmail.com with ESMTPSA id af79cd13be357-7c5f777e020sm538560185a.109.2025.03.31.13.09.52
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 31 Mar 2025 13:09:52 -0700 (PDT)
From: <eric@voskuil.org>
To: "'Antoine Poinsot'" <darosior@protonmail.com>
Cc: "'Bitcoin Development Mailing List'" <bitcoindev@googlegroups.com>
References: <uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g=@protonmail.com> <CAGL6+mFQqTS21cQZ_aU=hXtMaKkw5ygAk2PT9hQpdB4THz9X_A@mail.gmail.com> <TD8gP8PKw3th-0DrZznBXrXFILRkwr66wVRoiPC2di_e-NivCRKVjooVZIh7JJSV_C9rJEkKTvudWSG8CJsq16jPhQBjM0eVmPe8rir50Y4=@protonmail.com> <afedbc69-8042-4fe8-99c2-279173a440f3n@googlegroups.com> <065901dba01b$2164fff0$642effd0$@voskuil.org> <xusxPfCMTmIMZ4dvGoG4SvPH3kg1vFSq3Hrk0GFHVKJCSC9aojyeyY6fUkwq_3PRhiHowSrT3B2KbJXMT6PENmOH1dvwYve8ofwZSN6QpKc=@protonmail.com>
In-Reply-To: <xusxPfCMTmIMZ4dvGoG4SvPH3kg1vFSq3Hrk0GFHVKJCSC9aojyeyY6fUkwq_3PRhiHowSrT3B2KbJXMT6PENmOH1dvwYve8ofwZSN6QpKc=@protonmail.com>
Subject: RE: [bitcoindev] Consensus Cleanup BIP draft
Date: Mon, 31 Mar 2025 16:09:51 -0400
Message-ID: <009d01dba278$dcde1a00$969a4e00$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHWtHeW1eEx0HT2gtpWV+YJenkSdAJggGU8AIKIJN0B5cf6jAIQknyBAce1iyezUnjAMA==
Content-Language: en-us
X-Original-Sender: eric@voskuil.org
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@voskuil-org.20230601.gappssmtp.com header.s=20230601
 header.b=BO7AXHxf;       spf=none (google.com: eric@voskuil.org does not
 designate permitted sender hosts) smtp.mailfrom=eric@voskuil.org;
       dara=pass header.i=@googlegroups.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: -0.8 (/)

> Hi Eric,
>=20
> Thanks for chiming in.

Certainly, thank you as well for your work on this.

> > This kind of discontinuity always comes back to bite eventually. That c=
oncern
> should not be dismissed so casually.
>=20
> I don't think i've dismissed your concern when you brought this up last y=
ear. In
> fact i link to my summary of arguments on both sides of this debate in th=
e BIP:
> https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41.

You have been fair. I don't mean to imply that you dismissed the points I r=
aised. But it doesn't seem to me that this discontinuity has been given muc=
h weight. This was the issue that Jeremy raised.

>>> It's a wart in how transactions work, and future upgrades (especially a=
round tx programmability) might integrate very poorly with this kind of edg=
e condition.

From my experience every condition magnifies complexity over time. We are t=
alking about moving a condition from SPV clients into consensus.

> > But more to the point, it does not solve any of the problems that were
> originally provided as justification, apart from making it slightly simpl=
er to
> implement an SPV wallet (no need to get the coinbase tx).
>=20
> I did provide an incorrect motivation at some point (caching), and apprec=
iate
> your correction on this. But the main original motivation for invalidatin=
g 64
> bytes transactions was always to get rid of the footgun for SPV verifiers=
...

This thread contains the technical discussion on the question:
https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/MsOdTqYyCwAJ

Your early response to my query listed:
(1) make node invalidity caching more performant.
(2) preclude the need for SPV clients to get the coinbase proof.
(3) "Finally, it would get rid of a large footgun in general. Certainly, un=
ique block hashes would be a useful property for Bitcoin to have. It's not =
far-fetched to expect current or future Bitcoin-related software to rely on=
 this."

The tradeoff was described as:
"Outlawing 64-bytes transactions is also a very narrow and straightforward =
change, with trivial confiscatory effect as any 64-bytes transactions would=
 either be unspendable or an anyone-can-spend. Therefore i believe the bene=
fits of making them illegal outweigh the costs."

I realize there was a lot of subsequent discussion , and that you accepted =
that 1 and 3 would not in fact be benefits of the fork. But the third objec=
tive was not limited to caching. One of my concerns was that people were be=
ing influenced by these objectives that would not in fact be achieved or ev=
en advanced.

> And as Sjors points out SPV verifiers shouldn't be reduced to only SPV wa=
llets.

Let's say SPV clients. I wasn't making an intentional distinction except be=
tween consensus and non-consensus code.

> > If people agree that this is a worthwhile trade, I'm not going to lose =
any sleep
> over it.
>=20
> This is my position and the reason why i included it in my BIP. Of course
> introducing this discontinuity is pretty ugly. I just believe it's less b=
ad than
> keeping the weakness that 64 bytes transaction introduce.
>=20
> I am also not married to the idea. In fact, i think it's one of the less =
important
> fixes from the proposal. But as things stand i think it's preferable to i=
nclude it.
> Of course i am happy to reconsider in the face of new arguments and/or da=
ta.
>=20
> Best,
> Antoine

Best,
Eirc

> On Friday, March 28th, 2025 at 3:53 PM, eric@voskuil.org <eric@voskuil.or=
g>
> wrote:
>=20
> >
> >
> > Hi Jeremy,
> >
> > > I'm also personally strongly against removing 64-byte transactions.
> > > It's a wart in how transactions work, and future upgrades
> > > (especially around tx
> > > programmability) might integrate very poorly with this kind of edge
> condition.
> >
> >
> > I tend to agree. This kind of discontinuity always comes back to bite
> eventually. That concern should not be dismissed so casually.
> >
> > But more to the point, it does not solve any of the problems that were
> originally provided as justification, apart from making it slightly simpl=
er to
> implement an SPV wallet (no need to get the coinbase tx). This was discus=
sed
> at very great length here and on delving by myself and others, and I beli=
eve
> that it was fully accepted that the only justification is this SPV questi=
on. There
> are no issues of security or performance for any code, and not even a cod=
e
> simplification for a node. It's a new consensus rule that creates this
> discontinuity - only to make an SPV wallet very slightly easier to implem=
ent.
> There is no other benefit whatsoever. I want to emphasize this because in=
 the
> discussion it still seems that people may be holding on to the idea that =
it
> provides some other benefit - it doesn't. If people agree that this is a
> worthwhile trade, I'm not going to lose any sleep over it. But I don't li=
ke seeing
> arguments about consensus being based on implementation details -
> especially when they are flawed. It feels very much to me that this is wh=
at got
> this issue going (the several rejected arguments about node performance a=
nd
> simplification), and may be in part what's still driving it.
> >
> > I ACK the single activation concept, but don't accept that a rule shoul=
d be
> deployed that would not stand on its own justification.
> >
> > Also, I do appreciate the work that Antoine and others have done on the=
 set
> of issues overall.
> >
> > Best,
> > Eric
> >
> > > On Thursday, March 27, 2025 at 3:36:13=E2=80=AFPM UTC-4 Antoine Poins=
ot
> wrote:
> > >
> > > Hi Chris,
> > >
> > > As i already explained on this very list 2 months ago [0], i don't
> > > find the argument for splitting my BIP convincing. On the contrary i
> > > think it would be counterproductive as it would create more churn,
> > > invite bikeshedding and overall impede progress on this proposal.
> > >
> > > we've successfully activated multiple BIPs within a single soft fork
> > > in the past=E2=80=94e.g., BIP141 and BIP143 in Segwit, as well as BIP=
341,
> > > BIP342, and BIP343 in Taproot.
> > >
> > > Those BIPs had much more content to them. The specifications of the
> > > Consensus Cleanup is trivial in comparison: they fit in less than a
> > > dozen lines of text when described in details. Splitting them in 4
> > > different BIPs with a single or a couple lines of specifications woul=
d just
> introduce unnecessary overhead.
> > >
> > > if one of the proposed changes turns out to be controversial, we
> > > could remove it without holding up the rest of the improvements.
> > >
> > > First of all, i do not expect to remove any of the mitigations from
> > > the BIP at this stage. The fact that each of these mitigations was
> > > researched and discussed at length by multiple people over the past
> > > year gives me confidence to move forward with every single one of
> > > those. Otherwise i would not have proposed this BIP in the first plac=
e.
> > >
> > > Now, even if somehow we should drop one of the mitigations from the
> > > proposal, having them in separate BIPs does not make that any easier.
> > >
> > > More active contributors to the project may have stronger opinions
> > > on the best approach there.
> > >
> > > Yes.
> > >
> > > Best,
> > > Antoine
> > >
> > > [0]
> > >
> https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpq
> > > btbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-
> > > HdOnamw7tUrMtmXc=3D@protonmail.com
> > >
> > > On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart
> > > stewart....@gmail.com wrote:
> > >
> > > Hi Antoine,
> > >
> > > First off, concept ACK. My concerns are procedural rather than
> > > objections to the individual security fixes themselves.
> > >
> > > The "Great Consensus Cleanup" is a fantastic brand for communicating
> > > these protocol changes to non-technical users. However, since this
> > > is a technical forum and we are producing BIPs intended for
> > > technical audiences, I believe we should document these changes in
> separate BIPs.
> > >
> > > The proposed security fixes are largely unrelated from a technical
> > > standpoint:
> > >
> > > 1. Timewarp attack mitigation
> > >
> > > 2. Worst-case block validation constraints
> > >
> > > 3. Disallowing 64-byte transactions
> > >
> > > 4. Avoiding duplicate transactions
> > >
> > > We should absolutely retain the "Great Consensus Cleanup"
> > > branding while independently documenting each security enhancement.
> > >
> > > A common concern I=E2=80=99ve heard about splitting this BIP is that
> > > deploying soft forks is difficult, so all changes should be bundled t=
ogether.
> > > While soft fork deployment is indeed challenging, we've successfully
> > > activated multiple BIPs within a single soft fork in the past=E2=80=
=94e.g.,
> > > BIP141 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343
> > > in Taproot. If the community reaches consensus, we can still deploy
> > > all these changes together, even if they are documented separately.
> > >
> > > This approach also provides flexibility: if one of the proposed
> > > changes turns out to be controversial, we could remove it without
> > > holding up the rest of the improvements. Additionally, once these
> > > fixes are deployed, there will likely be significant research and
> > > documentation to incorporate, and maintaining independent BIPs will
> make it easier to manage that growth.
> > >
> > > I do see merit in implementing all the security fixes in a single PR
> > > for Bitcoin Core. More active contributors to the project may have
> > > stronger opinions on the best approach there.
> > >
> > > -Chris
> > >
> > > ________________________________
> > >
> > > On Wed, Mar 26, 2025 at 1:23=E2=80=AFPM 'Antoine Poinsot' via Bitcoin
> > > Development Mailing List bitco...@googlegroups.com wrote:
> > >
> > > Hi everyone,
> > >
> > > About two months ago i shared an update on this list about my (and
> > > others', really) work on the Consensus Cleanup [0]. I am now ready
> > > to share a BIP draft for a Consensus Cleanup soft fork.
> > >
> > > The BIP draft can be found here:
> > > https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
> > >
> > > It includes the following fixes:
> > > - a restriction on the timestamp of the first and last blocks of a
> > > difficulty adjustment period to address the Timewarp and Murch-Zawy
> > > attacks;
> > > - a limit on the number of legacy signature operations that may be
> > > executed in validating a single transaction to address long block
> > > validation times;
> > > - making 64 bytes transactions invalid to address weaknesses in the
> > > block Merkle tree construction;
> > > - mandating coinbase transactions be timelocked to their block
> > > height to prevent future transaction duplication without resorting
> > > to BIP30 validation.
> > >
> > > This BIP draws on the 2019 Great Consensus Cleanup proposal from
> > > Matt Corallo [1]. A number of people contributed ideas, testing,
> > > data or useful discussions. This includes Ava Chow, Matt Corallo,
> > > Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony
> > > Towns, Greg Sanders, Chris Stewart, Eric Voskuil, @0xb10c and
> > > others.
> > >
> > > Antoine Poinsot
> > >
> > > [0]
> > >
> https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldc
> > >
> ugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnN
> > > LRBn3MopuATI=3D@protonmail.com
> > > [1]
> > >
> https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197
> > > d3eabe661050c2/bip-XXXX.mediawiki
> > >
> > > --
> > > 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+...@googlegroups.com.
> > > To view this discussion visit
> > >
> https://groups.google.com/d/msgid/bitcoindev/uDAujRxk4oWnEGYX9lBD3e
> > > 0V7a4V4Pd-c4-
> > >
> 2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUc
> > > bl7Zne4g%3D%40protonmail.com.
> > >
> > > --
> > > 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
> > > mailto:bitcoindev+unsubscribe@googlegroups.com .
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-
> 99c2
> > > -
> > > 279173a440f3n%40googlegroups.com
> > > <https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-
> 99c
> > > 2-
> 279173a440f3n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfo
> > > oter> .
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google Grou=
ps
> "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send =
an
> email to bitcoindev+unsubscribe@googlegroups.com.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/065901dba01b%242164fff
> 0%24642effd0%24%40voskuil.org.

--=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/=
009d01dba278%24dcde1a00%24969a4e00%24%40voskuil.org.