Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 91DBBC001E for ; Tue, 4 Jan 2022 15:06:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 657B260EA2 for ; Tue, 4 Jan 2022 15:06:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuiidurOGhRy for ; Tue, 4 Jan 2022 15:06:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1F9AF600B5 for ; Tue, 4 Jan 2022 15:06:31 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 32659FA0244; Tue, 4 Jan 2022 15:06:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1641308788; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=g8uPz2818WpWb0e3FEPYl1G5tr9a9lvHZDq17I4saU4=; b=H4rysNmbF7YFXPtnDO6aYR7LS16Y4fVWw33jF5sGfgikG/0NQDgqd17VgVI0g39s QXfrhkm6ZGciRNmJy6vyGiDygtfjZlm4iimn9//KPDOmHH0Qm3lOlyXI7xVCcWuZsn1 dYTwSRWXNn/lVo3MAyw4mxmmE8YFqTgXw4Ck1JamZJzn+w1PWBngB7jMw3utxtSVk5e 9Dq6Ypj7RIZNmOqVnxK7fpeQC9q9mSzzcYB9rixSvnknE1rgYpi2crotCDfftd0+5om vCGk6MB/5NnenEAeJFjyhMgDU98b/I7N4jxb/ofdhKLXPSOxp6gP/gdgU4WFY9cp7kQ xspKFDVJaA== Date: Tue, 4 Jan 2022 16:06:28 +0100 (CET) From: Prayank To: Michael Folkson Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9567_1651322246.1641308789175" X-Mailman-Approved-At: Tue, 04 Jan 2022 15:53:58 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2022 15:06:33 -0000 ------=_Part_9567_1651322246.1641308789175 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What I have done related to OP_CTV? https://twitter.com/prayankgahlot/status/1456643891885592579 What am I currently working on that is not shared publicly and will do in n= ext few weeks? Review pull request 21702 and write contracts using Sapio based on few idea= s that I already have. What is this assessment based on? A few months are enough for the recent bounty to find bugs if possible and = other things pending to be completed. > you haven't thought about alternative proposals for any particular use ca= se (vaults for example have multiple current alternative proposals and most= likely many future ones) I have read enough about alternative proposals and some of them don't even = compete with OP_CTV, they can all be implemented and complement each other.= Vaults is not the only thing that I care about and it would be better if w= e don't assume about research done by others. > A new programming language (Sapio) sounds great but do you you need it fo= r 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 fo= r Taproot. Surely that needs to be done first otherwise Sapio is built on t= op of something that isn't ready? When you make the claims such as a consen= sus change is ready to go the burden is on you to convince me and other ske= ptics why. The status quo is the default. "I think it is ready or will be r= eady" doesn't mean much unless you have done the work. TBH I am not against Miniscript and still waiting for its support in Core w= hich might take another few years. I would love to have multiple programmin= g languages so that application developers can decide what works best for t= hem. I don't understand what work are you expecting me to do in this case to sha= re my opinion about a soft fork. > It is not enough for one individual to say it is ready to be activated, a= nyone 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 dedic= ate months of community time to getting a single opcode activated this year= . I have dedicated enough time reading everything related to OP_CTV and discu= ss things that were posted earlier here by Jeremy Rubin. Not sure how many = skeptics did the same or even tried to discuss anything until recent bounty= was announced. > You regularly NACK Core PRs yet you seem willing to wave a consensus chan= ge through with no outstanding questions and zero skepticism. I would NACK and write the reasons in this pull request as well if I find a= ny issues and PR author is not addressing them. I had lots of questions at = conceptual level which have been answered on different platforms and I cann= ot document each conversation. Its a Concept ACK from me and none of the co= ntributors could find any issues with PR right now so I don't want to stop = people from improving Bitcoin. > 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 c= an 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 de= ployment and activation is being included and I think it is irresponsible t= o be discussing those at this point. In my view activation should not even = be speculated upon until it is clear there is overwhelming community suppor= t for a soft fork being activated. I would be attending the workshops and had even requested Jeremy to use Twi= tch because it would help more people understand things with audio, screen = sharing etc. I would love to see skeptics participate and discuss technical= things. > 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 th= is point. If you don't participate in the workshops you might miss few things. Howeve= r, either Jeremy or one of the participants will ensure they share the summ= ary here or even logs would be available. --=20 Prayank A3B1 E430 2298 178F Jan 4, 2022, 19:45 by michaelfolkson@protonmail.com: > >=C2=A0> 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 r= eview 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 alternativ= e proposals for any particular use case (vaults for example have multiple c= urrent alternative proposals and most likely many future ones). A new progr= amming language (Sapio) sounds great but do you you need it for your use ca= se rather than an alternative high level language like Minsc? Sapio makes u= se of Miniscript which hasn't been finalized yet or updated for Taproot. Su= rely that needs to be done first otherwise Sapio is built on top of somethi= ng 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. Th= e 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 change= s. 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 i= n depth. It is not enough for one individual to say it is ready to be activ= ated, anyone who is expressing that view should understand why the opcode h= as been designed in the way it has and why it is so important that we shoul= d dedicate months of community time to getting a single opcode activated th= is 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 fo= r consensus changes should be significantly higher than a non-consensus PR)= . The use cases sound cool and the work is genuinely interesting. But hones= tly for someone who has followed Bitcoin Core development, review for a whi= le 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 C= ore PRs yet you seem willing to wave a consensus change through with no out= standing questions and zero skepticism. > > >=C2=A0If I had to select between a soft fork without any use cases and o= ne with use cases, I would go with the one that has some use cases with cod= e, documentation etc. You should propose a new opcode but OP_CTV is not cla= iming 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 c= ases. 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=E2=80=99t= promoting an imminent soft fork activation attempt and instead are buildin= g 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 buildin= g out and testing a use case. The high bar on readiness should be applied t= o all proposals not merely the ones where the authors/contributors decide t= o impose a high bar themselves. > > I don't really want to spend my year imploring people to dig deeper on th= is before indicating they support an imminent activation attempt. Some peop= le don't have the understanding to dig deeper, some people don't have the t= ime and some don't have either. However, if an activation of OP_CTV is atte= mpted this year I am sure it will be contentious [0]. Anyone who cares abou= t Bitcoin development and the ongoing technical work in a multitude of area= s should be strongly against a contentious soft fork activation attempt was= ting the time of developers and the entire ecosystem even if they don't hav= e 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 c= an 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 de= ployment and activation is being included and I think it is irresponsible t= o be discussing those at this point. In my view activation should not even = be speculated upon until it is clear there is overwhelming community suppor= t for a soft fork being activated. > > [0]:=C2=A0> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af52= 8d86a1b718 > [1]:=C2=A0> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-= December/019719.html > > --> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: michae= lfolksonPGP:=C2=A043ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev wrote: > =20 > >> Hi Michael, >> >> > If OP_CTV is ready to go now and has overwhelming community support (I= don=E2=80=99t think either is true) it should surely have been included in= the Taproot soft fork (perhaps delayed) rather than going through the mont= hs of activation wrangling and community outreach twice. >> >> It should be ready to go in a few months IMO and makes no sense to bundl= e everything with Taproot soft fork. Things can remain separate and still c= onsidered 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 ye= ars, documented properly, includes code for implementation and examples, re= cently 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 for= k containing exclusively OP_CTV [2]. >> >> He is doing nothing unexpected and got reasons to support OP_CTV being i= mplemented soon. >> >> >> > To contrast with his approach, the authors and contributors of another= future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t= promoting an imminent soft fork activation attempt and instead are buildin= g 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 someth= ing that would be more helpful for Bitcoin developers. >> >> >> > Instead Jeremy is encouraging people to =E2=80=9Csoft signal=E2=80=9D = 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 wait= ing for projects to use Taproot. Even miners signaling with speedy trial wa= s 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 us= e cases means nothing on its own. I can propose a new opcode OP_MAGIC and c= laim it will cure cancer with no potential downsides and hence we should ha= ve a soft fork activating it as soon as possible. >> >> If I had to select between a soft fork without any use cases and one wit= h use cases, I would go with the one that has some use cases with code, doc= umentation 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 w= ouldn=E2=80=99t 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 B= itcoin because of their bias and opinions which are mostly non-technical. >> >> >> > Enabling covenants on Bitcoin is a big step change with barely any exi= sting research on the topic and attempting to rush it through by the back d= oor 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. >> >> >> --=20 >> Prayank >> >> A3B1 E430 2298 178F >> ------=_Part_9567_1651322246.1641308789175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What I have done related to OP_CTV?

https://twitter.com/prayankgahlot/status/1456643891885= 592579

What am I cur= rently working on that is not shared publicly and will do in next few weeks= ?

Review pull reques= t 21702 and write contracts using Sapio based on few ideas that I already h= ave.

What is this as= sessment based on?

A= few months are enough for the recent bounty to find bugs if possible and o= ther things pending to be completed.

<= div dir=3D"auto">> you haven't thought about alternative proposals for a= ny particular use case (vaults for example have multiple current alternativ= e proposals and most likely many future ones)
I have read enough about alternative proposals an= d some of them don't even compete with OP_CTV, they can all be implemented = and complement each other. Vaults is not the only thing that I care about a= nd it would be better if we don't assume about research done by others.
=

> A new programming = language (Sapio) sounds great but do you you need it for your use case rath= er than an alternative high level language like Minsc? Sapio makes use of M= iniscript which hasn't been finalized yet or updated for Taproot. Surely th= at 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 statu= s quo is the default. "I think it is ready or will be ready" doesn't mean m= uch unless you have done the work.

TBH I am not against Miniscript and still waiting for its su= pport in Core which might take another few years. I would love to have mult= iple programming languages so that application developers can decide what w= orks best for them.

= I don't understand what work are you expecting me to do in this case to sha= re my opinion about a soft fork.

= > 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 b= een designed in the way it has and why it is so important that we should de= dicate months of community time to getting a single opcode activated this y= ear.

I have dedicate= d enough time reading everything related to OP_CTV and discuss things that = were posted earlier here by Jeremy Rubin. Not sure how many skeptics did th= e same or even tried to discuss anything until recent bounty was announced.=

> You regularly = NACK Core PRs yet you seem willing to wave a consensus change through with = no outstanding questions and zero skepticism.
I would NACK and write the reasons in this pull r= equest as well if I find any issues and PR author is not addressing them. I= had lots of questions at conceptual level which have been answered on diff= erent platforms and I cannot document each conversation. Its a Concept ACK = from me and none of the contributors could find any issues with PR right no= w so I don't want to stop people from improving Bitcoin.

> As I understand there are IRC wo= rkshops 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 tec= hnical concerns. Regrettably (as I said I find this work interesting) I don= 't feel like I can participate because deployment and activation is being i= ncluded and I think it is irresponsible to be discussing those at this poin= t. In my view activation should not even be speculated upon until it is cle= ar there is overwhelming community support for a soft fork being activated.=

I would be attendin= g the workshops and had even requested Jeremy to use Twitch because it woul= d help more people understand things with audio, screen sharing etc. I woul= d love to see skeptics participate and discuss technical things.
<= div dir=3D"auto">
> I don't feel like I can p= articipate because deployment and activation is being included and I think = it is irresponsible to be discussing those at this point.

If you don't participate in the works= hops you might miss few things. However, either Jeremy or one of the partic= ipants will ensure they share the summary here or even logs would be availa= ble.

--
Prayank

A3B1 E430 2298 178F
<= br>


Jan 4, 2022, 19:45 by michaelfo= lkson@protonmail.com:
=
> It should be ready to go in a few months= IMO

What i= s 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 propos= als for any particular use case (vaults for example have multiple current a= lternative proposals and most likely many future ones). A new programming l= anguage (Sapio) sounds great but do you you need it for your use case rathe= r than an alternative high level language like Minsc? Sapio makes use of Mi= niscript which hasn't been finalized yet or updated for Taproot. Surely tha= t 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 t= o 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 mu= ch unless you have done the work.

You are well= aware of the review process in Core for non-consensus changes. For consens= us changes you really should be digging even deeper, the bar should be high= er 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 w= ho is expressing that view should understand why the opcode has been design= ed in the way it has and why it is so important that we should dedicate mon= ths of community time to getting a single opcode activated this year.

I have more sympathy for those who don't follow Bit= coin Core development and Bitcoin Core review on an ongoing basis (note as = I said that the bar for consensus changes should be significantly higher th= an a non-consensus PR). The use cases sound cool and the work is genuinely = interesting. But honestly for someone who has followed Bitcoin Core develop= ment, review for a while now you really should know better than bandy aroun= d statements like "it should be ready to go in a few months" when you curre= ntly 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 chan= ge through with no outstanding questions and zero skepticism.

> If I had to select between a soft fork without an= y use cases and one with use cases, I would go with the one that has some u= se 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 be= tter than single when you have done the work to ensure they are actually th= e right tool for those multiple use cases. This work hasn't been done on an= y of these use cases. The curing cancer analogy was used to elucidate the p= oint that claims should be deeply explored rather than just accepted as tru= e.

>> To contrast with his= approach, the authors and contributors of another future soft fork proposa= l (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t promoting an imminent so= ft 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 becaus= e 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 one= s 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 underst= anding to dig deeper, some people don't have the time and some don't have e= ither. 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 agai= nst a contentious soft fork activation attempt wasting the time of develope= rs and the entire ecosystem even if they don't have the understanding or ti= me 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 concer= ns. 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 o= verwhelming community support for a soft fork being activated.

[1]: https://lists.l= inuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
<= /div>

<=
span style=3D"box-sizing: inherit; quotes: "=E2=80=9C" "=E2=
=80=9D" "=E2=80=98" "=E2=80=99"; line-height: norm=
al;">=
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
<= br>
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90= =E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90=E2=80=90=E2=80=90
On Tuesday, January 4th, 2022 at 11= :53 AM, Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:

Hi Michael,

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

It should be ready to go in a few months I= MO and makes no sense to bundle everything with Taproot soft fork. Things c= an remain separate and still considered good enough based on the changes pr= oposed.


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

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


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

He is doing nothing unexpected and go= t reasons to support OP_CTV being implemented soon.


> To contras= t with his approach, the authors and contributors of another future soft fo= rk proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t promoting an i= mminent soft fork activation attempt and instead are building out and testi= ng 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 Sa= pio is something that would be more helpful for Bitcoin developers.


> Instead Jeremy is encouraging people to =E2=80=9Csoft signal=E2=80=9D= for soft fork activation of OP_CTV presumably in the hope that the buildin= g out and testing of use cases can be completed post activation.
<= div dir=3D"auto">
We had soft signals from minin= g 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 foll= ow new consensus rules later. I don't see anything wrong in looking for peo= ple who support a proposal and documenting it.
<= br>

> This is totally= irresponsible in my view. A long list of speculated use cases means nothin= g on its own. I can propose a new opcode OP_MAGIC and claim it will cure ca= ncer with no potential downsides and hence we should have a soft fork activ= ating 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 co= de, documentation etc. You should propose a new opcode but OP_CTV is not cl= aiming to cure cancer.


> I would hope there would be sufficient = skepticism that this proposal wouldn=E2=80=99t see the light of day.

I am confident this propos= al will be used by lot of Bitcoin projects and improve privacy, security, d= ecentralization, demand for block space etc.

> I feel the top pr= iority is to bring some attention to the danger of us stumbling into an att= empted 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 a= re mostly non-technical.


> Enabling covenants on Bitcoin is a bi= g 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 shoul= d be resisted.

Nobod= y has stopped anyone from doing research. There is no backdoor and everythi= ng is public. So soon? I am not sure if there are any issues with a soft fo= rk in next few months if its ready.


--
Prayank

=
A3B1 E430 2298 178F

------=_Part_9567_1651322246.1641308789175--