From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 31 Mar 2025 13:50:34 -0700 Received: from mail-qv1-f61.google.com ([209.85.219.61]) 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-00029m-Hg for bitcoindev@gnusha.org; Mon, 31 Mar 2025 13:50:34 -0700 Received: by mail-qv1-f61.google.com with SMTP id 6a1803df08f44-6e2378169a4sf105870706d6.2 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=eaST+lR0orRp5y1i9ob1qc3jCifSa9IiyWcRQLvTrs1oxZOaiuWjTuqXmQ1xhzvmwx Dy35eGfaldX71nsnGuXP3qBGGnEG25nwBkwnrp9N7FCDL6Nt06wxDq0nAHRa0BZObgRF x3dHfYAx/4/ClytrmSyxZmSf/LQkfKPRIsLyEbCmNCBsk3uZN6bv3/fZqog20YTw8vxt qljeAWkJ8yp3J1eGdrw7AUxF9ESAHcsGQj/DFr6s7y2m7Y5hTCuTZaJZV4JhgmmEtS6o geZgKHvbqp+aXUi9jJ39WjzcVEj5BRq+1sG7NqnIk1v/LWguMW3ki+9jqksyJ5pA3eQb 0q8Q== 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:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=9lLhxlueu90s2s1RIpUMwu4u7a4JDvCpEGK70EVw8nM=; fh=JpJymIgrnF9cDgtlj2exwfoFRbON3aP4KkBkUeJgFaY=; b=MfmAV5gPktZKv0E+O7mSvxCkJD5Sajh/8NK/SnYfNyqWpKGNqJJy7SF+QLaMFW6OWO bCle7xyzvguxjtPr/vsAn6F+/ueTwhwnQ90MGLAT44HymCyuC2HNHAt/O8dWFJ1Qb4wO i9iIt+Op1ibS5Mbyu+CugaNLfHWCAl7DWtTakf0kaP3JNFC4g3ES2Vj70iBg690TE41t c4q+VYi3qNak83TezfNJpTaB++FrvEu2Kl1r1MaRYiUDZvn2nocoDMC/KW1Ic5qpzo9G RDyDancyX9TDyGC+YH1XCl7UIZw1JCI7tcRWsdB3D+i2TYya1PObdnq+y6tfIz1ZppZZ Xy7w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=pH9zp9VL; 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 :content-transfer-encoding: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=9lLhxlueu90s2s1RIpUMwu4u7a4JDvCpEGK70EVw8nM=; b=tVGIl7NcCYFJ2w5yX3vLlWEDAC+zqH3GXUOKLzlIJ5yAYVPVZ3oLGGSafTMnqb+hv2 Gnyd7W75/wNI7QclXWjx9lzYoZW/of1y8pc7eq+gCWJr38fYcADd7VkTktoYdF1nJvFz 0KFx6I6f0fl0nPM7GUr8yKk4xbi0526o4mh4ciDQ1OdXYfmfqGcT5Vg4wLRykSVx01zt yAgoNLcEoPURtoPlx+pVtQgADz9U5ezpRAvDBbenVj/2xzZ5dFSkYr+1GtnpvlMk53ZR Axc7mgBEqbEaazmcyhqQzolN1LfO3GQBN2y9Oox03BPEP/yGEDK9XTn+3e+zZD2ZJods nn6g== 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 :content-transfer-encoding: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=9lLhxlueu90s2s1RIpUMwu4u7a4JDvCpEGK70EVw8nM=; b=YrSKI2QDSAyeSjYncyAcj9C6kFWeGkSz/MlByDQPOyaqt5+Bm9ZCd3BV0dDGE0d7Rm TKyviito1ohp4iLnKNkhwWYvGpLvYKg/3xxjd7/D62JI3UaUfLUwc/9MV1IaFNYNfqtK NISM0E6ZDnwZ96Qt/P1YH0JYND8Tmtq28kZ//M29QwLh3YcMM3rEsPsuIJ3Xtr7JIlRe F6sx6nPgYJf2ncxIZmxtzNNs0jWhYH57kyY8wPKHKYklbCY0DKzI08NoestJVCaNznXw oEcwkKOiQewXLjZ8uPCiEq5E2eHKvbmdvlq/R+62MKyuORDYZFD705QRhL9acaCw/1Ih tYkQ== X-Forwarded-Encrypted: i=2; AJvYcCXYfRyM3sHVc5VVjt/94EWmcysd7lZQtCjKM846Ztm8u4igQhU9FECwPd6C/FccYXprRdqnjm/6ho3M@gnusha.org X-Gm-Message-State: AOJu0Yz1tUcIqc3LcK1eIa0wAXD0BiGIhyXMYzpx38bWJ+kRyS8zUeUX GOUK5FxzRTOpfEsihI9OB0nXFhUrz+ukvTA0iYddCGoRSn1S3H6k X-Google-Smtp-Source: AGHT+IEo+mXFVbtyVqG0cJjbHI+kVDALtd6Q7W71z5WtRt3wORhxBlqnMRZhabAaKZIngsBsJiG1HA== X-Received: by 2002:ad4:4ea9:0:b0:6e8:ede1:237 with SMTP id 6a1803df08f44-6eed630ca62mr139916056d6.43.1743454227436; Mon, 31 Mar 2025 13:50:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAKB2EMiTVAT6BDPEHqkzlQE3+F5Zg12YFf6JMUQvMaiPw== Received: by 2002:a0c:e842:0:b0:6dd:9013:f38f with SMTP id 6a1803df08f44-6ed2326ad4cls57357286d6.1.-pod-prod-09-us; Mon, 31 Mar 2025 13:50:24 -0700 (PDT) X-Received: by 2002:a05:620a:4449:b0:7c5:4d2e:4d2d with SMTP id af79cd13be357-7c69088f380mr1730007485a.50.1743454224571; Mon, 31 Mar 2025 13:50:24 -0700 (PDT) Received: by 2002:a05:600c:3acd:b0:43c:fd8b:faa8 with SMTP id 5b1f17b1804b1-43d783ec5b7ms5e9; Mon, 31 Mar 2025 08:29:18 -0700 (PDT) X-Received: by 2002:a5d:47c6:0:b0:391:20ef:6300 with SMTP id ffacd0b85a97d-39c12118deamr7738980f8f.37.1743434955504; Mon, 31 Mar 2025 08:29:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1743434955; cv=none; d=google.com; s=arc-20240605; b=gL4w3/ZJnWTnyFNWaQt1t5C+r+HDxEq/v8qEzYb9VZBkB3+w2vwY4tliSS6WsFTZzS nukgA8Sjykevb3znERZK+tdZkRlDgD9/PJEGq4eQCfFKPLMbTCZfPlLfmEThFzyzKP+r 3LH8WzZAcDWlQIozHz7m+xZrfO488v+3z0k2tSbzGnbqZk6F8Rm2N7PDDRbZdkKniwbC ullEH9Up5CsxAb1OATwOmDPKcyavyZ04uf+luPH1ZE8n1lEGh7i+bDxHnRMdWoUpakqH Kent0cqQMDh1D6+PnKT7Mf6V3l/1ZUDUuQKY6Cs/25yKOBHWuHhfYMW9sgYlNqUG9oqS jfuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=/YJpHfm0TvO+LOUr6pdWzQ7gJjrmnCpdr5YthAHCKC0=; fh=vfPP9iqpsn+L6IpDObIz3VSXaC72IQB5ATjaiPEmUGA=; b=eCvXebWCotKDgxIh8O8+694nXWra6zRtFBfrsF+4J97Pn50hx2ckzI2dX3PcdJ39cY bT2v4nV6Lu5pPcz1BSkFbSV0FjkuGdQowY0DKTzBN08t0fIdP+JsdTrGJsqFzid094aD Jj94/hkbokvDyO4AVHciQwNDYtftmPk/C0UgSWeS2DPD9YK2H3/z/iOdEeXNQCXKlYo7 nYIDv2FzEaxBE6GiTTmq/tk7k3yc78txUKqO9Ug8Tlb/OyiS2DwpL4sRefEVCrg0+OtF 27FGEK78UslXaymvGGZKE+xxZSPOCKSLyjt9p8jaMR9I8WwI/72MnzGFLy3pKEpu2IKD KLGQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=pH9zp9VL; 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-43d914f14ccsi1204205e9.1.2025.03.31.08.29.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Mar 2025 08:29:15 -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: Mon, 31 Mar 2025 15:29:11 +0000 To: eric@voskuil.org From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: 'Bitcoin Development Mailing List' Subject: RE: [bitcoindev] Consensus Cleanup BIP draft Message-ID: In-Reply-To: <065901dba01b$2164fff0$642effd0$@voskuil.org> References: <065901dba01b$2164fff0$642effd0$@voskuil.org> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 85d21e3d0787441b321996b07e38ee66493e585d MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=pH9zp9VL; 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 (-) Hi Eric, Thanks for chiming in. > This kind of discontinuity always comes back to bite eventually. That con= cern should not be dismissed so casually. I don't think i've dismissed your concern when you brought this up last yea= r. In fact i link to my summary of arguments on both sides of this debate i= n the BIP: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710= /41. > But more to the point, it does not solve any of the problems that were or= iginally provided as justification, apart from making it slightly simpler t= o implement an SPV wallet (no need to get the coinbase tx). I did provide an incorrect motivation at some point (caching), and apprecia= te your correction on this. But the main original motivation for invalidati= ng 64 bytes transactions was always to get rid of the footgun for SPV verif= iers. For instance see Matt's original BIP: https://github.com/TheBlueMatt/= bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki#discu= ssion. And as Sjors points out SPV verifiers shouldn't be reduced to only SPV wall= ets. > If people agree that this is a worthwhile trade, I'm not going to lose an= y sleep over it. This is my position and the reason why i included it in my BIP. Of course i= ntroducing this discontinuity is pretty ugly. I just believe it's less bad = than keeping the weakness that 64 bytes transaction introduce. I am also not married to the idea. In fact, i think it's one of the less im= portant fixes from the proposal. But as things stand i think it's preferabl= e to include it. Of course i am happy to reconsider in the face of new argu= ments and/or data. Best, Antoine On Friday, March 28th, 2025 at 3:53 PM, eric@voskuil.org = wrote: >=20 >=20 > Hi Jeremy, >=20 > > 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 con= dition. >=20 >=20 > I tend to agree. This kind of discontinuity always comes back to bite eve= ntually. That concern should not be dismissed so casually. >=20 > But more to the point, it does not solve any of the problems that were or= iginally provided as justification, apart from making it slightly simpler t= o 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 be= lieve that it was fully accepted that the only justification is this SPV qu= estion. There are no issues of security or performance for any code, and no= t even a code simplification for a node. It's a new consensus rule that cre= ates this discontinuity - only to make an SPV wallet very slightly easier t= o implement. 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. B= ut I don't like seeing arguments about consensus being based on implementat= ion details - especially when they are flawed. It feels very much to me tha= t this is what got this issue going (the several rejected arguments about n= ode performance and simplification), and may be in part what's still drivin= g it. >=20 > I ACK the single activation concept, but don't accept that a rule should = be deployed that would not stand on its own justification. >=20 > Also, I do appreciate the work that Antoine and others have done on the s= et of issues overall. >=20 > Best, > Eric >=20 > > On Thursday, March 27, 2025 at 3:36:13=E2=80=AFPM UTC-4 Antoine Poinsot= wrote: > >=20 > > Hi Chris, > >=20 > > 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 i= t would > > be counterproductive as it would create more churn, invite bikeshedding= and > > overall impede progress on this proposal. > >=20 > > 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. > >=20 > > Those BIPs had much more content to them. The specifications of the > > Consensus Cleanup is trivial in comparison: they fit in less than a doz= en 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 unnecessary overh= ead. > >=20 > > if one of the proposed changes turns out to be controversial, > > we could remove it without holding up the rest of the improvements. > >=20 > > 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 research= ed and > > discussed at length by multiple people over the past year gives me conf= idence > > to move forward with every single one of those. Otherwise i would not h= ave > > proposed this BIP in the first place. > >=20 > > Now, even if somehow we should drop one of the mitigations from > > the proposal, having them in separate BIPs does not make that any easie= r. > >=20 > > More active contributors to the project may have stronger > > opinions on the best approach there. > >=20 > > Yes. > >=20 > > Best, > > Antoine > >=20 > > [0] > > https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpq > > btbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6- > > HdOnamw7tUrMtmXc=3D@protonmail.com > >=20 > > On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart > > stewart....@gmail.com wrote: > >=20 > > Hi Antoine, > >=20 > > First off, concept ACK. My concerns are procedural rather than > > objections to the individual security fixes themselves. > >=20 > > The "Great Consensus Cleanup" is a fantastic brand for > > communicating these protocol changes to non-technical users. However, s= ince > > this is a technical forum and we are producing BIPs intended for techni= cal > > audiences, I believe we should document these changes in separate BIPs. > >=20 > > The proposed security fixes are largely unrelated from a > > technical standpoint: > >=20 > > 1. Timewarp attack mitigation > >=20 > > 2. Worst-case block validation constraints > >=20 > > 3. Disallowing 64-byte transactions > >=20 > > 4. Avoiding duplicate transactions > >=20 > > We should absolutely retain the "Great Consensus Cleanup" > > branding while independently documenting each security enhancement. > >=20 > > 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 tog= ether. > > 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., BIP14= 1 and BIP143 in > > Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the commun= ity > > reaches consensus, we can still deploy all these changes together, even= if they > > are documented separately. > >=20 > > This approach also provides flexibility: if one of the proposed > > changes turns out to be controversial, we could remove it without holdi= ng up > > the rest of the improvements. Additionally, once these fixes are deploy= ed, > > there will likely be significant research and documentation to incorpor= ate, and > > maintaining independent BIPs will make it easier to manage that growth. > >=20 > > 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 s= tronger > > opinions on the best approach there. > >=20 > > -Chris > >=20 > > ________________________________ > >=20 > > On Wed, Mar 26, 2025 at 1:23=E2=80=AFPM 'Antoine Poinsot' via > > Bitcoin Development Mailing List bitco...@googlegroups.com wrote: > >=20 > > Hi everyone, > >=20 > > 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. > >=20 > > The BIP draft can be found here: > > https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md > >=20 > > 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. > >=20 > > 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. > >=20 > > Antoine Poinsot > >=20 > > [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 > >=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 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. > >=20 > > -- > > 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 > > mailto:bitcoindev+unsubscribe@googlegroups.com . > > To view this discussion visit > > https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-99c2- > > 279173a440f3n%40googlegroups.com > > > 279173a440f3n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfo > > oter> . >=20 >=20 >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/065901dba01b%242164fff0%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/= xusxPfCMTmIMZ4dvGoG4SvPH3kg1vFSq3Hrk0GFHVKJCSC9aojyeyY6fUkwq_3PRhiHowSrT3B2= KbJXMT6PENmOH1dvwYve8ofwZSN6QpKc%3D%40protonmail.com.