Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id E274AC001E for ; Tue, 4 Jan 2022 17:07:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B828F82640 for ; Tue, 4 Jan 2022 17:07:39 +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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxngbSm0hNXc for ; Tue, 4 Jan 2022 17:07:37 +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 smtp1.osuosl.org (Postfix) with ESMTPS id E8F9482628 for ; Tue, 4 Jan 2022 17:07:36 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 0F123FBF688; Tue, 4 Jan 2022 17:07:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1641316054; 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=oCmHHJdStq1wmd/JLldw7MBBk/veg0+tvHKs6BJ+7pA=; b=PqWe8jM8UVZzyBA1KadEHPyYqm4YuC7pnJGxYl98ZKJssfoNlOs7OUvn3vrNo0bH pqK4xlHC9E2B8+D8UGj82tEjHYapoW2Fxvs0d5EusntKynRuto2Ag8UhiSgT64D9omH dSvJwe0aPu6fevjfzc9QjSzKQd/Fg8Tk23zUgUlB/0iEKOjcygGbvNJAbay0gR2Hv/o HGjZMS0kTm96jNGQYXQ84QgmtCbto5scCUta2uiOgHIrPabJS7eZ7iScSx1eLjkYj1e REq1zHt72neSnjbkSpIa9AdSYo9OPLAr2Mv9Iz1aY6S9Tv3hq0HFwd1vlpJH3jPBbDb 0qlc9AWhBg== Date: Tue, 4 Jan 2022 18:07:34 +0100 (CET) From: Prayank To: Michael Folkson Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17461_226439410.1641316055038" X-Mailman-Approved-At: Tue, 04 Jan 2022 17:52:00 +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 17:07:40 -0000 ------=_Part_17461_226439410.1641316055038 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > You are working on a use case of OP_CTV now? I think I mentioned clearly what I would be doing: 1. Review pull request 2= . Create contracts with Sapio. This would help me review OP_CTV and learn n= ew things. > Cool, you only recently announced you were working on Bitcoin Knots (and = I think Wasabi before that) so I'm losing track of all the announcements. You can read more about my involvement in Bitcoin Knots here: https://githu= b.com/bitcoinknots/bitcoin/discussions/39 I started working for zkSNACKs Wasabi 2 months back which can be confirmed = with the team. There are no announcements and humans can work on multiple things. You migh= t want to check my next project which involves discreet log contracts as I = have learnt a few things in bitcoin-s slack as well: https://gok.one/ For my involvement in other projects you can email me privately and I can s= hare my resume. --=20 Prayank A3B1 E430 2298 178F Jan 4, 2022, 22:18 by michaelfolkson@protonmail.com: > You are working on a use case of OP_CTV now? Cool, you only recently anno= unced you were working on Bitcoin Knots (and I think Wasabi before that) so= I'm losing track of all the announcements. Regardless stick with it and bu= ild out more than a rudimentary proof of concept. That is one of the things= that is severely lacking at this point for OP_CTV. > > >=C2=A0TBH I am not against Miniscript and still waiting for its support = in Core which might take another few years. I would love to have multiple p= rogramming languages so that application developers can decide what works b= est for them. > > I would hope you weren't against Miniscript because Sapio is built on top= of it :) But whatever have fun, I can't do this all day. > > > --> 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 3:06 PM, Prayank = wrote: > =20 > >> 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 i= n next few weeks? >> >> Review pull request 21702 and write contracts using Sapio based on few i= deas that I already have. >> >> What is this assessment based on? >> >> A few months are enough for the recent bounty to find bugs if possible a= nd other things pending to be completed. >> >> > you haven't thought about alternative proposals for any particular use= case (vaults for example have multiple current alternative proposals and m= ost likely many future ones) >> >> I have read enough about alternative proposals and some of them don't ev= en compete with OP_CTV, they can all be implemented and complement each oth= er. Vaults is not the only thing that I care about and it would be better i= f 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 rather than an alternative high level language like Mins= c? 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 o= n top of something that isn't ready? When you make the claims such as a con= sensus 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 b= e ready" doesn't mean much unless you have done the work. >> >> TBH I am not against Miniscript and still waiting for its support in Cor= e which might take another few years. I would love to have multiple program= ming languages so that application developers can decide what works best fo= r them. >> >> I don't understand what work are you expecting me to do in this case to = share 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 dedicated enough time reading everything related to OP_CTV and di= scuss things that were posted earlier here by Jeremy Rubin. Not sure how ma= ny skeptics did the same or even tried to discuss anything until recent bou= nty was announced. >> >> > You regularly NACK Core PRs yet you seem willing to wave a consensus c= hange through with no outstanding questions and zero skepticism. >> >> I would NACK and write the reasons in this pull request as well if I fin= d any 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 c= annot document each conversation. Its a Concept ACK from me and none of the= contributors could find any issues with PR right now so I don't want to st= op 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 yo= u can engage with the skeptics on technical concerns. Regrettably (as I sai= d 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 irresponsibl= e to be discussing those at this point. In my view activation should not ev= en be speculated upon until it is clear there is overwhelming community sup= port for a soft fork being activated. >> >> I would be attending the workshops and had even requested Jeremy to use = Twitch because it would help more people understand things with audio, scre= en sharing etc. I would love to see skeptics participate and discuss techni= cal 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= this point. >> >> If you don't participate in the workshops you might miss few things. How= ever, either Jeremy or one of the participants will ensure they share the s= ummary 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= 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 alternat= ive proposals for any particular use case (vaults for example have multiple= current alternative proposals and most likely many future ones). A new pro= gramming 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 somet= hing 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 chan= ges. For consensus changes you really should be digging even deeper, the ba= r 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 act= ivated, 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 sho= uld 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 developmen= t 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 P= R). The use cases sound cool and the work is genuinely interesting. But hon= estly for someone who has followed Bitcoin Core development, review for a w= hile now you really should know better than bandy around statements like "i= t should be ready to go in a few months" when you currently haven't scratch= ed 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 o= utstanding questions and zero skepticism. >>> >>> >=C2=A0If 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 c= ode, documentation etc. You should propose a new opcode but OP_CTV is not c= laiming to cure cancer. >>> >>> Multiple proven built out use cases, sure. Multiple is better than sing= le when you have done the work to ensure they are actually the right tool f= or 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 clai= ms should be deeply explored rather than just accepted as true. >>> >>> >> To contrast with his approach, the authors and contributors of anoth= er future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80= =99t promoting an imminent soft fork activation attempt and instead are bui= lding out and testing one of the speculated use cases, eltoo payment channe= ls [4]. >>> >>> > Because its not ready? >>> >>> As I said it is not ready because the ANYPREVOUT contributors are build= ing 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 pe= ople 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 at= tempted this year I am sure it will be contentious [0]. Anyone who cares ab= out Bitcoin development and the ongoing technical work in a multitude of ar= eas should be strongly against a contentious soft fork activation attempt w= asting the time of developers and the entire ecosystem even if they don't h= ave the understanding or time to appreciate the reasons why it is contentio= us. >>> >>> 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 eve= n be speculated upon until it is clear there is overwhelming community supp= ort for a soft fork being activated. >>> >>> [0]:=C2=A0>>> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89= af528d86a1b718 >>> [1]:=C2=A0>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2= 021-December/019719.html >>> >>> -->>> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: mi= chaelfolksonPGP:=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 Origina= l 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: >>> >>> >>>> 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 mo= nths of activation wrangling and community outreach twice. >>>> >>>> It should be ready to go in a few months IMO and makes no sense to bun= dle 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 th= e knock on impacts and potential short term damage they are inflicting on t= he 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 securit= y. >>>> >>>> >>>> > 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 f= ork 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 anoth= er future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80= =99t promoting an imminent soft fork activation attempt and instead are bui= lding out and testing one of the speculated use cases, eltoo payment channe= ls [4]. >>>> >>>> Because its not ready? >>>> >>>> >>>> > Similar work has not been done for any of the speculated use cases o= f OP_CTV. >>>> >>>> There is no comparison between the two. If someone has worked on one o= f the speculated uses cases, it makes no difference. >>>> >>>> If we still compare something because of our bias, maybe Sapio is some= thing 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 buil= ding out and testing of use cases can be completed post activation. >>>> >>>> We had soft signals from mining pools for Taproot as well and still wa= iting 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 se= e anything wrong in looking for people who support a proposal and documenti= ng 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 w= ith use cases, I would go with the one that has some use cases with code, d= ocumentation etc. You should propose a new opcode but OP_CTV is not claimin= g 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 proposal will be used by lot of Bitcoin projects a= nd 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 e= xisting 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 an= d 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_17461_226439410.1641316055038 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> You are working on a use case of OP_CTV now?

I think I mentioned clearly what I would= be doing: 1. Review pull request 2. Create contracts with Sapio. This woul= d help me review OP_CTV and learn new things.

=
> Cool, you only recently announced you were working on Bitcoin Kno= ts (and I think Wasabi before that) so I'm losing track of all the announce= ments.

You can read = more about my involvement in Bitcoin Knots here: https://github.com/bitcoin= knots/bitcoin/discussions/39

I started working for zkSNACKs Wasabi 2 months back which can be = confirmed with the team.

There are no announcements and humans can work on multiple things. You= might want to check my next project which involves discreet log contracts = as I have learnt a few things in bitcoin-s slack as well: https://gok.one/<= br>

For my involvement i= n other projects you can email me privately and I can share my resume.
<= /div>

--
Prayank

A3B1 E430 2298 178F

=


Jan 4, 2022, 22:18 by michaelfolks= on@protonmail.com:
= You are working on a use case of OP_CTV now? Cool, you only recently announ= ced you were working on Bitcoin Knots (and I think Wasabi before that) so I= 'm losing track of all the announcements. Regardless stick with it and buil= d out more than a rudimentary proof of concept. That is one of the things t= hat is severely lacking at this point for OP_CTV.

<= div>> TBH I am not against Miniscript and still waiting for its sup= port in Core which might take another few years. I would love to have multi= ple programming languages so that application developers can decide what wo= rks best for them.

I w= ould hope you weren't against Miniscript because Sapio is built on top of i= t :) But whatever have fun, I can't do this all day.


=
--
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 3:06 PM, Prayank <prayank@tutanota.de> wrote:
<= div>
What I have done r= elated to OP_CTV?

ht= tps://twitter.com/prayankgahlot/status/1456643891885592579

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

Review pull request 21702 and write contr= acts using Sapio based on few ideas 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 case= (vaults for example have multiple current alternative proposals and most l= ikely many future ones)

I have read enough about alternative proposals and some of them don't e= ven compete with OP_CTV, they can all be implemented and complement each ot= her. Vaults is not the only thing that I care about and it would be better = if we don't assume about research done by others.

> A new programming language (Sapio) sound= s 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 fi= rst 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 do= ne the work.

TBH I a= m not against Miniscript and still waiting for its support in Core which mi= ght take another few years. I would love to have multiple programming langu= ages so that application developers can decide what works best for them.

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

> It is not enough = for one individual to say it is ready to be activated, anyone who is expres= sing that view should understand why the opcode has been designed in the wa= y it has and why it is so important that we should dedicate months of commu= nity time to getting a single opcode activated this year.

I have dedicated enough time reading = everything related to OP_CTV and discuss things that were posted earlier he= re by Jeremy Rubin. Not sure how many skeptics did the same or even tried t= o 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 questio= ns and zero skepticism.

I would NACK and write the reasons in this pull request as well if I fi= nd any 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 = cannot document each conversation. Its a Concept ACK from me and none of th= e contributors could find any issues with PR right now so I don't want to s= top people from improving Bitcoin.

> As I understand there are IRC workshops next week on BI= P 119 [1] that I'd encourage you to join so you can start getting into a po= sition where you can engage with the skeptics on technical concerns. Regret= tably (as I said I find this work interesting) I don't feel like I can part= icipate because deployment and activation is being included and I think it = is irresponsible to be discussing those at this point. In my view activatio= n should not even be speculated upon until it is clear there is overwhelmin= g community support for a soft fork being activated.

I would be attending the workshops and had= even requested Jeremy to use Twitch because it would help more people unde= rstand 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 depl= oyment 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 workshops you might miss few= things. However, either Jeremy or one of the participants will ensure they= share the summary here or even logs would be available.

--
Prayank

=
A3B1 E430 2298 178F



Jan 4, 2022, 19:45 by michaelfolkson@protonmail.com:<= br>
> It should be ready to g= o in a few months IMO
<= /div>

What is this assessment based on? I am assuming yo= u haven't done a code review of the opcode, you haven't coded up a real wor= ld use case of OP_CTV (or even a primitive proof of concept), you haven't t= hought about alternative proposals for any particular use case (vaults for = example have multiple current alternative proposals and most likely many fu= ture 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 li= ke 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 a= s 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.
<= div>
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 sho= uld 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 import= ant that we should dedicate months of community time to getting a single op= code activated this year.

I have more sympathy= for those who don't follow Bitcoin Core development and Bitcoin Core revie= w on an ongoing basis (note as I said that the bar for consensus changes sh= ould be significantly higher than a non-consensus PR). The use cases sound = cool and the work is genuinely interesting. But honestly for someone who ha= s followed Bitcoin Core development, review for a while now you really shou= ld 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 ut= ility and safety of this opcode. You regularly NACK Core PRs yet you seem w= illing 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 s= hould 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. T= his work hasn't been done on any of these use cases. The curing cancer anal= ogy was used to elucidate the point that claims should be deeply explored r= ather than just accepted as true.

= >> To contrast with his approach, the authors and contributors of ano= ther future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80= =99t promoting an imminent soft fork activation attempt and instead are bui= lding out and testing one of the speculated use cases, eltoo payment channe= ls [4].

> Because i= ts not ready?

As I sa= id 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 pro= posals 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 thi= s before indicating they support an imminent activation attempt. Some peopl= e don't have the understanding to dig deeper, some people don't have the ti= me and some don't have either. However, if an activation of OP_CTV is attem= pted 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 wast= ing 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 skep= tics on technical concerns. Regrettably (as I said I find this work interes= ting) 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 a= t this point. In my view activation should not even be speculated upon unti= l it is clear there is overwhelming community support for a soft fork being= activated.


--
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>= ; wrote:

= 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 Ta= proot soft fork (perhaps delayed) rather than going through the months of a= ctivation 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 propo= sed.


> It should be made clear to any individual(s) that attempt= this of the knock on impacts and potential short term damage they are infl= icting 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 exa= mples, 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 activa= tion of a soft fork containing exclusively OP_CTV [2].

He is doing nothing unexpected and got r= easons to support OP_CTV being implemented soon.


> To contrast w= ith his approach, the authors and contributors of another future soft fork = proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t promoting an immi= nent 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 com= parison between the two. If someone has worked on one of the speculated use= s 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.
<= div dir=3D"auto">

&g= t; Instead Jeremy is encouraging people to =E2=80=9Csoft signal=E2=80=9D fo= r soft fork activation of OP_CTV presumably in the hope that the building o= ut and testing of use cases can be completed post activation.

We had soft signals from mining p= ools for Taproot as well and still waiting for projects to use Taproot. Eve= n 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 ir= responsible in my view. A long list of speculated use cases means nothing o= n its own. I can propose a new opcode OP_MAGIC and claim it will cure cance= r with no potential downsides and hence we should have a soft fork activati= ng 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 claim= ing to cure cancer.

=
> I would hope there would be sufficient ske= pticism that this proposal wouldn=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, dece= ntralization, demand for block space etc.


> I feel the top prior= ity is to bring some attention to the danger of us stumbling into an attemp= ted contentious soft fork activation attempt.
I feel the danger is a few people able to stop so= ft forks that improve Bitcoin because of their bias and opinions which are = mostly non-technical.


> Enabling covenants on Bitcoin is a big s= tep 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 b= e resisted.

Nobody h= as 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


------=_Part_17461_226439410.1641316055038--