Delivery-date: Mon, 31 Mar 2025 13:50:34 -0700 Received: from mail-qt1-f191.google.com ([209.85.160.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tzM5Z-00029j-8f for bitcoindev@gnusha.org; Mon, 31 Mar 2025 13:50:34 -0700 Received: by mail-qt1-f191.google.com with SMTP id d75a77b69052e-4766afee192sf25618711cf.0 for ; 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=N9+HO3HQFG3hQMVxHbS8cIhQI+OSeKUu/eujaumLMvhX9Pg+tMytK6uIXrUX9UDQDY yJHFZNT+6C5fIK/8phitoWqhHKPyasbdx4aSK6jSBNBaiT6wxEhduQ7EnJHrLNI8d2Ae huNXZcQvfov0+HERZMrsfN/Xkt/16IWMa0d2+/UfxOjzpOYNIdUm0u2+hC+MyeNwC3zS hqp5Bg5nnNKp6fNscXiL8RY6TG4VkrYLooPuE7Y330+2cKoXP4rAJqjJGw9uaaKsVV2h DH0cyOtShpfaIVT/roMMKl7jmoGNjRzzE2GrTucGShgo0G8c2x/KUUApM301GWRPxQpY 9JDQ== 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:from:to:date :dkim-signature; bh=UFfqUP2zVAO1U+OiAlMVTHN0hyzuyheanw9g0W4O/x4=; fh=4fdkDWiEyMY7rwK2Ldyn0hdB3zKqI7fo4O+G33ZsmoE=; b=eF63vaWbJ1mxnWW/2cQ1ybf9STxscaznH1o3zdGnxEldtYkZu/txapdAIxYbmu/Gnb zIsdN8VALY5oHMNowrEndf950jdZWy0LkNZWp9Xm5Pi9LnhVUzejjtNlOVq/Czf0qKA4 BGsSxeN/J6Sm/DnbTur9YOUPVWXZihfdsjNs7wDk0Q9dZBsxdggPtqCCqSIec95NhdGF waiEPFXQrYp3Ur8f1GUBHqHjqAx4z71iiKPsHlZMc8fILFMGZAsEGBtM83nGA8iSCj7p 7GFidn2krfxhyu8X0qp2zJcDfMTqVrShBGopTIQj4EbpvMFXvGMah+sDRHc7d7aMdJvv iLzA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=SQVfOUxK; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 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=1743454227; x=1744059027; 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:from:to:date :from:to:cc:subject:date:message-id:reply-to; bh=UFfqUP2zVAO1U+OiAlMVTHN0hyzuyheanw9g0W4O/x4=; b=C5ND5SaM5xnAt+j201ySelYtdnkP6IybhxRv8ojoXqGvrER/fkM8DaY58EYNMG24LT 8v4C0dLS/Jbg+bdkCJij8p7qHkuv39nJYIAdrQFkTM+E7SOkg726ndNv10er0xBoRZqW RsacnDisEBc+dne9hCfzAmz8nvieoAyjSHKWj6U0pueqY7KX4xPek5KztwumBSx071/J pJ4ztd7Ph6ApHAXXJBuL60EQvixMgrGcB5mEVSuu+0WOMTq5tQpNNd3CbbUj/HjoUmr/ YccJkPX2zoq8290Fgxb4lNQA6nyKuZLwHeVai8Gqfy6Yllz9J/CoU4JV+8y/SrIDh9ku ebhw== 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:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:from:to:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UFfqUP2zVAO1U+OiAlMVTHN0hyzuyheanw9g0W4O/x4=; b=JNm4V2U8zww/MLK29IGGP7gOu25UTZi2bL2lJy4/rRynqyp7ReRzq4brM6Djxlf1GF uDQt1LB1X9KGX1tiJ7llR6qG0z2f1/3d0OBN0bRNRDZ0rx39Pf1SekZSxzMYc0dbWPAh FeB6TvbEhvNWyEPzdxEMbI+4sJvIzwFiY+6u4Z79oBL8vMkNY0Bac61fv5ORDp7wq+5F prQ6HoJK46WJz/tCJPVeoEciHf3X0lkx3D3pu5CkY3asX7DnpD3CxyCXUBrmdVJ5t3f0 URCt/NYrl3WPbHDCQ5dZPsurqLtDIJ1prdth2mZrpD+8Rhxw+lIQuVHAv+BfPyI0sY3c X5Zg== X-Forwarded-Encrypted: i=2; AJvYcCUKYnr3FwQX3sCfJWu0FvbPryME19NyUzNCzNxfF01FZ/Agy5UL/H8Z1Nvbzs0IAQe83GhKQMUxwzGn@gnusha.org X-Gm-Message-State: AOJu0YwgAGIquknPi/yi56HOaGPCMjbxy6y63m9jzRAJgMGCEPWdbFXK ufD7jd5x3kY9X6i5I7ITiEy41y7OwAZZ6GpkZulZ3qtW8iuwhVB6 X-Google-Smtp-Source: AGHT+IHMZk2pjAafKQcz6S3rM78kzpu3H1qms3eWksFu3pxrnYEneD87UdUPXDB/GGxNWEqgFuDROQ== X-Received: by 2002:a05:622a:19a7:b0:476:97d3:54f with SMTP id d75a77b69052e-477e4b294fbmr192337871cf.14.1743454227512; Mon, 31 Mar 2025 13:50:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJ1w3U73vQ7z6QEnhSJLuQDvrCKy9thxgDq3hsQQQG35A== Received: by 2002:ac8:6601:0:b0:476:7e35:1cd5 with SMTP id d75a77b69052e-4776e324452ls23513001cf.0.-pod-prod-04-us; Mon, 31 Mar 2025 13:50:24 -0700 (PDT) X-Received: by 2002:a05:620a:4544:b0:7c5:53ab:a722 with SMTP id af79cd13be357-7c6862ec00cmr1584988785a.5.1743454224614; Mon, 31 Mar 2025 13:50:24 -0700 (PDT) Received: by 2002:a05:600c:3acd:b0:43c:fd8b:faa8 with SMTP id 5b1f17b1804b1-43d783ec5b7ms5e9; Thu, 27 Mar 2025 14:39:01 -0700 (PDT) X-Received: by 2002:a05:6000:2d86:b0:391:40bd:621e with SMTP id ffacd0b85a97d-39ad1784afdmr3776869f8f.44.1743111538736; Thu, 27 Mar 2025 14:38:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1743111538; cv=none; d=google.com; s=arc-20240605; b=V9OVAtVhu47QB3aZ8OMDBdktiASPdYs5hdBI0smSiyRDdv6p6yNQkFp3X9i/2t4c85 75q9gV4lVnPvdoFVtVb3Zgm5yycZi+a39SB0AacFiNyHSqST0yjfzDnK6i4HRw4CW5hW 9dcotSOXFT280plxFgskhhrUiPTdxlGSE4Uli6OAyoo9GyYrNidjZ/dDoFPj/AFor6UP OTnqR523iviRugDvC12mN5Bv1RFM6/2A9rCzMZqPgjlJGUB8A/I5eqw6QBc/jTHsObJq Q9e050kVJdiL3HqWhWvsSMJuHcNfo7/5kvBW0suVVR8BJlYkqwFxaMVzu+F+2KpfpZFe uGGQ== 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 :from:to:date:dkim-signature; bh=2GVr6SwcBra/DnzpGRccQKWiuIktkdOkQd4wDlFfjr8=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=ei1DlyfC7SrX5/aw1hO7bL9+6TD9S0o5yv1tE2QPWFLUEwdncCLmMe7CndrKOvQYCF Uw0FT3oHO/m2JQRorWmVhQICS6LCx2aSlJIeF+hCqw2QILupyravfOZxUBkR/JzY4Tz7 1r7/awQVxXBV2c0tEw4wK5927nRApklQLMsN+kkTuwIDm+IsRa+vIGu/a6hyFxWnXbqb hQNvwgyupEkxLid7f0oasTC+dRj3itQAND+HlZCBAnRzxRNnXt89c49HvD1QV4JyAPNV RhECEwI+HFs6Ybuwj1Gz+ELD2YwCzuC9fqh53DO/YOLDaK+v0Us2K7jLJNd5lvz2YxrP y8LQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=SQVfOUxK; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch. [79.135.106.29]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-43d9151824bsi74975e9.1.2025.03.27.14.38.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Mar 2025 14:38:58 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) client-ip=79.135.106.29; Date: Thu, 27 Mar 2025 21:38:51 +0000 To: "bitcoindev@googlegroups.com" From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Subject: Re: [bitcoindev] Consensus Cleanup BIP draft Message-ID: <2Lz1KjZ8CJ8i_pHJWpGK8lH2UqUbTiLmyRL9qv5hZJkV9pBpXyYL1i288FwsrvtGMPMU-lhFxv0x-sGnUus9RlA8lMCxrwo8TV5ik1yPxfk=@protonmail.com> In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 8cf5ee7187151a34bb3f25791e0a5bee6857c1aa MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_6drVqN9TkLKeTR0d16KWzmhByv2KGydeKuURnjvUxZw" 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=SQVfOUxK; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 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=_6drVqN9TkLKeTR0d16KWzmhByv2KGydeKuURnjvUxZw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeremy, Thanks for your recommendations. I suggest you lead by example. "Discussed at length" is not about me. My hastily sharing mistaken results = [0] a week ago shouldn't obscure the fact that 64 bytes transactions have b= een studied and generally considered harmful since at least 2017 [1], almos= t a decade ago. Regarding your other questions i don't think you, of all people, are in a p= osition of taking this moral high ground and interrogating tone when it com= es to consulting industry stakeholders at large about a consensus change. That said, i (as well as others) have in fact been discussing Consensus Cle= anup with some miners (hashers as well as pools) for a while. I intend to s= hare some testing results soon. Antoine [0] [https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/82](h= ttps://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/82?u=3Danto= inep) [1] [https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tr= ee-design](https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-mer= kle-tree-design/) On Thursday, March 27th, 2025 at 4:45 PM, jeremy = wrote: >> 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 a= nd discussed at length by multiple people over the past year gives me confi= dence to move forward with every single one of those. Otherwise i would not= have proposed this BIP in the first place. > > I'd recommend taking a much more flexible mindset at this stage. The set = of eyeballs you get at a pre-BIP and BIP stage, and the level of attention = are very different, and this type of messaging is very discouraging for som= eone with expertise to care to put review in v.s. disregarding the effort a= s non-constructive. > > Critically: > > In your "discussed at length" proposal, you failed to realize that there = were indeed 64 byte transactions on-chain until it was pointed out to you 7= days ago. > > You also include a hack using coinbase nSequence -- have you bothered to = talk to anyone in the mining business how they feel about that? Are you sur= e no ASIC in the wild don't hardcode a field that never needed to be set be= fore? > > 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 conditi= on. > > regards, > > Jeremy > > On Thursday, March 27, 2025 at 3:36:13=E2=80=AFPM UTC-4 Antoine Poinsot w= rote: > >> 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 wo= uld 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 BIP341, BIP= 342, and BIP343 in Taproot. >> >> Those BIPs had much more content to them. The specifications of the Cons= ensus 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 would just introduce unnecess= ary 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 a= nd discussed at length by multiple people over the past year gives me confi= dence to move forward with every single one of those. Otherwise i would not= have proposed this BIP in the first place. >> >> Now, even if somehow we should drop one of the mitigations from the prop= osal, having them in separate BIPs does not make that any easier. >> >>> More active contributors to the project may have stronger opinions on t= he best approach there. >> >> Yes. >> >> Best, >> Antoine >> >> [0] https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbt= bFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=3D= @protonmail.com >> On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart wrote: >> >>> Hi Antoine, >>> >>> First off, concept ACK. My concerns are procedural rather than objectio= ns to the individual security fixes themselves. >>> >>> The "Great Consensus Cleanup" is a fantastic brand for communicating th= ese protocol changes to non-technical users. However, since this is a techn= ical forum and we are producing BIPs intended for technical audiences, I be= lieve we should document these changes in separate BIPs. >>> >>> The proposed security fixes are largely unrelated from a technical stan= dpoint: >>> >>> - >>> >>> Timewarp attack mitigation >>> >>> - >>> >>> Worst-case block validation constraints >>> >>> - >>> >>> Disallowing 64-byte transactions >>> >>> - >>> >>> Avoiding duplicate transactions >>> >>> We should absolutely retain the "Great Consensus Cleanup" branding whil= e independently documenting each security enhancement. >>> >>> A common concern I=E2=80=99ve heard about splitting this BIP is that de= ploying soft forks is difficult, so all changes should be bundled together.= While soft fork deployment is indeed challenging, we've successfully activ= ated multiple BIPs within a single soft fork in the past=E2=80=94e.g., BIP1= 41 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 t= ogether, 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 r= est 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 fo= r Bitcoin Core. More active contributors to the project may have stronger o= pinions on the best approach there. >>> >>> -Chris >>> >>> --------------------------------------------------------------- >>> >>> On Wed, Mar 26, 2025 at 1:23=E2=80=AFPM 'Antoine Poinsot' via Bitcoin D= evelopment Mailing List wrote: >>> >>>> Hi everyone, >>>> >>>> About two months ago i shared an update on this list about my (and oth= ers', really) work on the >>>> Consensus Cleanup [0]. I am now ready to share a BIP draft for a Conse= nsus 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 dif= ficulty adjustment period to >>>> address the Timewarp and Murch-Zawy attacks; >>>> - a limit on the number of legacy signature operations that may be exe= cuted in validating a single >>>> transaction to address long block validation times; >>>> - making 64 bytes transactions invalid to address weaknesses in the bl= ock 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 in= cludes Ava Chow, Matt Corallo, >>>> Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony T= owns, Greg Sanders, Chris >>>> Stewart, Eric Voskuil, @0xb10c and others. >>>> >>>> Antoine Poinsot >>>> >>>> [0] https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kl= dcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI= =3D@protonmail.com >>>> [1] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d219= 7d3eabe661050c2/bip-XXXX.mediawiki >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+...@googlegroups.com. >>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoi= ndev/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8= eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%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. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/afedbc69-8042-4fe8-99c2-279173a440f3n%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/= 2Lz1KjZ8CJ8i_pHJWpGK8lH2UqUbTiLmyRL9qv5hZJkV9pBpXyYL1i288FwsrvtGMPMU-lhFxv0= x-sGnUus9RlA8lMCxrwo8TV5ik1yPxfk%3D%40protonmail.com. --b1=_6drVqN9TkLKeTR0d16KWzmhByv2KGydeKuURnjvUxZw Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeremy,

Thanks for= your recommendations. I suggest you lead by example.

"Discussed at length" is not= about me. My hastily sharing mistaken results [0] a week ago shouldn't obs= cure the fact that 64 bytes transactions have been studied and generally co= nsidered harmful since at least 2017 [1], almost a decade ago.

Regarding your othe= r questions i don't think you, of all people, are in a position of taking t= his moral high ground and interrogating tone when it comes to consulting in= dustry stakeholders at large about a consensus change.

That said, i (as well as ot= hers) have in fact been discussing Consensus Cleanup with some miners (hash= ers as well as pools) for a while. I intend to share some testing results s= oon.


<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">[0] http= s://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/82<= br>
On Thursday, March 27th, 2025 at 4:45 PM, jeremy <jeremy.l.rubin= @gmail.com> wrote:
> First of a= ll, i do not expect to remove any of the mitigations from the BIP at this s= tage. 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 propose= d this BIP in the first place.

I'd recom= mend taking a much more flexible mindset at this stage. The set of eyeballs= you get at a pre-BIP and BIP stage, and the level of attention are very di= fferent, and this type of messaging is very discouraging for someone with e= xpertise to care to put review in v.s. disregarding the effort as non-const= ructive.

Critically:

In your "discussed at length" proposal, you failed to realize= that there were indeed 64 byte transactions on-chain until it was pointed = out to you 7 days ago.
=
You also include a= hack using coinbase nSequence -- have you bothered to talk to anyone in th= e mining business how they feel about that? Are you sure no ASIC in the wil= d don't hardcode a field that never needed to be set before?

I'm also personally strongly against removing 64-byte t= ransactions. It's a wart in how transactions work, and future upgrades (esp= ecially around tx programmability) might integrate very poorly with this ki= nd of edge condition.
<= br>
regards,

Jeremy

On Thursday, March 27, 2025 at 3:36:13=E2=80=AFPM UTC-4 Antoine Po= insot wrote:
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">Hi Chris,

As i already explained o= n 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 progres= s on this proposal.

we've successfu= lly activated multiple BIPs within a single soft fork in the past=E2=80=94e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP3= 42, and BIP343 in Taproot.

Those BIPs had much more content to them. The specif= ications of the Consensus Cleanup is trivial in comparison: they fit in les= s 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 would jus= t introduce unnecessary overhead.

i= f 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 th= is stage. The fact that each of these mitigations was researched and discus= sed 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 pro= posed this BIP in the first place.

Now, even if somehow we should drop one of the mitigation= s from the proposal, having them in separate BIPs does not make that any ea= sier.

<= /div>
More active contributors to t= he project may have stronger opinions on the best approach there.
=
Yes.

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 objection= s to the individual security fixes themselves.

The "Great Consensus Cleanup" is a fantastic brand for communicating the= se protocol changes to non-technical users. However, since this is a techni= cal forum and we are producing BIPs intended for technical audiences, I bel= ieve we should document these changes in separate BIPs.

The proposed security fixes are largely unrelated from a technical stand= point:

  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 dep= loying soft forks is difficult, so all changes should be bundled together. = While soft fork deployment is indeed challenging, we've successfully activa= ted multiple BIPs within a single soft fork in the past=E2=80=94e.g., BIP14= 1 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. I= f the community reaches consensus, we can still deploy all these changes to= gether, 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 re= st of the improvements. Additionally, once these fixes are deployed, there = will likely be significant research and documentation to incorporate, and m= aintaining 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 op= inions 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 difficul= ty 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 M= erkle tree construction;
- mandating coinbase transactions be timelocked to their block height to pr= event future transaction
duplication without resorting to BIP30 validation.

This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt Coral= lo [1]. A number of
people contributed ideas, testing, data or useful discussions. This include= s 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/jiyMlvTX8BnG71f75SqChQZxy= hZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3= MopuATI=3D@protonmail.com
[1] https://github.com/TheBl= ueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawik= i

--
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+...@googlegroups.com.<= br> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/uDAujRxk4oWnEGYX9lBD3e0V7a4V4= Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zn= e4g%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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/afedbc69-8042-4fe8-99c2-279173a440f3n%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/= 2Lz1KjZ8CJ8i_pHJWpGK8lH2UqUbTiLmyRL9qv5hZJkV9pBpXyYL1i288FwsrvtGMPMU-lhFxv0= x-sGnUus9RlA8lMCxrwo8TV5ik1yPxfk%3D%40protonmail.com.
--b1=_6drVqN9TkLKeTR0d16KWzmhByv2KGydeKuURnjvUxZw--