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. -- Prayank A3B1 E430 2298 178F
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
