Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Indicated: No #27

Closed
michaelfolkson opened this issue Dec 30, 2021 · 0 comments
Closed

Support Indicated: No #27

michaelfolkson opened this issue Dec 30, 2021 · 0 comments

Comments

@michaelfolkson
Copy link

I was hoping to avoid "soft signaling" No for CTV as I was looking forward to seeing progress in the coming months and years on various CTV related research topics: vaults, eltoo constructions, payment pools etc. I was also looking forward to exploring these topics in greater depth myself. But rather than doing that my thoughts are turning to what happens when what I believe will be a contentious soft fork activation is attempted most likely at some stage next year.

I fundamentally disagree that the research, experimentation and community understanding is sufficiently advanced to be attempting a soft fork to activate CTV in the coming months which the primary promoter (Jeremy Rubin) of CTV has indicated he will be attempting. This research and experimentation should mature before considering activation especially for new opcodes where all the potential value is in how useful they are for their speculated use cases. A long list of use cases with primitive proofs of concept is not the standard we should be expecting before considering the activation of an opcode (or multiple opcodes). Ignoring the risks of attempting a contentious soft fork, activating an opcode that could end up not being used if turns out alternatives are better is a colossal waste of community time. There is considerable uncertainty currently on whether CTV is the best tool for the job on any of its listed use cases. This work takes time as we are seeing with eltoo using ANYPREVOUT but the answer is not to skip this painstaking work and say we'll figure it out later post activation. This work could end up with changes to the initial soft fork proposal but if that work is left to after activation it is too late.

I also think attempting regular soft forks with single features is a disturbing pattern to get into having just activated Taproot. As I say in the linked post it means less and less community scrutiny of consensus changes, it becomes a full time job to monitor the regular soft forks being activated (or attempting to be activated) and only a tiny minority of the community can dedicate the time to do that.

Hence I'd like to register a "No" soft signal as I fundamentally disagree that a CTV soft fork should be attempted in the near future and my concerns over premature activation outweigh my enthusiasm for digging into the speculated real world use cases of CTV.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants