Thanks for writing this. My personal view on the topic is that we should change Bitcoin’s consensus rules if we have a good reason to, but only if we do. I would like to offer some push backs and explain why i don’t think a CTV+CSFS meets the bar we should set for ourselves for a soft fork.
This is actually the main selling point of CTV in my opinion. Interactivity reduction is often underappreciated.
It would be useful to get some statement on the matter from active contributors to the Lightning specifications. What i heard from some people there is that Eltoo might be nice for (far) future stuff, like multiparty channels. But would not be close to a priority for the moment, where all resources are currently allocated to features demanded by users that can be implemented today (including some made possible by the last soft fork but not yet implemented).
This is pretty vague. What are concrete examples of applications leveraging those that have any realistic chance of bringing value to Bitcoin end users, should such a soft fork be activated?
If Ark becomes widely used and CTV makes it significantly better, then i think this would be a very convincing argument in favor of a CTV soft fork.
Could you list the benefits of CTV for Ark here, instead of linking to Twitter? This is better for discussion here, future reference, people who don’t have an account there, and for when it’s down like it’s been in the past couple days.
You say both implementations would use CTV as soon as possible beyond any doubt, but it seems the other team stated otherwise on Twitter. (Reference will have to wait until Twitter is back up.) edit: couldn’t find a reference
Bitcoin users don’t seem too interested in DLCs, at all.
Has BitVM seen any adoption from Bitcoin users, either directly or indirectly?
This is misleading to qualify such constructions as “vaults”. Vaults were introduced as a way for Bitcoin users to receive coins on a script such as external payments may be canceled, by enforcing an unvault period whereby external spend are delayed for a configurable amount of time.
The construction described there simply defines a precomputed chain of transaction to spend a UTxO which requires using a hot wallet before making a payment, which kills the purpose of using a ““vault”” if your intention was to protect yourself from your hot wallet being compromised. In addition, this transaction chain requires committing to the amount which is by itself a gigantic footgun. Send too little to the address? Your funds are locked forever. Send too much? The excess is burned to fees. Which makes it so you need to first receive funds on your hot wallet before sending it to this utxo-with-precomputed-chain-of-transactions, and even then make really sure you are not going to burn your funds in doing so.
CTV may be useful to reduce interactivity in some actual vault constructions, but those don’t seem to have much traction in the first place.
In conclusion, from the presented motivations for soft-forking CTV+CSFS today, only one was clearly demonstrated. Reduced interactivity in protocols by replacing presigned transactions with CTV commitments. This seems pretty light on its own for a Bitcoin soft fork.