> It should be ready to go in a few months IMO
What is this assessment based on? I am assuming you haven't done a code review
of the opcode, you haven't coded up a real world use case of OP_CTV (or even a
primitive proof of concept), you haven't thought about alternative proposals
for any particular use case (vaults for example have multiple current
alternative proposals and most likely many future ones). A new programming
language (Sapio) sounds great but do you you need it for your use case rather
than an alternative high level language like Minsc? Sapio makes use of
Miniscript which hasn't been finalized yet or updated for Taproot. Surely that
needs to be done first otherwise Sapio is built on top of something that isn't
ready? When you make the claims such as a consensus change is ready to go the
burden is on you to convince me and other skeptics why. The status quo is the
default. "I think it is ready or will be ready" doesn't mean much unless you
have done the work.
You are well aware of the review process in Core for non-consensus changes. For
consensus changes you really should be digging even deeper, the bar should be
higher and all questions you and others have should be explored in depth. It is
not enough for one individual to say it is ready to be activated, anyone who is
expressing that view should understand why the opcode has been designed in the
way it has and why it is so important that we should dedicate months of
community time to getting a single opcode activated this year.
I have more sympathy for those who don't follow Bitcoin Core development and
Bitcoin Core review on an ongoing basis (note as I said that the bar for
consensus changes should be significantly higher than a non-consensus PR). The
use cases sound cool and the work is genuinely interesting. But honestly for
someone who has followed Bitcoin Core development, review for a while now you
really should know better than bandy around statements like "it should be ready
to go in a few months" when you currently haven't scratched the surface on the
utility and safety of this opcode. You regularly NACK Core PRs yet you seem
willing to wave a consensus change through with no outstanding questions and
zero skepticism.
> 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.
Multiple proven built out use cases, sure. Multiple is better than single when
you have done the work to ensure they are actually the right tool for those
multiple use cases. This work hasn't been done on any of these use cases. The
curing cancer analogy was used to elucidate the point that claims should be
deeply explored rather than just accepted as true.
>> 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?
As I said it is not ready because the ANYPREVOUT contributors are building out
and testing a use case. The high bar on readiness should be applied to all
proposals not merely the ones where the authors/contributors decide to impose a
high bar themselves.
I don't really want to spend my year imploring people to dig deeper on this
before indicating they support an imminent activation attempt. Some people
don't have the understanding to dig deeper, some people don't have the time and
some don't have either. However, if an activation of OP_CTV is attempted this
year I am sure it will be contentious [0]. Anyone who cares about Bitcoin
development and the ongoing technical work in a multitude of areas should be
strongly against a contentious soft fork activation attempt wasting the time of
developers and the entire ecosystem even if they don't have the understanding
or time to appreciate the reasons why it is contentious.
As I understand there are IRC workshops next week on BIP 119 [1] that I'd
encourage you to join so you can start getting into a position where you can
engage with the skeptics on technical concerns. Regrettably (as I said I find
this work interesting) I don't feel like I can participate because deployment
and activation is being included and I think it is irresponsible to be
discussing those at this point. In my view activation should not even be
speculated upon until it is clear there is overwhelming community support for a
soft fork being activated.
[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
[1]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
