Subject: Re: [bitcoindev] Consensus Cleanup BIP draft

From: Chris Stewart <[email-masked]>
Date: Fri, 28 Mar 2025 06:02:46 -0500

Hi Sjors,

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 byte
limit, the witness could be of arbitrary size. This was pointed out
<https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/74?u=chris_stewart_5>
by garlonicon <https://delvingbitcoin.org/u/garlonicon> 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
transaction? The author of pay to anchor outputs is aware of this issue
<https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/78?u=chris_stewart_5>,
but I haven't heard of any further updates since his post on delving.

-Chris

On Fri, Mar 28, 2025 at 4:25 AM Sjors Provoost <[email-masked]> wrote:

>
> > Op 27 mrt 2025, om 21:45 heeft jeremy <[email-masked]> het
> volgende geschreven:
> >
> > 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.
>
> 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
> signature, I could imagine a burn or anyone-can-spend clause. Those don't
> have to be 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
> "ward", we should also consider how much engineering effort is saved in
> other smart contract systems by having simpler SPV proofs.
>
> Imo the real ward is the originally broken Merkle tree design. That has
> required 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
>
> --
> 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 [email-masked].
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/17A67D4A-3EF4-4676-8356-B1DE6B0C2D8D%40sprovoost.nl
> .
>

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmE8JQGJErgJH03sz8Nzo%2Bwkgx74jgFWp7hFT0MuHiPg_g%40mail.gmail.com.