From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B00D6C001E for ; Tue, 4 Jan 2022 11:53:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id ACA1B60BC1 for ; Tue, 4 Jan 2022 11:53:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 4K1IFA6olFOc for ; Tue, 4 Jan 2022 11:53:35 +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 5FB3260B3B for ; Tue, 4 Jan 2022 11:53:35 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 70996FA0921; Tue, 4 Jan 2022 11:53:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1641297212; 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:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=9PhvmmRkToyonDlsseCMAgEumMcb91VlX3oH9JAMbnQ=; b=oIfES2VdCTWjxYvEhe8ZXO1qZJBSqTR7XC2aRbAPtGYrDwyaSh981V92F6ag4Nmo iZlLIy3eNLgTsYmybjuYSfTIBFZIpBdtrTSs2Vw1oiPz+Ha4IjMVWhXGoWAY5rVvIxC 3WgPiLyHPFdKIH7fEmQzFjPxVviXfs58tJmy5kDguotMxE2K3J6weiOMuBXzoKvNl2y oK+Jpa7XEEqCXci3wEOVDJBwD45/7WUnK6nby6vTDBU269jfeVJc0H7BX4hIS6ji9Nz ivokp0lIK/LXMYAZrcZr/hxsS4828pPVQGoYu60SyPOtSAVry0uw8NcigIlI2I2cB4Z JnYO9zAAnQ== Date: Tue, 4 Jan 2022 12:53:32 +0100 (CET) From: Prayank To: Michael Folkson Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_607002_1092306597.1641297212436" X-Mailman-Approved-At: Tue, 04 Jan 2022 12:30:26 +0000 Cc: Bitcoin Dev 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 11:53:36 -0000 ------=_Part_607002_1092306597.1641297212436 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael, > If OP_CTV is ready to go now and has overwhelming community support (I do= n=E2=80=99t think either is true) it should surely have been included in th= e 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 e= verything with Taproot soft fork. Things can remain separate and still cons= idered good enough based on the changes proposed. > It should be made clear to any individual(s) that attempt this of the kno= ck on impacts and potential short term damage they are inflicting on the en= tire 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, recen= tly got crowdfunding to incentivize review process and improve security. > It seems to me like the author and primary promoter of this proposal (Jer= emy Rubin) is pushing for an imminent attempted activation of a soft fork c= ontaining exclusively OP_CTV [2]. He is doing nothing unexpected and got reasons to support OP_CTV being impl= emented soon. > To contrast with his approach, the authors and contributors of another fu= ture soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t pr= omoting an imminent soft fork activation attempt and instead are building o= ut 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 =E2=80=9Csoft signal=E2=80=9D for= soft fork activation of OP_CTV presumably in the hope that the building ou= t 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 n= ot a guarantee they would follow new consensus rules later. I don't see any= thing 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 c= ases means nothing on its own. I can propose a new opcode OP_MAGIC and clai= m 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 u= se cases, I would go with the one that has some use cases with code, docume= ntation 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 woul= dn=E2=80=99t see the light of day. I am confident this proposal will be used by lot of Bitcoin projects and im= prove privacy, security, decentralization, demand for block space etc. > I feel the top priority is to bring some attention to the danger of us st= umbling into an attempted contentious soft fork activation attempt. I feel the danger is a few people able to stop soft forks that improve Bitc= oin because of their bias and opinions which are mostly non-technical. > Enabling covenants on Bitcoin is a big step change with barely any existi= ng 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 eve= rything is public. So soon? I am not sure if there are any issues with a so= ft fork in next few months if its ready. --=20 Prayank A3B1 E430 2298 178F ------=_Part_607002_1092306597.1641297212436 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

>= ; If OP_CTV is ready to go now and has overwhelming community support (I do= n=E2=80=99t think either is true) it should surely have been included in th= e 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 p= roposed.


<= div dir=3D"auto">> It should be made clear to any individual(s) that att= empt 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 discu= ssed since years, documented properly, includes code for implementation and= examples, recently got crowdfunding to incentivize review process and impr= ove security.


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

He is doing nothing unexpected and g= ot reasons to support OP_CTV being implemented soon.


> To contra= st with his approach, the authors and contributors of another future soft f= ork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t promoting an = imminent soft fork activation attempt and instead are building out and test= ing one of the speculated use cases, eltoo payment channels [4].
<= div dir=3D"auto">
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.

<= div dir=3D"auto">If we still compare something because of our bias, maybe S= apio 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 buil= ding out and testing of use cases can be completed post activation.

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


> This is tota= lly irresponsible in my view. A long list of speculated use cases means not= hing 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 ac= tivating it as soon as possible.

If I had to select between a soft fork without any use cases a= nd 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 sufficie= nt skepticism that this proposal wouldn=E2=80=99t see the light of day.
=

I am confident this pro= posal 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 s= top soft forks that improve Bitcoin because of their bias and opinions whic= h are mostly non-technical.


> Enabling covenants on Bitcoin is= a big step change with barely any existing research on the topic and attem= pting 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 eve= rything is public. So soon? I am not sure if there are any issues with a so= ft fork in next few months if its ready.


--
Prayank

A3B1 E430 2298 178F
------=_Part_607002_1092306597.1641297212436--