path: root/c0/ffc32566645b456059283b6a6a101ca4be692c

Return-Path: <prayank@tutanota.de>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B00D6C001E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <prayank@tutanota.de>
To: Michael Folkson <michaelfolkson@gmail.com>
Message-ID: <MsZvyxN--7-2@tutanota.de>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>Hi Michael,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt=
; 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.<br></div><div dir=3D"=
auto"><br></div><div dir=3D"auto">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.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">&gt; 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.<br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">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.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">&gt; 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].<br></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">He is doing nothing unexpected and g=
ot reasons to support OP_CTV being implemented soon.<br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; 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].<br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Because its not ready?<br></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>&gt; Similar work has not been done for any of the speculated use cases of=
 OP_CTV.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">There is no=
 comparison between the two. If someone has worked on one of the speculated=
 uses cases, it makes no difference.<br></div><div dir=3D"auto"><br></div><=
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.<br></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">&gt; 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.<br></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">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.<br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; 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.<br></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">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.<br></div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><br></div><div dir=3D"auto">&gt; I would hope there would be sufficie=
nt skepticism that this proposal wouldn=E2=80=99t see the light of day.<br>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">I am confident this pro=
posal will be used by lot of Bitcoin projects and improve privacy, security=
, decentralization, demand for block space etc.<br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; I feel the top=
 priority is to bring some attention to the danger of us stumbling into an =
attempted contentious soft fork activation attempt.<br></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">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.<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">&gt; 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.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
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.<br></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto"><br></div><div>-- <br></div><div>Prayank<br></div><div=
><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div>  </body>
</html>

------=_Part_607002_1092306597.1641297212436--