Subject: Re: [bitcoindev] CTV + CSFS: a letter

From: Matt Corallo <[email-masked]>
Date: Mon, 9 Jun 2025 17:12:29 -0400

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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/351b6327-08ab-4c2d-937c-521020978c82%40mattcorallo.com.