Delivery-date: Thu, 27 Mar 2025 13:52:51 -0700 Received: from mail-qt1-f187.google.com ([209.85.160.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1txuDZ-0000FY-V1 for bitcoindev@gnusha.org; Thu, 27 Mar 2025 13:52:51 -0700 Received: by mail-qt1-f187.google.com with SMTP id d75a77b69052e-4769a1db721sf31443551cf.3 for ; Thu, 27 Mar 2025 13:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1743108764; x=1743713564; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=uczm8VxFpql0dvDXhllvLmcMKwevXkWZUPqUCRBIuxg=; b=u1EyGeil6g0lM3F32G2kyfM6nPCR6Qo/9yeLySvPZuGIAbx6g3mOMWCOAbQl6fcp9P 8VhKZkN9YZrN1aewQP8NIXAWvH98Zh/+PGtCTr8ET0ZShfPgP5xi5HM9BFq/9bbX2vfy 23OSjCNINsyU6cgP97KvhJlTV1t0+PwYXFAH3Mugij3fE10BMzvpv7SIwX283u62G6WX WUC0OTT1KBNpc2A5oF0v64ovDmN4JX98Cq+qGuIgB9mrP4JUTC1viqtzJqnbvy8dxNZD jhVhEqKkau8PMboipB5T/2Hr9yn4BvHipIkujIgyAHSPioP+VooHEu0wA3cmeUNIS1Ic hovg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743108764; x=1743713564; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=uczm8VxFpql0dvDXhllvLmcMKwevXkWZUPqUCRBIuxg=; b=NZMHMKngHVLJqz5QY0LMuv/xadEu5TFrxOk+VCdbrkASgCYKzgQ2XGMbCcjezvxtMa IWlPdPQtAaSX1IkjdCOQPS99ECmmcwPbh9K7FL5yMwPiIaSj37Z8Bpc0BSDhFosd8f3W 6FQRjH8h1jIc3swbfgCWVpzMpwecDFp2HXZ4Ao+1knfoFM9Wf0b1exq37auVhB9t/+o0 Glac+heC2qoRbkCsqttsDaHJE8/Y/C0xI7+TSjbkSLqjGkA0zsCkcxu1cjyuf61jbwQj IB/h1FfUV4hbVMEATL0zfggngtddSSR2ls913TctCZFb0vupatxQlJrUC5QF5pEobwsv OC4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743108764; x=1743713564; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=uczm8VxFpql0dvDXhllvLmcMKwevXkWZUPqUCRBIuxg=; b=esK+MDCvAdZrkibiN1s0eBVTkQzYf3x6IDlsgyuo/eMdtLy5W660FToCWgD6VhmT2W iLax03lsTuPXyGrxiayCjbLr/wKU9xuCbV4BK7JLBInB3dKbZfbwkDgNYYMfORbtYwVV epxX4kF6NNyusmi6lSyOmnoDGkcAedBjXpwEIDCE6hojrDZK8JJfQBiXuncR9etwv2ce 0049qnZFTFweY1QPXUW5x7/5KIFOfxPGosJqRd08kPCse4gCbMnuMQ4Zl+Kpza9SXsVQ YNcbhJZX18rEjoUMErQ/xoiTOFEoU8KoT9UpSv95dL7o9/nx4g+0zexjT8MDrKZlp/S3 K14Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXFJOqm142jdaonQU4Cnif4YZ2wqJEs+hfPZfdpwh5M8gqlJKetfofjhwXGluewIFIRM82dNfwi6bkF@gnusha.org X-Gm-Message-State: AOJu0YxQks+b3m/7C6K7kPGqjM58eT3WN7ZNr2rAdJVyL9HsUGqRiT5S pi0sVzjnRi6KekTmUINM0UV2c9ORGB2xzh2aDauBrzaMbAvdHCkh X-Google-Smtp-Source: AGHT+IGeavunNSKiMVxlc2Ug1ExwRsVLiWrHlrvDgTfWJxuId6fWEH9Yn6H4KsOUkap3bOUDDPhLqw== X-Received: by 2002:a05:622a:5c18:b0:476:a7f2:272d with SMTP id d75a77b69052e-4776e21d4e3mr80071061cf.44.1743108763545; Thu, 27 Mar 2025 13:52:43 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAI2eyT//MmNn/QDEaCDW7oQW0YC/UHlnFxrEU+c+Rzghw== Received: by 2002:a05:622a:1487:b0:476:70d8:43d2 with SMTP id d75a77b69052e-4776e4d06c8ls17235561cf.2.-pod-prod-00-us; Thu, 27 Mar 2025 13:52:39 -0700 (PDT) X-Received: by 2002:a05:620a:f0e:b0:7c5:93f8:f4b1 with SMTP id af79cd13be357-7c5f9db8810mr37857285a.4.1743108759808; Thu, 27 Mar 2025 13:52:39 -0700 (PDT) Received: by 2002:a05:620a:1da8:b0:7c5:3b15:3956 with SMTP id af79cd13be357-7c5da16645bms85a; Thu, 27 Mar 2025 13:45:21 -0700 (PDT) X-Received: by 2002:a05:690c:f96:b0:6fd:346f:97ba with SMTP id 00721157ae682-70224f8c4aamr68137637b3.11.1743108319591; Thu, 27 Mar 2025 13:45:19 -0700 (PDT) Date: Thu, 27 Mar 2025 13:45:19 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: Re: [bitcoindev] Consensus Cleanup BIP draft MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_55052_1515534136.1743108319260" X-Original-Sender: Jeremy.L.Rubin@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_55052_1515534136.1743108319260 Content-Type: multipart/alternative; boundary="----=_Part_55053_1253683265.1743108319260" ------=_Part_55053_1253683265.1743108319260 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > First of all, i do not expect to remove any of the mitigations from the= =20 BIP at this stage. The fact that each of these mitigations was researched= =20 and discussed at length by multiple people over the past year gives me=20 confidence to move forward with every single one of those. Otherwise i=20 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= =20 eyeballs you get at a pre-BIP and BIP stage, and the level of attention are= =20 very different, and this type of messaging is very discouraging for someone= =20 with expertise to care to put review in v.s. disregarding the effort as=20 non-constructive. Critically: In your "discussed at length" proposal, you failed to realize that there=20 were indeed 64 byte transactions on-chain until it was pointed out to you 7= =20 days ago. You also include a hack using coinbase nSequence -- have you bothered to=20 talk to anyone in the mining business how they feel about that? Are you=20 sure no ASIC in the wild don't hardcode a field that never needed to be set= =20 before? I'm also personally strongly against removing 64-byte transactions. It's a= =20 wart in how transactions work, and future upgrades (especially around tx=20 programmability) might integrate very poorly with this kind of edge=20 condition. regards, Jeremy On Thursday, March 27, 2025 at 3:36:13=E2=80=AFPM UTC-4 Antoine Poinsot wro= te: > Hi Chris, > > As i already explained on this very list 2 months ago [0], i don't find= =20 > the argument for splitting my BIP convincing. On the contrary i think it= =20 > would be counterproductive as it would create more churn, invite=20 > bikeshedding and overall impede progress on this proposal. > > we've successfully activated multiple BIPs within a single soft fork in= =20 > the past=E2=80=94e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BI= P342, and=20 > BIP343 in Taproot. > > > Those BIPs had much more content to them. The specifications of the=20 > Consensus Cleanup is trivial in comparison: they fit in less than a dozen= =20 > lines of text when described in details. Splitting them in 4 different BI= Ps=20 > with a single or a couple lines of specifications would just introduce=20 > unnecessary overhead. > > if one of the proposed changes turns out to be controversial, we could=20 > 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= =20 > BIP at this stage. The fact that each of these mitigations was researched= =20 > and discussed at length by multiple people over the past year gives me=20 > confidence to move forward with every single one of those. Otherwise i=20 > would not have proposed this BIP in the first place. > > Now, even if somehow we should drop one of the mitigations from the=20 > proposal, having them in separate BIPs does not make that any easier. > > More active contributors to the project may have stronger opinions on the= =20 > best approach there. > > > Yes. > > Best, > Antoine > > [0]=20 > https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy= 0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=3D@prot= onmail.com > On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart < > stewart....@gmail.com> wrote: > > Hi Antoine,=20 > > First off, concept ACK. My concerns are procedural rather than objections= =20 > to the individual security fixes themselves. > > The "Great Consensus Cleanup" is a fantastic brand for communicating thes= e=20 > protocol changes to non-technical users. However, since this is a technic= al=20 > forum and we are producing BIPs intended for technical audiences, I belie= ve=20 > we should document these changes in separate BIPs. > > The proposed security fixes are largely unrelated from a technical=20 > standpoint: > > 1.=20 > =20 > Timewarp attack mitigation > 2.=20 > =20 > Worst-case block validation constraints > 3.=20 > =20 > Disallowing 64-byte transactions > 4.=20 > =20 > Avoiding duplicate transactions > =20 > We should absolutely retain the "Great Consensus Cleanup" branding while= =20 > independently documenting each security enhancement. > > A common concern I=E2=80=99ve heard about splitting this BIP is that depl= oying=20 > soft forks is difficult, so all changes should be bundled together. While= =20 > soft fork deployment is indeed challenging, we've successfully activated= =20 > multiple BIPs within a single soft fork in the past=E2=80=94e.g., BIP141 = and BIP143=20 > in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the=20 > community reaches consensus, we can still deploy all these changes=20 > together, even if they are documented separately. > > This approach also provides flexibility: if one of the proposed changes= =20 > turns out to be controversial, we could remove it without holding up the= =20 > rest of the improvements. Additionally, once these fixes are deployed,=20 > there will likely be significant research and documentation to incorporat= e,=20 > and maintaining independent BIPs will make it easier to manage that growt= h. > > I do see merit in implementing all the security fixes in a single PR for= =20 > Bitcoin Core. More active contributors to the project may have stronger= =20 > opinions on the best approach there. > > -Chris=20 > ------------------------------ > > > > > On Wed, Mar 26, 2025 at 1:23=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Dev= elopment=20 > Mailing List wrote: > >> Hi everyone, >> >> About two months ago i shared an update on this list about my (and=20 >> others', really) work on the >> Consensus Cleanup [0]. I am now ready to share a BIP draft for a=20 >> Consensus Cleanup soft fork. >> >> The BIP draft can be found here:=20 >> 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=20 >> difficulty adjustment period to >> address the Timewarp and Murch-Zawy attacks; >> - a limit on the number of legacy signature operations that may be=20 >> executed in validating a single >> transaction to address long block validation times; >> - making 64 bytes transactions invalid to address weaknesses in the bloc= k=20 >> Merkle tree construction; >> - mandating coinbase transactions be timelocked to their block height to= =20 >> prevent future transaction >> duplication without resorting to BIP30 validation. >> >> This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt=20 >> Corallo [1]. A number of >> people contributed ideas, testing, data or useful discussions. This=20 >> includes Ava Chow, Matt Corallo, >> Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony=20 >> Towns, Greg Sanders, Chris >> Stewart, Eric Voskuil, @0xb10c and others. >> >> Antoine Poinsot >> >> [0]=20 >> https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeI= DJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=3D@pro= tonmail.com >> [1]=20 >> https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eab= e661050c2/bip-XXXX.mediawiki >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/uDAujRxk4oWnEGYX9lBD3e0V7a4= V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7= Zne4g%3D%40protonmail.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/= afedbc69-8042-4fe8-99c2-279173a440f3n%40googlegroups.com. ------=_Part_55053_1253683265.1743108319260 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0First of all, i d= o not expect to remove any of the mitigations from the BIP at this stage.= =C2=A0The 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 rec= ommend taking a much more flexible mindset at this stage. The set of eyebal= ls 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 someone with= expertise to care to put review in v.s. disregarding the effort as non-con= structive.

=
Critically:

In your "discussed at length" proposal, you failed to = realize that there were indeed 64 byte transactions on-chain until it was p= ointed out to you 7 days ago.

You also = include a hack using coinbase nSequence -- have you bothered to talk to any= one in the mining business how they feel about that? Are you sure no ASIC i= n the wild don't hardcode a field that never needed to be set before?
=

I'm also personally strongly against removin= g 64-byte transactions. It's a wart in how transactions work, and future up= grades (especially around tx programmability) might integrate very poorly w= ith this kind of edge condition.

regard= s,

Jeremy

On Thursday, March 27, 2025 at 3:36:13=E2=80=AFPM= UTC-4 Antoine Poinsot wrote:
Hi Chris,
=
As i a= lready explained on this very list 2 months ago [0], i don't find the a= rgument for splitting my BIP convincing. On the contrary i think it would b= e 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=20 the past=E2=80=94e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP3= 42,=20 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=20 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.=C2=A0The fact that each of these mitigations was researched and d= iscussed at length by multiple people over the past year gives me confidenc= e to move forward with every single one of those. Otherwise i would not hav= e proposed this BIP in the first place.

Now, even if somehow we should drop one of the mitig= ations from the proposal, having them in separate BIPs does not make that a= ny easier.
=
More active contributors= to the project may have stronger opinions on the best approach there.
<= /div>

Yes.=

=
Best,
Antoine=

[0] https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfF= pqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmX= c=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 objection= s to the individual security fixes themselves.

The "Great Consensus Cleanup" is a fantastic brand for communi= cating these protocol changes to non-technical users. However, since this i= s a technical forum and we are producing BIPs intended for technical audien= ces, I believe 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" bran= ding 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 ac= tivated multiple BIPs within a single soft fork in the past=E2=80=94e.g., B= IP141 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproo= t. If the community reaches consensus, we can still deploy all these change= s 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 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...@go= oglegroups.com> wrote:
Hi everyone,

About two months ago i shared an update on this list about my (and others&#= 39;, 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@googlegroups.com.
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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/afedbc69-8042-4fe8-99c2-279173a440f3n%40googlegroups.com.
------=_Part_55053_1253683265.1743108319260-- ------=_Part_55052_1515534136.1743108319260--