path: root/ff/dbd2c7285dde20368f547b78dcfd2379bdc70d

Return-Path: <prayank@tutanota.de>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E274AC001E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <prayank@tutanota.de>
To: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <Msa2rJm--3-2@tutanota.de>
In-Reply-To: <Em6eiOmLzenkLBlDBHquuiK4rE60qno3pHirzBQYHG9r9zqpK5nexun38eoRaC9wEDogPKVc4SPJ6ScNL-KDkx8CW4i4fuV9bB8x-G8bHq0=@protonmail.com>
References: <MsZvyxN--7-2@tutanota.de>
 <mS9BiAhDjDaA8BeRzKIJy7DggiCYkRuIaYISjT-G0v3fd88HDIiWS6UxUghkp-kA99Us1wxkNOyunsBnRVRClZcvgAgOSALl3RB_8z6YY-A=@protonmail.com>
 <Ms_c8Dw--3-2@tutanota.de>
 <Em6eiOmLzenkLBlDBHquuiK4rE60qno3pHirzBQYHG9r9zqpK5nexun38eoRaC9wEDogPKVc4SPJ6ScNL-KDkx8CW4i4fuV9bB8x-G8bHq0=@protonmail.com>
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 <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 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 <prayank@tutanota.de> =
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 <bit=
coin-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 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

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>&gt; You are working on a use case of OP_CTV now?<br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">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.<br></div><div><div><br></div>=
<div>&gt; 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.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">You can read =
more about my involvement in Bitcoin Knots here: https://github.com/bitcoin=
knots/bitcoin/discussions/39<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I started working for zkSNACKs Wasabi 2 months back which can be =
confirmed with the team.<br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">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></div><div dir=3D"auto"><br></div><div dir=3D"auto">For my involvement i=
n other projects you can email me privately and I can share my resume.<br><=
/div><div dir=3D"auto"><br></div></div><div>-- <br></div><div>Prayank<br></=
div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div><div><br>=
</div><div><br></div><div><br></div><div>Jan 4, 2022, 22:18 by michaelfolks=
on@protonmail.com:<br></div><blockquote class=3D"tutanota_quote" style=3D"b=
order-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>=
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.<br></div><div><br></div><=
div>&gt;&nbsp;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.<br></div><div dir=3D"auto" style=3D"box-sizing: inherit;=
 quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; =
&quot;=E2=80=99&quot;; line-height: normal;"><br></div><div dir=3D"auto" st=
yle=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&q=
uot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-height: normal;">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.<br></div><div><br></di=
v><div class=3D""><div class=3D""><br></div></div><pre style=3D"box-sizing:=
 inherit; font-size: 14px; line-height: normal; margin: 0px; font-family: S=
FMono-Regular, Consolas, &quot;Liberation Mono&quot;, Menlo, monospace, mon=
ospace; overflow-wrap: break-word; white-space: pre-wrap; height: auto; max=
-width: 100%; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=
=80=98&quot; &quot;=E2=80=99&quot;; font-style: normal; font-variant-ligatu=
res: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: n=
ormal; orphans: 2; text-align: start; text-indent: 0px; text-transform: non=
e; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decor=
ation-thickness: initial; text-decoration-style: initial; text-decoration-c=
olor: initial; background-color: rgb(255, 255, 255); color: rgb(0, 0, 0);">=
<span style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &quot;=E2=
=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-height: norm=
al;"><span style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &quo=
t;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-height:=
 normal;"><span style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot;=
 &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-he=
ight: normal;"><span style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&=
quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; li=
ne-height: normal;"><span style=3D"box-sizing: inherit; quotes: &quot;=E2=
=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&qu=
ot;; line-height: normal;"><span class=3D"" style=3D""><span class=3D"size"=
 style=3D"font-size:14px">--
</span></span></span></span></span></span></span>Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP:&nbsp;43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br></pre><div><=
br></div><div><br></div><div class=3D""><div>=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<br></div><div> On Tuesday, January =
4th, 2022 at 3:06 PM, Prayank &lt;prayank@tutanota.de&gt; wrote:<br></div><=
div> <br></div><blockquote type=3D"cite" class=3D""><div>What I have done r=
elated to OP_CTV?<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">ht=
tps://twitter.com/prayankgahlot/status/1456643891885592579<br></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">What am I currently working on that =
is not shared publicly and will do in next few weeks?<br></div><div dir=3D"=
auto"><br></div><div dir=3D"auto">Review pull request 21702 and write contr=
acts using Sapio based on few ideas that I already have.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">What is this assessment based on?<br>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">A few months are enough=
 for the recent bounty to find bugs if possible and other things pending to=
 be completed.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; =
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)<br></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">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.<br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">&gt; 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.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">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.<br=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">I don't understand wha=
t work are you expecting me to do in this case to share my opinion about a =
soft fork.<br></div><div><br></div><div dir=3D"auto">&gt; 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.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">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.<br></div><div dir=3D"=
auto"><br></div><div dir=3D"auto">&gt; You regularly NACK Core PRs yet you =
seem willing to wave a consensus change through with no outstanding questio=
ns and zero skepticism.<br></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">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.<br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">&gt; 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.<br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">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.<br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">&gt; 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.<br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">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.<br></div><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><div><br></div><div><br></di=
v><div><br></div><div>Jan 4, 2022, 19:45 by michaelfolkson@protonmail.com:<=
br></div><blockquote style=3D"border-left: 1px solid #93A3B8; padding-left:=
 10px; margin-left: 5px;"><div>&gt;&nbsp;<span style=3D"color: rgb(38, 42, =
51); font-style: normal; font-variant-ligatures: normal; font-variant-caps:=
 normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rg=
b(255, 255, 255); text-decoration-thickness: initial; text-decoration-style=
: initial; text-decoration-color: initial; float: none; display: inline !im=
portant;"><span class=3D"" style=3D""><span style=3D"" class=3D""><span cla=
ss=3D"font" style=3D"font-family:-apple-system, &quot;system-ui&quot;, &quo=
t;Segoe UI&quot;, Roboto, Oxygen-Sans, Ubuntu, Cantarell, &quot;Helvetica N=
eue&quot;, sans-serif"><span class=3D"" style=3D""><span style=3D"" class=
=3D""><span class=3D"size" style=3D"font-size:14px">It should be ready to g=
o in a few months IMO</span></span></span></span></span></span></span><br><=
/div><div><br></div><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.<br></div><=
div><br></div><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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>&gt;&nbsp;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.<br></=
div><div style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &quot;=
=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-height: n=
ormal;" dir=3D"auto"><br></div><div style=3D"box-sizing: inherit; quotes: &=
quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=
=80=99&quot;; line-height: normal;" dir=3D"auto">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.<br></div><div><br></div><div style=3D"box=
-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot=
;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-height: normal;" dir=3D"auto">=
&gt;&gt; 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].<br></div><div style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C=
&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; l=
ine-height: normal;" dir=3D"auto"><br></div><div style=3D"box-sizing: inher=
it; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quo=
t; &quot;=E2=80=99&quot;; line-height: normal;" dir=3D"auto">&gt; Because i=
ts not ready?<br></div><div style=3D"box-sizing: inherit; quotes: &quot;=E2=
=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&qu=
ot;; line-height: normal;" dir=3D"auto"><br></div><div style=3D"box-sizing:=
 inherit; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=
=98&quot; &quot;=E2=80=99&quot;; line-height: normal;" dir=3D"auto">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.<br></div><div style=3D"box-sizing: inherit; quotes: =
&quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=
=80=99&quot;; line-height: normal;" dir=3D"auto"><br></div><div style=3D"bo=
x-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quo=
t;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-height: normal;" dir=3D"auto"=
>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.=
<br></div><div style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; =
&quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-hei=
ght: normal;" dir=3D"auto"><br></div><div style=3D"box-sizing: inherit; quo=
tes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quo=
t;=E2=80=99&quot;; line-height: normal;" dir=3D"auto">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.<br></div><div style=3D"box-sizing: inherit; quotes: &quot;=E2=
=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&qu=
ot;; line-height: normal;" dir=3D"auto"><br></div><div style=3D"box-sizing:=
 inherit; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=
=98&quot; &quot;=E2=80=99&quot;; line-height: normal;" dir=3D"auto">[0]:&nb=
sp;<a target=3D"_blank" rel=3D"noopener noreferrer" href=3D"https://gist.gi=
thub.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718">https://gist.gith=
ub.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718</a><br></div><div st=
yle=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&q=
uot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-height: normal;" dir=
=3D"auto">[1]:&nbsp;<a target=3D"_blank" rel=3D"noopener noreferrer" href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/0=
19719.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-De=
cember/019719.html</a><br></div><div style=3D"box-sizing: inherit; quotes: =
&quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=
=80=99&quot;; line-height: normal;" dir=3D"auto"><br></div><pre style=3D"bo=
x-sizing: inherit; font-size: 14px; line-height: normal; margin: 0px; font-=
family: SFMono-Regular, Consolas, &quot;Liberation Mono&quot;, Menlo, monos=
pace, monospace; overflow-wrap: break-word; white-space: pre-wrap; height: =
auto; max-width: 100%; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; =
&quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; font-style: normal; font-varia=
nt-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-s=
pacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-trans=
form: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; t=
ext-decoration-thickness: initial; text-decoration-style: initial; text-dec=
oration-color: initial; background-color: rgb(255, 255, 255); color: rgb(0,=
 0, 0);"><span style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; =
&quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-hei=
ght: normal;"><span style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&q=
uot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;; lin=
e-height: normal;"><span style=3D"box-sizing: inherit; quotes: &quot;=E2=80=
=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99&quot;=
; line-height: normal;"><span style=3D"box-sizing: inherit; quotes: &quot;=
=E2=80=9C&quot; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=E2=80=99=
&quot;; line-height: normal;"><span style=3D"" class=3D""><span style=3D"" =
class=3D""><span class=3D"size" style=3D"font-size:14px">--
</span></span></span></span></span></span></span>Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP:&nbsp;43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br></pre><div><=
br></div><div class=3D""><div>=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<br></div><div>On Tuesday, January 4th, 2022 at 11:=
53 AM, Prayank via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt=
; wrote:<br></div><div><br></div><blockquote class=3D"" type=3D"cite"><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 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.<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 propo=
sed.<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 attempt=
 this of the knock on impacts and potential short term damage they are infl=
icting on the entire ecosystem.<br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">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.<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 promoter =
of this proposal (Jeremy Rubin) is pushing for an imminent attempted activa=
tion of a soft fork containing exclusively OP_CTV [2].<br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">He is doing nothing unexpected and got r=
easons to support OP_CTV being implemented soon.<br></div><div dir=3D"auto"=
><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; 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].<br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Because its not ready?<br></div><d=
iv 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 com=
parison between the two. If someone has worked on one of the speculated use=
s 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 Sapio=
 is something that would be more helpful for Bitcoin developers.<br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><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.<br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">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.<br></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; 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.<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 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.<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 sufficient ske=
pticism 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 proposal =
will be used by lot of Bitcoin projects and improve privacy, security, dece=
ntralization, 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 prior=
ity is to bring some attention to the danger of us stumbling into an attemp=
ted contentious soft fork activation attempt.<br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">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.<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 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.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">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.<br></div><div dir=3D"auto"><br></div><div =
dir=3D"auto"><br></div><div>-- <br></div><div>Prayank<br></div><div><br></d=
iv><div dir=3D"auto">A3B1 E430 2298 178F<br></div></blockquote></div></bloc=
kquote><div dir=3D"auto"><br></div></blockquote></div></blockquote><div dir=
=3D"auto"><br></div>  </body>
</html>

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