Is there a reason why people are pushing CTV currently over TXHASH? It seems like the second is strictly more flexible and I haven’t seen a reason why we should prefer not-that. Maybe nostr:nprofile1qqs2nep2pjnwfvfqszytdzj06eq8fqd3yps0j9dqlm95ezr524lrwjgpzfmhxue69uhk7enxvd5xz6tw9ec82cspr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqvgfg4m ?

Reply to this note

Please Login to reply.

Discussion

Probably because its easier to reason about the potential footguns

For a dev? Not really, CTV is a special-case of TXHASH, if you want CTV you can use that mode.

But in a softfork is not only the devs is also the economic nodes and the miners. It probably is way easier to do CTV and CSFS. I find it more understandable than txhash in general.

Huh? TXHASH is way more understandable - you have some flag bits and you hash those parts of the transaction. CTV is a very specific version of that and you have to understand whether it’s the “right” one.

Not clear that flexibility is a good thing.

In the abstract, sure. But specifically in this case? The whole point of CTV was it being “not recursive”, but with CSFS it kinda is, and more importantly no one seems to actually want to avoid recursion (and now it’s not even in the BIP).

So? CTV is still objectively a lot simpler.

Forks in general have substantial cost by their nature. If we’re gonna do one to add features for these types of applications, it seems worth doing one to add Features for these types of applications. Just because one is a restricted version of another isn’t a strong argument to prefer it (unless the other is unreviewably or unusably complicated, neither of which applies here)

IMO there's two parts to this. First is that CTV is relatively way more mature. Been around for a while and hasn't changed much since. So it can be adopted fast. TXHASH still has quite some room for bike-shedding.

Second is complexity. While TXHASH is way more flexible it's also an order of magnitude more complex, mostly code-wise. Needs quite some caching etc, so the code is far from trivial.

That being said, it seems that TXHASH together with CSFS enables APO in a more secure way (than CTV) and with APO, txid stability is already far less important. Which also means that indigenous fees could be a thing maybe.

> First is that CTV is relatively way more mature. Been around for a while and hasn't changed much since. So it can be adopted fast. TXHASH still has quite some room for bike-shedding.

This seems like a pretty bad reason to decide on a specific soft fork that we’re committing to for decades, at least when the second option isn’t like crazy complicated and would require a five years of work to “finish”.

> While TXHASH is way more flexible it's also an order of magnitude more complex, mostly code-wise. Needs quite some caching etc, so the code is far from trivial.

Honestly this doesn’t seem that complex? Some tx hash caching already exists so adding a few more cache entries seems…. Incredibly doable?

Honestly these seem like incredibly weak reasons (not saying they’re not the reason, just that if they are, we should choose a different path).

apparently "just expressing what you want to do" is too much for bitcoiners

Hmm?