Date: Tue, 4 Jan 2022 16:06:28 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <Ms_c8Dw--3-2@tutanota.de>
In-Reply-To: <mS9BiAhDjDaA8BeRzKIJy7DggiCYkRuIaYISjT-G0v3fd88HDIiWS6UxUghkp-kA99Us1wxkNOyunsBnRVRClZcvgAgOSALl3RB_8z6YY-A=@protonmail.com>
References: <MsZvyxN--7-2@tutanota.de>
 <mS9BiAhDjDaA8BeRzKIJy7DggiCYkRuIaYISjT-G0v3fd88HDIiWS6UxUghkp-kA99Us1wxkNOyunsBnRVRClZcvgAgOSALl3RB_8z6YY-A=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_9567_1651322246.1641308789175"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation
 attempt
Precedence: list

------=_Part_9567_1651322246.1641308789175
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

What I have done related to OP_CTV?

https://twitter.com/prayankgahlot/status/1456643891885592579

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

Review pull request 21702 and write contracts using Sapio based on few idea=
s that I already have.

What is this assessment based on?

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

> you haven't thought about alternative proposals for any particular use ca=
se (vaults for example have multiple current alternative proposals and most=
 likely many future ones)

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

> A new programming language (Sapio) sounds great but do you you need it fo=
r your use case rather than an alternative high level language like Minsc? =
Sapio makes use of Miniscript which hasn't been finalized yet or updated fo=
r Taproot. Surely that needs to be done first otherwise Sapio is built on t=
op of something that isn't ready? When you make the claims such as a consen=
sus change is ready to go the burden is on you to convince me and other ske=
ptics why. The status quo is the default. "I think it is ready or will be r=
eady" doesn't mean much unless you have done the work.

TBH I am not against Miniscript and still waiting for its support in Core w=
hich might take another few years. I would love to have multiple programmin=
g languages so that application developers can decide what works best for t=
hem.

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

> It is not enough for one individual to say it is ready to be activated, a=
nyone who is expressing that view should understand why the opcode has been=
 designed in the way it has and why it is so important that we should dedic=
ate months of community time to getting a single opcode activated this year=
.

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

> You regularly NACK Core PRs yet you seem willing to wave a consensus chan=
ge through with no outstanding questions and zero skepticism.

I would NACK and write the reasons in this pull request as well if I find a=
ny issues and PR author is not addressing them. I had lots of questions at =
conceptual level which have been answered on different platforms and I cann=
ot document each conversation. Its a Concept ACK from me and none of the co=
ntributors could find any issues with PR right now so I don't want to stop =
people from improving Bitcoin.

> As I understand there are IRC workshops next week on BIP 119 [1] that I'd=
 encourage you to join so you can start getting into a position where you c=
an engage with the skeptics on technical concerns. Regrettably (as I said I=
 find this work interesting) I don't feel like I can participate because de=
ployment and activation is being included and I think it is irresponsible t=
o be discussing those at this point. In my view activation should not even =
be speculated upon until it is clear there is overwhelming community suppor=
t for a soft fork being activated.

I would be attending the workshops and had even requested Jeremy to use Twi=
tch because it would help more people understand things with audio, screen =
sharing etc. I would love to see skeptics participate and discuss technical=
 things.

> I don't feel like I can participate because deployment and activation is =
being included and I think it is irresponsible to be discussing those at th=
is point.

If you don't participate in the workshops you might miss few things. Howeve=
r, either Jeremy or one of the participants will ensure they share the summ=
ary here or even logs would be available.

--=20
Prayank

A3B1 E430 2298 178F



Jan 4, 2022, 19:45 by michaelfolkson@protonmail.com:

> >=C2=A0> It should be ready to go in a few months IMO
>
> What is this assessment based on? I am assuming you haven't done a code r=
eview of the opcode, you haven't coded up a real world use case of OP_CTV (=
or even a primitive proof of concept), you haven't thought about alternativ=
e proposals for any particular use case (vaults for example have multiple c=
urrent alternative proposals and most likely many future ones). A new progr=
amming language (Sapio) sounds great but do you you need it for your use ca=
se rather than an alternative high level language like Minsc? Sapio makes u=
se of Miniscript which hasn't been finalized yet or updated for Taproot. Su=
rely that needs to be done first otherwise Sapio is built on top of somethi=
ng that isn't ready? When you make the claims such as a consensus change is=
 ready to go the burden is on you to convince me and other skeptics why. Th=
e status quo is the default. "I think it is ready or will be ready" doesn't=
 mean much unless you have done the work.
>
> You are well aware of the review process in Core for non-consensus change=
s. For consensus changes you really should be digging even deeper, the bar =
should be higher and all questions you and others have should be explored i=
n depth. It is not enough for one individual to say it is ready to be activ=
ated, anyone who is expressing that view should understand why the opcode h=
as been designed in the way it has and why it is so important that we shoul=
d dedicate months of community time to getting a single opcode activated th=
is year.
>
> I have more sympathy for those who don't follow Bitcoin Core development =
and Bitcoin Core review on an ongoing basis (note as I said that the bar fo=
r consensus changes should be significantly higher than a non-consensus PR)=
. The use cases sound cool and the work is genuinely interesting. But hones=
tly for someone who has followed Bitcoin Core development, review for a whi=
le now you really should know better than bandy around statements like "it =
should be ready to go in a few months" when you currently haven't scratched=
 the surface on the utility and safety of this opcode. You regularly NACK C=
ore PRs yet you seem willing to wave a consensus change through with no out=
standing questions and zero skepticism.
>
> >=C2=A0If I had to select between a soft fork without any use cases and o=
ne with use cases, I would go with the one that has some use cases with cod=
e, documentation etc. You should propose a new opcode but OP_CTV is not cla=
iming to cure cancer.
>
> Multiple proven built out use cases, sure. Multiple is better than single=
 when you have done the work to ensure they are actually the right tool for=
 those multiple use cases. This work hasn't been done on any of these use c=
ases. The curing cancer analogy was used to elucidate the point that claims=
 should be deeply explored rather than just accepted as true.
>
> >> To contrast with his approach, the authors and contributors of another=
 future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t=
 promoting an imminent soft fork activation attempt and instead are buildin=
g out and testing one of the speculated use cases, eltoo payment channels [=
4].
>
> > Because its not ready?
>
> As I said it is not ready because the ANYPREVOUT contributors are buildin=
g out and testing a use case. The high bar on readiness should be applied t=
o all proposals not merely the ones where the authors/contributors decide t=
o impose a high bar themselves.
>
> I don't really want to spend my year imploring people to dig deeper on th=
is before indicating they support an imminent activation attempt. Some peop=
le don't have the understanding to dig deeper, some people don't have the t=
ime and some don't have either. However, if an activation of OP_CTV is atte=
mpted this year I am sure it will be contentious [0]. Anyone who cares abou=
t Bitcoin development and the ongoing technical work in a multitude of area=
s should be strongly against a contentious soft fork activation attempt was=
ting the time of developers and the entire ecosystem even if they don't hav=
e the understanding or time to appreciate the reasons why it is contentious=
.
>
> As I understand there are IRC workshops next week on BIP 119 [1] that I'd=
 encourage you to join so you can start getting into a position where you c=
an engage with the skeptics on technical concerns. Regrettably (as I said I=
 find this work interesting) I don't feel like I can participate because de=
ployment and activation is being included and I think it is irresponsible t=
o be discussing those at this point. In my view activation should not even =
be speculated upon until it is clear there is overwhelming community suppor=
t for a soft fork being activated.
>
> [0]:=C2=A0> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af52=
8d86a1b718
> [1]:=C2=A0> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-=
December/019719.html
>
> --> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: michae=
lfolksonPGP:=C2=A043ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
>  On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:
> =20
>
>> Hi Michael,
>>
>> > If OP_CTV is ready to go now and has overwhelming community support (I=
 don=E2=80=99t think either is true) it should surely have been included in=
 the Taproot soft fork (perhaps delayed) rather than going through the mont=
hs of activation wrangling and community outreach twice.
>>
>> It should be ready to go in a few months IMO and makes no sense to bundl=
e everything with Taproot soft fork. Things can remain separate and still c=
onsidered good enough based on the changes proposed.
>>
>>
>> > It should be made clear to any individual(s) that attempt this of the =
knock on impacts and potential short term damage they are inflicting on the=
 entire ecosystem.
>>
>> I don't see any damage with a soft fork that is being discussed since ye=
ars, documented properly, includes code for implementation and examples, re=
cently got crowdfunding to incentivize review process and improve security.
>>
>>
>> > It seems to me like the author and primary promoter of this proposal (=
Jeremy Rubin) is pushing for an imminent attempted activation of a soft for=
k containing exclusively OP_CTV [2].
>>
>> He is doing nothing unexpected and got reasons to support OP_CTV being i=
mplemented soon.
>>
>>
>> > To contrast with his approach, the authors and contributors of another=
 future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t=
 promoting an imminent soft fork activation attempt and instead are buildin=
g out and testing one of the speculated use cases, eltoo payment channels [=
4].
>>
>> Because its not ready?
>>
>>
>> > Similar work has not been done for any of the speculated use cases of =
OP_CTV.
>>
>> There is no comparison between the two. If someone has worked on one of =
the speculated uses cases, it makes no difference.
>>
>> If we still compare something because of our bias, maybe Sapio is someth=
ing that would be more helpful for Bitcoin developers.
>>
>>
>> > Instead Jeremy is encouraging people to =E2=80=9Csoft signal=E2=80=9D =
for soft fork activation of OP_CTV presumably in the hope that the building=
 out and testing of use cases can be completed post activation.
>>
>> We had soft signals from mining pools for Taproot as well and still wait=
ing for projects to use Taproot. Even miners signaling with speedy trial wa=
s not a guarantee they would follow new consensus rules later. I don't see =
anything wrong in looking for people who support a proposal and documenting=
 it.
>>
>>
>> > This is totally irresponsible in my view. A long list of speculated us=
e cases means nothing on its own. I can propose a new opcode OP_MAGIC and c=
laim it will cure cancer with no potential downsides and hence we should ha=
ve a soft fork activating it as soon as possible.
>>
>> If I had to select between a soft fork without any use cases and one wit=
h use cases, I would go with the one that has some use cases with code, doc=
umentation etc. You should propose a new opcode but OP_CTV is not claiming =
to cure cancer.
>>
>>
>> > I would hope there would be sufficient skepticism that this proposal w=
ouldn=E2=80=99t see the light of day.
>>
>> I am confident this proposal will be used by lot of Bitcoin projects and=
 improve privacy, security, decentralization, demand for block space etc.
>>
>>
>> > I feel the top priority is to bring some attention to the danger of us=
 stumbling into an attempted contentious soft fork activation attempt.
>>
>> I feel the danger is a few people able to stop soft forks that improve B=
itcoin because of their bias and opinions which are mostly non-technical.
>>
>>
>> > Enabling covenants on Bitcoin is a big step change with barely any exi=
sting research on the topic and attempting to rush it through by the back d=
oor so soon after Taproot activation should be resisted.
>>
>> Nobody has stopped anyone from doing research. There is no backdoor and =
everything is public. So soon? I am not sure if there are any issues with a=
 soft fork in next few months if its ready.
>>
>>
>> --=20
>> Prayank
>>
>> A3B1 E430 2298 178F
>>


------=_Part_9567_1651322246.1641308789175
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>What I have done related to OP_CTV?<br></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">https://twitter.com/prayankgahlot/status/1456643891885=
592579<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">What am I cur=
rently 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 reques=
t 21702 and write contracts using Sapio based on few ideas that I already h=
ave.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">What is this as=
sessment 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 o=
ther 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 a=
ny particular use case (vaults for example have multiple current alternativ=
e proposals and most likely many future ones)<br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">I have read enough about alternative proposals an=
d some of them don't even compete with OP_CTV, they can all be implemented =
and complement each other. Vaults is not the only thing that I care about a=
nd it would be better if we don't assume about research done by others.<br>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; A new programming =
language (Sapio) sounds great but do you you need it for your use case rath=
er than an alternative high level language like Minsc? Sapio makes use of M=
iniscript which hasn't been finalized yet or updated for Taproot. Surely th=
at needs to be done first otherwise Sapio is built on top of something that=
 isn't ready? When you make the claims such as a consensus change is ready =
to go the burden is on you to convince me and other skeptics why. The statu=
s quo is the default. "I think it is ready or will be ready" doesn't mean m=
uch unless you have done the work.<br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">TBH I am not against Miniscript and still waiting for its su=
pport in Core which might take another few years. I would love to have mult=
iple programming languages so that application developers can decide what w=
orks best for them.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
I don't understand what work are you expecting me to do in this case to sha=
re 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 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.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">I have dedicate=
d enough time reading everything related to OP_CTV and discuss things that =
were posted earlier here by Jeremy Rubin. Not sure how many skeptics did th=
e same or even tried to discuss anything until recent bounty was announced.=
<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 questions and zero skepticism.<br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">I would NACK and write the reasons in this pull r=
equest as well if I find any issues and PR author is not addressing them. I=
 had lots of questions at conceptual level which have been answered on diff=
erent platforms and I cannot document each conversation. Its a Concept ACK =
from me and none of the contributors could find any issues with PR right no=
w so I don't want to stop people from improving Bitcoin.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">&gt; As I understand there are IRC wo=
rkshops next week on BIP 119 [1] that I'd encourage you to join so you can =
start getting into a position where you can engage with the skeptics on tec=
hnical concerns. Regrettably (as I said I find this work interesting) I don=
't feel like I can participate because deployment and activation is being i=
ncluded and I think it is irresponsible to be discussing those at this poin=
t. In my view activation should not even be speculated upon until it is cle=
ar there is overwhelming community support for a soft fork being activated.=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">I would be attendin=
g the workshops and had even requested Jeremy to use Twitch because it woul=
d help more people understand things with audio, screen sharing etc. I woul=
d love to see skeptics participate and discuss technical things.<br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">&gt; I don't feel like I can p=
articipate because deployment and activation is being included and I think =
it is irresponsible to be discussing those at this point.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">If you don't participate in the works=
hops you might miss few things. However, either Jeremy or one of the partic=
ipants will ensure they share the summary here or even logs would be availa=
ble.<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></div><div><br></div><div>Jan 4, 2022, 19:45 by michaelfo=
lkson@protonmail.com:<br></div><blockquote class=3D"tutanota_quote" 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; f=
ont-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400;=
 letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-dec=
oration-thickness: initial; text-decoration-style: initial; text-decoration=
-color: initial; float: none; display: inline !important;"><span class=3D""=
 style=3D""><span style=3D"font-family:-apple-system, &quot;system-ui&quot;=
, &quot;Segoe UI&quot;, Roboto, Oxygen-Sans, Ubuntu, Cantarell, &quot;Helve=
tica Neue&quot;, sans-serif" class=3D""><span class=3D"" style=3D""><span s=
tyle=3D"font-size:14px" class=3D"">It should be ready to go in a few months=
 IMO</span></span></span></span></span><br></div><div><br></div><div>What i=
s this assessment based on? I am assuming you haven't done a code review of=
 the opcode, you haven't coded up a real world use case of OP_CTV (or even =
a primitive proof of concept), you haven't thought about alternative propos=
als for any particular use case (vaults for example have multiple current a=
lternative proposals and most likely many future ones). A new programming l=
anguage (Sapio) sounds great but do you you need it for your use case rathe=
r than an alternative high level language like Minsc? Sapio makes use of Mi=
niscript which hasn't been finalized yet or updated for Taproot. Surely tha=
t needs to be done first otherwise Sapio is built on top of something that =
isn't ready? When you make the claims such as a consensus change is ready t=
o go the burden is on you to convince me and other skeptics why. The status=
 quo is the default. "I think it is ready or will be ready" doesn't mean mu=
ch unless you have done the work.<br></div><div><br></div><div>You are well=
 aware of the review process in Core for non-consensus changes. For consens=
us changes you really should be digging even deeper, the bar should be high=
er and all questions you and others have should be explored in depth. It is=
 not enough for one individual to say it is ready to be activated, anyone w=
ho is expressing that view should understand why the opcode has been design=
ed in the way it has and why it is so important that we should dedicate mon=
ths of community time to getting a single opcode activated this year.<br></=
div><div><br></div><div>I have more sympathy for those who don't follow Bit=
coin Core development and Bitcoin Core review on an ongoing basis (note as =
I said that the bar for consensus changes should be significantly higher th=
an a non-consensus PR). The use cases sound cool and the work is genuinely =
interesting. But honestly for someone who has followed Bitcoin Core develop=
ment, review for a while now you really should know better than bandy aroun=
d statements like "it should be ready to go in a few months" when you curre=
ntly haven't scratched the surface on the utility and safety of this opcode=
. You regularly NACK Core PRs yet you seem willing to wave a consensus chan=
ge through with no outstanding questions and zero skepticism.<br></div><div=
><br></div><div>&gt;&nbsp;If I had to select between a soft fork without an=
y use cases and one with use cases, I would go with the one that has some u=
se cases with code, documentation etc. You should propose a new opcode but =
OP_CTV is not claiming to cure cancer.<br></div><div style=3D"box-sizing: i=
nherit; 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"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;" dir=3D"auto">Multiple proven built out use cases, sure. Multiple is be=
tter than single when you have done the work to ensure they are actually th=
e right tool for those multiple use cases. This work hasn't been done on an=
y of these use cases. The curing cancer analogy was used to elucidate the p=
oint that claims should be deeply explored rather than just accepted as tru=
e.<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 another future soft fork proposa=
l (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t promoting an imminent so=
ft fork activation attempt and instead are building out and testing one of =
the speculated use cases, eltoo payment channels [4].<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"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">&gt; Because its 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&quot;; 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 said it is not ready becaus=
e the ANYPREVOUT contributors are building out and testing a use case. The =
high bar on readiness should be applied to all proposals not merely the one=
s where the authors/contributors decide to impose a high bar themselves.<br=
></div><div style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &qu=
ot;=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"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">I don't really want to =
spend my year imploring people to dig deeper on this before indicating they=
 support an imminent activation attempt. Some people don't have the underst=
anding to dig deeper, some people don't have the time and some don't have e=
ither. However, if an activation of OP_CTV is attempted this year I am sure=
 it will be contentious [0]. Anyone who cares about Bitcoin development and=
 the ongoing technical work in a multitude of areas should be strongly agai=
nst a contentious soft fork activation attempt wasting the time of develope=
rs and the entire ecosystem even if they don't have the understanding or ti=
me to appreciate the reasons why it is contentious.<br></div><div style=3D"=
box-sizing: inherit; quotes: &quot;=E2=80=9C&quot; &quot;=E2=80=9D&quot; &q=
uot;=E2=80=98&quot; &quot;=E2=80=99&quot;; line-height: normal;" dir=3D"aut=
o"><br></div><div style=3D"box-sizing: inherit; quotes: &quot;=E2=80=9C&quo=
t; &quot;=E2=80=9D&quot; &quot;=E2=80=98&quot; &quot;=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 skeptics on technical concer=
ns. Regrettably (as I said I find this work interesting) I don't feel like =
I can participate because deployment and activation is being included and I=
 think it is irresponsible to be discussing those at this point. In my view=
 activation should not even be speculated upon until it is clear there is o=
verwhelming community support for a soft fork being activated.<br></div><di=
v 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"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]:&nbsp;<a target=3D"_blank" r=
el=3D"noopener noreferrer" href=3D"https://gist.github.com/michaelfolkson/3=
52a503f4f9fc5de89af528d86a1b718">https://gist.github.com/michaelfolkson/352=
a503f4f9fc5de89af528d86a1b718</a><br></div><div style=3D"box-sizing: inheri=
t; 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">[1]:&nbsp;<a ta=
rget=3D"_blank" rel=3D"noopener noreferrer" href=3D"https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2021-December/019719.html">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2021-December/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"box-sizing: inherit; font-siz=
e: 14px; line-height: normal; margin: 0px; font-family: SFMono-Regular, Con=
solas, &quot;Liberation Mono&quot;, Menlo, monospace, monospace; overflow-w=
rap: break-word; white-space: pre-wrap; height: auto; max-width: 100%; quot=
es: &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-ligatures: normal; font-=
variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2;=
 text-align: start; text-indent: 0px; text-transform: none; widows: 2; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: i=
nitial; text-decoration-style: initial; text-decoration-color: initial; bac=
kground-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: 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"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"" class=3D""><span style=3D"font-size:14px" class=3D"">=
--
</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&g=
t; wrote:<br></div><div> <br></div><blockquote class=3D"" type=3D"cite"><di=
v>Hi Michael,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; I=
f OP_CTV is ready to go now and has overwhelming community support (I don=
=E2=80=99t think either is true) it should surely have been included in the=
 Taproot soft fork (perhaps delayed) rather than going through the months o=
f activation wrangling and community outreach twice.<br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">It should be ready to go in a few months I=
MO and makes no sense to bundle everything with Taproot soft fork. Things c=
an remain separate and still considered good enough based on the changes pr=
oposed.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">&gt; It should be made clear to any individual(s) that atte=
mpt this of the knock on impacts and potential short term damage they are i=
nflicting on the entire ecosystem.<br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">I don't see any damage with a soft fork that is being discus=
sed since years, documented properly, includes code for implementation and =
examples, recently got crowdfunding to incentivize review process and impro=
ve security.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">&gt; It seems to me like the author and primary promot=
er of this proposal (Jeremy Rubin) is pushing for an imminent attempted act=
ivation of a soft fork containing exclusively OP_CTV [2].<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">He is doing nothing unexpected and go=
t reasons to support OP_CTV being implemented soon.<br></div><div dir=3D"au=
to"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; To contras=
t with his approach, the authors and contributors of another future soft fo=
rk proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren=E2=80=99t promoting an i=
mminent soft fork activation attempt and instead are building out and testi=
ng one of the speculated use cases, eltoo payment channels [4].<br></div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Because its not ready?<br></div=
><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><d=
iv dir=3D"auto">If we still compare something because of our bias, maybe Sa=
pio is something that would be more helpful for Bitcoin developers.<br></di=
v><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 buildin=
g out 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 minin=
g pools for Taproot as well and still waiting for projects to use Taproot. =
Even miners signaling with speedy trial was not a guarantee they would foll=
ow new consensus rules later. I don't see anything wrong in looking for peo=
ple who support a proposal and documenting it.<br></div><div dir=3D"auto"><=
br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; This is totally=
 irresponsible in my view. A long list of speculated use cases means nothin=
g on its own. I can propose a new opcode OP_MAGIC and claim it will cure ca=
ncer with no potential downsides and hence we should have a soft fork activ=
ating it as soon as possible.<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 co=
de, documentation etc. You should propose a new opcode but OP_CTV is not cl=
aiming to cure cancer.<br></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">&gt; I would hope there would be sufficient =
skepticism that this proposal wouldn=E2=80=99t see the light of day.<br></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">I am confident this propos=
al will be used by lot of Bitcoin projects and improve privacy, security, d=
ecentralization, demand for block space etc.<br></div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; I feel the top pr=
iority is to bring some attention to the danger of us stumbling into an att=
empted contentious soft fork activation attempt.<br></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">I feel the danger is a few people able to stop=
 soft forks that improve Bitcoin because of their bias and opinions which a=
re mostly non-technical.<br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">&gt; Enabling covenants on Bitcoin is a bi=
g step change with barely any existing research on the topic and attempting=
 to rush it through by the back door so soon after Taproot activation shoul=
d be resisted.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Nobod=
y has stopped anyone from doing research. There is no backdoor and everythi=
ng is public. So soon? I am not sure if there are any issues with a soft fo=
rk in next few months if its ready.<br></div><div dir=3D"auto"><br></div><d=
iv 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></blockquote></div></b=
lockquote><div dir=3D"auto"><br></div>  </body>
</html>

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