Delivery-date: Mon, 31 Mar 2025 13:50:34 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: none (google.com: eric@voskuil.org does not designate permitted sender hosts) client-ip=2607:f8b0:4864:20::735;
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
Thread-Index: AQHWtHeW1eEx0HT2gtpWV+YJenkSdAJggGU8AIKIJN0B5cf6jAIQknyBAce1iyezUnjAMA==
Content-Language: en-us
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

> 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.