Delivery-date: Mon, 31 Mar 2025 13:50:34 -0700
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" <bitcoindev@googlegroups.com>
Cc: 'Bitcoin Development Mailing List' <bitcoindev@googlegroups.com>
Subject: RE: [bitcoindev] Consensus Cleanup BIP draft
Message-ID: <xusxPfCMTmIMZ4dvGoG4SvPH3kg1vFSq3Hrk0GFHVKJCSC9aojyeyY6fUkwq_3PRhiHowSrT3B2KbJXMT6PENmOH1dvwYve8ofwZSN6QpKc=@protonmail.com>
In-Reply-To: <065901dba01b$2164fff0$642effd0$@voskuil.org>
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>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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 <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
> > <https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-99c2-
> > 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.