From: Matt Corallo <lf-lists@mattcorallo•com>
To: /dev /fd0 <alicexbtong@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
Date: Mon, 9 Jun 2025 17:12:29 -0400 [thread overview]
Message-ID: <351b6327-08ab-4c2d-937c-521020978c82@mattcorallo.com> (raw)
In-Reply-To: <CALiT-ZqWjPM-dhAUfahG5AgNfQbLhn2Aa4+eLcrpugU4eZ4_vA@mail.gmail.com>
Note that you can always reply inline, you don't have to copy and paste quotes, your email client
will do that for you :)
On 6/9/25 3:27 PM, /dev /fd0 wrote:
> Hi Matt,
>
> > I mean, sure, compared to something trivial doing something marginally-trivial has a lot bigger
> > surface area. But that isn't really an argument unless we're talking about something truly
> > complicated, and TXHASH absolutely is not.
>
> If you are referring to [BIP 346][0], it is not /marginally/ trivial compared to BIP 119.
> TxFieldSelector makes it super complex. That's without even considering the possibilities when
> combined with CSFS.
The "marginally-trivial" comment was not in comparison to, rather in the general sense. taking
hashes of various parts of the transaction based on a discriminator (with intermediate hashes and
caching to avoid hashed-data blowups) is absolutely marginally-trivial in the context of recent soft
fork complexity.
> > If that goal includes more flexible tx field commitments (I imagine it
> > certainly does!) then we should do that, rather than taking a detour we should make progress towards
> > the eventual goal!
>
> Sometimes the goal is easier to achieve through multiple steps with BIP 119 being the first step in
> this case.
I believe you missed my comment addressing this specifically in the email you're replying to, let me
paste it here:
> I do not understand why people make this argument. Yes, the encoding of the opcode allows you to
turn it into an OP_NOP (or SUCCESS or whatever), that doesn't make it "upgrade hook"-friendly. If we
think that we just want to do CTV but we want CTV to be upgradable later to be TXHASH, then we first
need to define the TXHASH hash and bitfield format, so that we can take the subset of it that
captures CTV and hard-code that. But, of course, if we do that work we should clearly do TXHASH 🙂.
> There are several reasons to prefer BIP 119 over BIP 346, and I have listed some of them
> below, based on rationales shared in the [covenants support wiki][1]:
>
> 1. All the possible configurations need to be tested.
I mean....okay? Yes? And? Come on, this isn't a lot of work.
> 2. State carrying UTXOs will bloat the UTXO set.
State carrying UTXOs will bloat the UTXO set worse if its done via BitVM/GC? Come on...
> 3. BIP 346 could be activated in 2030 or later, once we better understand how people are actually
> using covenants. This approach would be based on real-world usage rather than premature optimization
> without sufficient data.
This is similar to the argument I was replying to which you replied to here, and I think my original
response still stands and wasn't responded to at all:
> This is a much better argument 🙂. I'm a bit skeptical, though, that its quite this cut-and-dry.
For example, the utter hack of the BitVM-with-CTV variant pretty clearly points to us needing a more
fully featured commitment gadget to enable these things without the nonsense they had to resort to.
IOW, we have concrete use-cases already for TXHASH-over-CTV (at least in the sense that it would
simplify things that are currently very hacky), and if it avoids a future soft fork by just enabling
the full set of things today vs some narrow subset, I don't see why we shouldn't take on the extra
month of work.
Matt
--
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/351b6327-08ab-4c2d-937c-521020978c82%40mattcorallo.com.
next prev parent reply other threads:[~2025-06-09 21:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 11:40 James O'Beirne
2025-06-09 12:51 ` Michael Folkson
2025-06-09 14:41 ` James O'Beirne
2025-06-09 15:56 ` Michael Folkson
2025-06-09 13:51 ` Matt Corallo
2025-06-09 14:43 ` James O'Beirne
2025-06-09 17:51 ` Matt Corallo
2025-06-09 19:27 ` /dev /fd0
2025-06-09 21:12 ` Matt Corallo [this message]
2025-06-09 18:55 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-10 2:02 ` Paul Sztorc
2025-06-09 23:02 ` Andrew Poelstra
2025-06-10 2:08 ` David A. Harding
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=351b6327-08ab-4c2d-937c-521020978c82@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=alicexbtong@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/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