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.