From: Chris Stewart <stewart.chris1234@gmail•com>
To: Sjors Provoost <sjors@sprovoost•nl>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
jeremy <jeremy.l.rubin@gmail•com>
Subject: Re: [bitcoindev] Consensus Cleanup BIP draft
Date: Fri, 28 Mar 2025 08:54:52 -0500 [thread overview]
Message-ID: <CAGL6+mHuVgWc9ATjRnBz+b7SJyz84La8q9jeM=yiw-Anh=a3ag@mail.gmail.com> (raw)
In-Reply-To: <80010585-E209-4042-B6F6-5B7DC6675247@sprovoost.nl>
[-- Attachment #1: Type: text/plain, Size: 4179 bytes --]
*Hi Sjors,*
Sorry to be a bit pedantic here, but I think this distinction is important.
Are you referring to a pre-SegWit transaction or a SegWit transaction? It’s
crucial to analyze these separately, as SegWit was designed to solve
transaction malleability, which affects how we assess backward
compatibility concerns when disallowing 64-byte transactions.
In the future, it would be helpful to explicitly specify “pre-segwit” or
“segwit” when discussing potential transactions. In my draft BIP
<https://github.com/bitcoin/bips/blob/a3d12410d3e3361932e44f34f8420331cf5f9b59/bip-XXXX.mediawiki#backward-compatibility>,
I differentiate between these two types when evaluating the backward
compatibility risks of disallowing 64-byte transactions. Additionally, as I
mentioned earlier (and as I believe Jeremy has also raised concerns about),
there are potential *future* compatibility issues with segwit transactions.
I'll take a closer look at the Stack Exchange examples and share my
thoughts there when I have a bit of time.
Thanks for diving into this in detail—I really appreciate it.
*- Chris*
On Fri, Mar 28, 2025 at 7:48 AM Sjors Provoost <sjors@sprovoost•nl> wrote:
> 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 example uses SIGHASH_SINGLE | 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.
>
> 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
> committed 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:
>
> 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 <sjors@sprovoost•nl> wrote:
>
>>
>> > Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail•com> 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
>>
>>
>
--
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.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmHuVgWc9ATjRnBz%2Bb7SJyz84La8q9jeM%3Dyiw-Anh%3Da3ag%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5742 bytes --]
next prev parent reply other threads:[~2025-03-28 14:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 17:14 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-27 10:46 ` Chris Stewart
2025-03-27 17:54 ` /dev /fd0
2025-03-27 19:05 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-27 20:45 ` jeremy
2025-03-27 21:38 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-28 9:23 ` Sjors Provoost
2025-03-28 11:02 ` Chris Stewart
2025-03-28 12:48 ` Sjors Provoost
2025-03-28 13:54 ` Chris Stewart [this message]
2025-03-28 14:07 ` Sjors Provoost
2025-03-28 19:53 ` eric
2025-03-29 11:02 ` Sjors Provoost
2025-03-31 11:00 ` Anthony Towns
2025-03-31 15:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-31 20:09 ` eric
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGL6+mHuVgWc9ATjRnBz+b7SJyz84La8q9jeM=yiw-Anh=a3ag@mail.gmail.com' \
--to=stewart.chris1234@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=jeremy.l.rubin@gmail$(echo .)com \
--cc=sjors@sprovoost$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox