Delivery-date: Fri, 28 Mar 2025 07:34:48 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.148 as permitted sender) client-ip=103.168.172.148;
Feedback-ID: ie5e042df:Fastmail
From: Sjors Provoost <sjors@sprovoost.nl>
Message-Id: <80010585-E209-4042-B6F6-5B7DC6675247@sprovoost.nl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F7C3566E-7D82-43C9-9278-33927ADD801E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [bitcoindev] Consensus Cleanup BIP draft
Date: Fri, 28 Mar 2025 13:48:41 +0100
In-Reply-To: <CAGL6+mE8JQGJErgJH03sz8Nzo+wkgx74jgFWp7hFT0MuHiPg_g@mail.gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
 jeremy <jeremy.l.rubin@gmail.com>
To: Chris Stewart <stewart.chris1234@gmail.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>
 <17A67D4A-3EF4-4676-8356-B1DE6B0C2D8D@sprovoost.nl>
 <CAGL6+mE8JQGJErgJH03sz8Nzo+wkgx74jgFWp7hFT0MuHiPg_g@mail.gmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--Apple-Mail=_F7C3566E-7D82-43C9-9278-33927ADD801E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hi Chris,

Thanks for that example.

I also realised that there indeed can exist 64 byte transactions that can't=
 be malleated into a different size (see Stack Exchange link below). The ex=
ample uses SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, so as long as our hypothe=
tical smart contracting system uses those flags for its burn-all / giveaway=
-all clauses, then if it produces a 64 byte transaction by mistake, it's re=
coverable.

But a SIGHASH_ALL could get stuck (can't be confirmed, can't be modified). =
And IIUC with OP_CTV even a SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, once com=
mitted inside a CTV tree, can't be modified.

- Sjors

> Op 28 mrt 2025, om 12:02 heeft Chris Stewart <stewart.chris1234@gmail.com=
> het volgende geschreven:
>=20
> Hi Sjors,
>=20
> An example is any segwit transaction that 1 input 1 output that pays to a=
 2 byte witness program. Since witness data doesn't count towards the 64 by=
te limit, the witness could be of arbitrary size. This was pointed out <htt=
ps://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/74?u=3Dchris_=
stewart_5> by garlonicon <https://delvingbitcoin.org/u/garlonicon> on delvi=
ngbitcoin. This type of witness program is used for pay-to-anchor outputs c=
urrently - although I don't believe anchor outputs make sense in a 1 input =
1 output transaction? The author of pay to anchor outputs is aware of this =
issue <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/78?=
u=3Dchris_stewart_5>, but I haven't heard of any further updates since his =
post on delving.
>=20
> -Chris
>=20
> On Fri, Mar 28, 2025 at 4:25=E2=80=AFAM Sjors Provoost <sjors@sprovoost.n=
l <mailto:sjors@sprovoost.nl>> wrote:
>>=20
>> > Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail.com <mailt=
o:jeremy.l.rubin@gmail.com>> het volgende 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 cond=
ition.
>>=20
>> Do you have an example in mind where a 64-byte transaction could appear =
in such a system?
>>=20
>> Given the limited space, in particular no room for a public key or signa=
ture, I could imagine a burn or anyone-can-spend clause. Those don't have t=
o be exactly 64 bytes. Even if 64 byte transactions are generated by accide=
nt, I believe they can be tweaked after the fact (though that claim could u=
se more scrutiny):
>>=20
>> https://bitcoin.stackexchange.com/q/125971/4948
>>=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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
80010585-E209-4042-B6F6-5B7DC6675247%40sprovoost.nl.

--Apple-Mail=_F7C3566E-7D82-43C9-9278-33927ADD801E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; -webkit-nbsp-mod=
e: space; line-break: after-white-space;">Hi Chris,<div><br></div><div>Than=
ks for that example.</div><div><br></div><div>I also realised that there in=
deed can exist 64 byte transactions that can't be malleated into a differen=
t size (see Stack Exchange link below). The example uses&nbsp;SIGHASH_SINGL=
E | SIGHASH_ANYONECANPAY, so as long as our hypothetical smart contracting =
system uses those flags for its burn-all / giveaway-all clauses, then if it=
 produces a 64 byte transaction by mistake, it's recoverable.</div><div><br=
></div><div>But a SIGHASH_ALL could get stuck (can't be confirmed, can't be=
 modified). And IIUC with OP_CTV even a SIGHASH_SINGLE | SIGHASH_ANYONECANP=
AY, once committed inside a CTV tree, can't be modified.</div><div><br></di=
v><div>- Sjors</div><div><div><br><blockquote type=3D"cite"><div>Op 28 mrt =
2025, om 12:02 heeft Chris Stewart &lt;stewart.chris1234@gmail.com&gt; het =
volgende geschreven:</div><br class=3D"Apple-interchange-newline"><div><div=
 dir=3D"ltr"><div>Hi Sjors,</div><div><br></div><div>An example is any segw=
it transaction that 1 input 1 output that pays to a 2 byte witness program.=
 Since witness data doesn't count towards the 64 byte limit, the witness co=
uld be of arbitrary size. This was <a href=3D"https://delvingbitcoin.org/t/=
great-consensus-cleanup-revival/710/74?u=3Dchris_stewart_5">pointed out</a>=
 by <span class=3D"gmail-first gmail-username"><a href=3D"https://delvingbi=
tcoin.org/u/garlonicon" class=3D"gmail-">garlonicon</a> on delvingbitcoin. =
This type of witness program is used for pay-to-anchor outputs currently - =
although I don't believe anchor outputs make sense in a 1 input 1 output tr=
ansaction? The author of pay to anchor outputs is <a href=3D"https://delvin=
gbitcoin.org/t/great-consensus-cleanup-revival/710/78?u=3Dchris_stewart_5">=
aware of this issue</a>, but I haven't heard of any further updates since h=
is post on delving.</span></div><div><span class=3D"gmail-first gmail-usern=
ame"><br></span></div><div><span class=3D"gmail-first gmail-username">-Chri=
s</span></div></div><br><div class=3D"gmail_quote gmail_quote_container"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 28, 2025 at 4:25=E2=80=AFAM=
 Sjors Provoost &lt;<a href=3D"mailto:sjors@sprovoost.nl">sjors@sprovoost.n=
l</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><br>
&gt; Op 27 mrt 2025, om 21:45 heeft jeremy &lt;<a href=3D"mailto:jeremy.l.r=
ubin@gmail.com" target=3D"_blank">jeremy.l.rubin@gmail.com</a>&gt; het volg=
ende geschreven:<br>
&gt; <br>
&gt; 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 cond=
ition.<br>
<br>
Do you have an example in mind where a 64-byte transaction could appear in =
such a system?<br>
<br>
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):<br>
<br>
<a href=3D"https://bitcoin.stackexchange.com/q/125971/4948" rel=3D"noreferr=
er" target=3D"_blank">https://bitcoin.stackexchange.com/q/125971/4948</a><b=
r>
<br></blockquote></div></div></blockquote></div><br></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/80010585-E209-4042-B6F6-5B7DC6675247%40sprovoost.nl?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
80010585-E209-4042-B6F6-5B7DC6675247%40sprovoost.nl</a>.<br />

--Apple-Mail=_F7C3566E-7D82-43C9-9278-33927ADD801E--