Hi Michael,

> If OP_CTV is ready to go now and has overwhelming community support (I don’t 
> think either is true) it should surely have been included in the Taproot soft 
> fork (perhaps delayed) rather than going through the months of activation 
> wrangling and community outreach twice.

It should be ready to go in a few months IMO and makes no sense to bundle 
everything with Taproot soft fork. Things can remain separate and still 
considered good enough based on the changes proposed.

> It should be made clear to any individual(s) that attempt this of the knock 
> on impacts and potential short term damage they are inflicting on the entire 
> ecosystem.

I don't see any damage with a soft fork that is being discussed since years, 
documented properly, includes code for implementation and examples, recently 
got crowdfunding to incentivize review process and improve security.

> It seems to me like the author and primary promoter of this proposal (Jeremy 
> Rubin) is pushing for an imminent attempted activation of a soft fork 
> containing exclusively OP_CTV [2].

He is doing nothing unexpected and got reasons to support OP_CTV being 
implemented soon.

> To contrast with his approach, the authors and contributors of another future 
> soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an 
> imminent soft fork activation attempt and instead are building out and 
> testing one of the speculated use cases, eltoo payment channels [4].

Because its not ready?

> Similar work has not been done for any of the speculated use cases of OP_CTV.

There is no comparison between the two. If someone has worked on one of the 
speculated uses cases, it makes no difference.

If we still compare something because of our bias, maybe Sapio is something 
that would be more helpful for Bitcoin developers.

> Instead Jeremy is encouraging people to “soft signal” for soft fork 
> activation of OP_CTV presumably in the hope that the building out and testing 
> of use cases can be completed post activation.

We had soft signals from mining pools for Taproot as well and still waiting for 
projects to use Taproot. Even miners signaling with speedy trial was not a 
guarantee they would follow new consensus rules later. I don't see anything 
wrong in looking for people who support a proposal and documenting it.

> This is totally irresponsible in my view. A long list of speculated use cases 
> means nothing on its own. I can propose a new opcode OP_MAGIC and claim it 
> will cure cancer with no potential downsides and hence we should have a soft 
> fork activating it as soon as possible.

If I had to select between a soft fork without any use cases and one with use 
cases, I would go with the one that has some use cases with code, documentation 
etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.

> I would hope there would be sufficient skepticism that this proposal wouldn’t 
> see the light of day.

I am confident this proposal will be used by lot of Bitcoin projects and 
improve privacy, security, decentralization, demand for block space etc.

> I feel the top priority is to bring some attention to the danger of us 
> stumbling into an attempted contentious soft fork activation attempt.

I feel the danger is a few people able to stop soft forks that improve Bitcoin 
because of their bias and opinions which are mostly non-technical.

> Enabling covenants on Bitcoin is a big step change with barely any existing 
> research on the topic and attempting to rush it through by the back door so 
> soon after Taproot activation should be resisted.

Nobody has stopped anyone from doing research. There is no backdoor and 
everything is public. So soon? I am not sure if there are any issues with a 
soft fork in next few months if its ready.


A3B1 E430 2298 178F
bitcoin-dev mailing list

Reply via email to