Re: [bitcoindev] CTV + CSFS: a letter

["/dev /fd0" <alicexbtong@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6315 bytes --]

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.

> 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. 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.
2. State carrying UTXOs will bloat the UTXO set.
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.

[0]:
https://github.com/bitcoin/bips/blob/debd349e6181d949cbea0691fcc0d67b265b02a8/bip-0346.md
[1]: https://en.bitcoin.it/wiki/Covenants_support

/dev/fd0
floppy disk guy

On Mon, Jun 9, 2025 at 11:23 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

>
>
> On 6/9/25 10:43 AM, James O'Beirne wrote:
> > On Mon, Jun 9, 2025 at 9:51 AM Matt Corallo <lf-lists@mattcorallo.com
> <mailto:lf-
> > lists@mattcorallo.com>> wrote:
> >  > That said, I have yet to see a reasoned explanation of why we should
> prefer CTV over TXHASH.
> >
> >  From the author of TXHASH himself on Delving Bitcoin
> > (
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-
> > covenants/1509/15 <
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-
> > towards-covenants/1509/15>):
> >
> >  > Having implemented TXHASH, I would definitely not say that
> >  > it “simplifies the change”.
>
> Who claimed TXHASH is simpler than CTV?
>
> >  > The difference in both technical debt and
> >  > potential for bugs is an order of magnitude bigger for TXHASH than for
> >  > CTV.
>
> 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.
>
> >  > (Not to say that I don’t think TXHASH would be worthwhile, but I
> >  > will definitely say that it has not received the attention I had
> expected,
> >  > so I would definitely not want to put it on the table anytime soon.)
>
> I mean there's still debate around the exact format of CTV commitments (eg
> whether it commits to
> scriptSigs, if it works outside of segwit, etc), saying that there's
> debate over the format of
> TXHASH isn't exactly a compelling argument either? Yes, it needs some
> work, but the time we'll
> invest in CTV isn't all that different from the time we'll invest in
> TXHASH, once we pick a direction.
>
> > The use-cases that might merit such a jump up in complexity over CTV
> > have not been enumerated to my knowledge.
>
> 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.
>
> Further, we should think at least somewhat about what we think a
> reasonable end state is. As far as
> I understand, most proponents of CTV+CSFS do not think that CTV+CSFS is
> *all* we want, but rather a
> first step towards some goal. 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!
>
> > CTV also includes
> > upgrade hooks to incorporate modifications should these additional
> > uses be more fully understood.
>
> 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 :).
>
> These really feel like the same arguments again and again. I just don't
> find them even remotely
> compelling. "Oh, well, if we want to figure out TXHASH someone would have
> to define a bitfield
> format and that will take years" is just nonsense. Hell, its already done!
> Maybe we want to tweak
> it, but honestly bikeshedding over a specific bitfield format sounds like
> it'll take a hell of a lot
> less time than trying to make sure we work out all the cases for what
> someone might want to commit
> to that we want them to commit to but not more and fix a specific set of
> commitments!
>
> 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/01f49d64-838e-4311-bf79-8c4130b40c8e%40mattcorallo.com
> .
>

-- 
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/CALiT-ZqWjPM-dhAUfahG5AgNfQbLhn2Aa4%2BeLcrpugU4eZ4_vA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 8177 bytes --]