Delivery-date: Fri, 28 Mar 2025 17:03:08 -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::f29;
From: <eric@voskuil.org>
To: "'jeremy'" <jeremy.l.rubin@gmail.com>,
	"'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>
In-Reply-To: <afedbc69-8042-4fe8-99c2-279173a440f3n@googlegroups.com>
Subject: RE: [bitcoindev] Consensus Cleanup BIP draft
Date: Fri, 28 Mar 2025 15:53:51 -0400
Message-ID: <065901dba01b$2164fff0$642effd0$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHWtHeW1eEx0HT2gtpWV+YJenkSdAJggGU8AIKIJN0B5cf6jLNsgZQQ
Content-Language: en-us
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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 condi=
tion.

I tend to agree. This kind of discontinuity always comes back to bite event=
ually. That concern should not be dismissed so casually.

But more to the point, it does not solve any of the problems that were orig=
inally provided as justification, apart from making it slightly simpler to =
implement an SPV wallet (no need to get the coinbase tx). This was discusse=
d 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 ques=
tion. There are no issues of security or performance for any code, and not =
even a code simplification for a node. It's a new consensus rule that creat=
es this discontinuity - only to make an SPV wallet very slightly easier to =
implement. There is no other benefit whatsoever. I want to emphasize this b=
ecause in the discussion it still seems that people may be holding on to th=
e idea that it provides some other benefit - it doesn't. If people agree th=
at this is a worthwhile trade, I'm not going to lose any sleep over it. But=
 I don't like seeing arguments about consensus being based on implementatio=
n details - especially when they are flawed. It feels very much to me that =
this is what got this issue going (the several rejected arguments about nod=
e performance and simplification), and may be in part what's still driving =
it.

I ACK the single activation concept, but don't accept that a rule should 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 Poinsot w=
rote:
>=20
>=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 it =
would
> be counterproductive as it would create more churn, invite bikeshedding a=
nd
> overall impede progress on this proposal.
>=20
>=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 BI=
P341,
> BIP342, and BIP343 in Taproot.
>=20
>=20
>=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 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 unnecessary overhea=
d.
>=20
>=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
>=20
>=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 researched=
 and
> discussed at length by multiple people over the past year gives me confid=
ence
> to move forward with every single one of those. Otherwise i would not hav=
e
> 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 easier.
>=20
>=20
> 		More active contributors to the project may have stronger
> opinions on the best approach there.
>=20
>=20
>=20
> 	Yes.
>=20
> 	Best,
> 	Antoine
>=20
>=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
>=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, sin=
ce
> this is a technical forum and we are producing BIPs intended for technica=
l
> 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 toget=
her.
> While soft fork deployment is indeed challenging, we've successfully acti=
vated
> 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 communit=
y
> reaches consensus, we can still deploy all these changes together, even i=
f 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 holding=
 up
> the rest of the improvements. Additionally, once these fixes are deployed=
,
> there will likely be significant research and documentation to incorporat=
e, 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 str=
onger
> opinions on the best approach there.
>=20
>=20
>=20
> 		-Chris
>=20
>=20
> ________________________________
>=20
>=20
>=20
>=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
>=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
>=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
> <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
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/=
065901dba01b%242164fff0%24642effd0%24%40voskuil.org.