Nostr Web Client

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 ?

Steven Roose 8mo ago

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.

Reply to this note

Please Login to reply.

Discussion

Matt Corallo 8mo ago

> 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).