Delivery-date: Fri, 28 Mar 2025 02:26:05 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.146 as permitted sender) client-ip=103.168.172.146;
Feedback-ID: ie5e042df:Fastmail
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [bitcoindev] Consensus Cleanup BIP draft
From: Sjors Provoost <sjors@sprovoost.nl>
In-Reply-To: <afedbc69-8042-4fe8-99c2-279173a440f3n@googlegroups.com>
Date: Fri, 28 Mar 2025 10:23:52 +0100
Cc: jeremy <jeremy.l.rubin@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <17A67D4A-3EF4-4676-8356-B1DE6B0C2D8D@sprovoost.nl>
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>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


> Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail.com> het volg=
ende geschreven:
>=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 conditi=
on.

Do you have an example in mind where a 64-byte transaction could appear in =
such a system?

Given the limited space, in particular no room for a public key or signatur=
e, I could imagine a burn or anyone-can-spend clause. Those don't have to b=
e exactly 64 bytes. Even if 64 byte transactions are generated by accident,=
 I believe they can be tweaked after the fact (though that claim could use =
more scrutiny):

https://bitcoin.stackexchange.com/q/125971/4948

If we grant that any smart contract system has to engineer around this "war=
d", we should also consider how much engineering effort is saved in other s=
mart contract systems by having simpler SPV proofs.

Imo the real ward is the originally broken Merkle tree design. That has req=
uired a bunch of engineering all over the place to compensate. Afaik it can=
 only be truly fixed with a hard fork. This seems to be as good as it gets =
with a soft fork.

- Sjors

--=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/=
17A67D4A-3EF4-4676-8356-B1DE6B0C2D8D%40sprovoost.nl.