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