path: root/cd/aa911930435b2572c0c8eb33bd6c40beea32e2

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A6D30C002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 04:03:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 944A340186
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 04:03:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 5fAzJQRt5_fE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 04:03:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [IPv6:2a00:1450:4864:20::631])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 74B3940129
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 04:03:23 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id bv19so7424419ejb.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Apr 2022 21:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=9N8ieUVo9vtklvi5EHswepmJlYm4LpRyieK4kt6ZdZE=;
 b=fcgiJzLK8sO27bB8qJeiAAJBD1tM/fG1wqR/q4oGRLnniyTcFH2c6T2J1Ftfo0ie5X
 n8W2W8pBircSsZNXXlWJovpuyv18dnC9eiEbiCq/T7YVFFIgliWchYvBEnwyBTt+Ao6a
 oGkG9Eytaheauz+5Dovv6czm58MMoy0Q6j19ACd0eGy/QDntwdzE1arjqZW99lMLdZyo
 qpDYV56CiWS9eY0TwoKoDrGJeLHqW5SpwiInFMP1/nqiC4FLQMaPJOgvNS9pW26OzMAY
 x4EZ0cXT6LblI4n9ND4SCyAcfRqPttVyuXiaJhB85FFBIhCBtwOMvhSxOf5SPTgg1zlO
 R2jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=9N8ieUVo9vtklvi5EHswepmJlYm4LpRyieK4kt6ZdZE=;
 b=yfPNkgsG0mH0zh7qSYVTajiX1jNnKHynnPq+nyH6HcMVAtDyRRCJ1ECtk8X2BrB+Zm
 o8ObSNe95TpytHqIltthNvQrDZD/ZITHvurVNsBWrDcoGjOjOLxZxlntK0SiyM9N+STB
 oFXbOD1eQWp9dG2u8VWjKs4poITQqAsUJxXnbJpS69M4mJ523siQamN9IlTFWsucz4yC
 MVGpYZuA8JcYzFwdHlTdJ0adxyVryBJei19dW/YO3l373MkW2mitCu2Z/gCMSGTBBi+5
 GWuSKojYK52uhGoGRNJp2s/lTp+Jo01x7/22fn4fUR7BOyQHNTbO4xFMiXKvuYs49rUx
 0uxg==
X-Gm-Message-State: AOAM533/hcBauKCNfOaWRPx+8HwP9ObePPWF3VISR8TC23C+jb4W2bZt
 J6cbSIyHAYpeJr8IFzkN00lsDQC9uirMI1BryPQemBeQczE=
X-Google-Smtp-Source: ABdhPJy1uFd1I0f+gYjtcHMR985qbyLVh1i29lxrAZPAP6SMlajYqJAaGHi7DVIFPzIxFNWNRZqrd20PApy1f47j1Bc=
X-Received: by 2002:a17:907:6d23:b0:6d9:ac9d:222 with SMTP id
 sa35-20020a1709076d2300b006d9ac9d0222mr21437667ejc.595.1650513801360; Wed, 20
 Apr 2022 21:03:21 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjVS4Y4e3qDWzJfva+0hiKpe8-WqmX_kUHrpfXmG5sMXw@mail.gmail.com>
 <uUzpB7Sapu5q3qxF7voLmwRIJfLPGCwcelhFVR8BClM7HBi9n86zj1A6SeYBdKZXOGL-8C049G1mEURDkyNMhksyPMfjIMPJXHoidOydAT8=@protonmail.com>
In-Reply-To: <uUzpB7Sapu5q3qxF7voLmwRIJfLPGCwcelhFVR8BClM7HBi9n86zj1A6SeYBdKZXOGL-8C049G1mEURDkyNMhksyPMfjIMPJXHoidOydAT8=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 20 Apr 2022 23:03:05 -0500
Message-ID: <CAGpPWDYP07uWLiPSu-r9qhoLgiVdR3z+Mnay-P8-hS8ued1RKA@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d3bb0d05dd2230c0"
X-Mailman-Approved-At: Thu, 21 Apr 2022 10:09:14 +0000
Subject: Re: [bitcoin-dev] 7 Theses on a next step for BIP-119
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: Thu, 21 Apr 2022 04:03:25 -0000

--000000000000d3bb0d05dd2230c0
Content-Type: text/plain; charset="UTF-8"

Hi Michael,

I'm sympathetic to the idea of allowing time for the community to absorb,
review, analyze, discuss, etc any new substantial change to bitcoin,
especially consensus changes. I certainly think that over time the
frequency of soft forks should generally go down on average, with
ossification at some point being the ideal endpoint (perhaps in the next
10-20 years).

However, many of the messages of opposition/caution seem to imply that
analysis of a consensus change can't begin until the last change has been
completed. This is quite clearly not the case. And as far as I can tell the
CTV spec was functionally completed *before* the taproot spec was (sometime
in early 2020).

Jeremy included a nice list of "ticked boxes" that are all indicators of
maturity of not only the spec but implementations and testing. I would
expect any considered opposition to CTV to at least address that checklist,
but you did not.

I think it would be interesting to compare the state of CTV now with the
state of taproot when activation. One example is that Taproot had been on
Signet for about 1 month
<https://www.coindesk.com/tech/2021/01/14/bitcoin-cores-latest-release-is-out-heres-whats-in-it/>
before
consensus developed <https://gnusha.org/taproot-activation/2021-02-16.log>
in support of pulling the trigger on a softfork for taproot. CTV has had a
signet running for almost twice that long already if not longer. So
Michael, what do you think is missing from Jeremy's checklist? Where do you
think the checklist fails to meet your ideal bar of acceptance?

Not only that but CTV is a simpler change than taproot. I assume you'd
agree that a simpler change should require correspondingly less
review/analysis/etc, right? If not, I'd appreciate it if you could comment
as to why.

> There are a number of individuals who have stated opposition to
attempting to activate a CTV soft fork in the near term

As Jeremy has noted, none of these indicate or suspect any technical issues
in CTV. Basically all of them are basically saying "too soon" without much
concrete reasons. I believe in consensus weighted by quality-of-logic, and
most of the ones in your list do not contain any supported logic at all.
Many are borderline ad hominems at Jeremy. So to me, most hold little
weight. The ones with some logic included seem to basically be "I'm not
involved enough to know or knowledgeable enough to review, and therefore
I'm hesitant". Now to be fair, many of the acks listed in Jeremy's also
hold little weight to me for the same reasons, with a few exceptions like Bram
Cohen's discussion
<https://twitter.com/bramcohen/status/1224823869933899776> and a Corenell
paper <https://arxiv.org/abs/2005.11776>. But there's clearly been quite a
bit of review on the PR <https://github.com/bitcoin/bitcoin/pull/21702> as
well. By contrast I've seen literally no opposition to CTV based on the
proposal at all.

With regards to the idea that more time is needed to review/discuss. I
wonder if any of those opposed to near term speedy trial of CTV plan on
doing a deeper review/exploration of it in the next year? If not, then what
will delaying do? Are these people simply waiting to see more people in
their social bubble becomes familiar and comfortable with CTV?

> I have a better (and safer) way forward which is to continue to build out
use cases of CTV, convince the community it is the best tool for the job
(whatever use case(s) that is), compare it to other existing covenant
enabling proposals

While I think this is a more valid position to take than your other points,
I disagree with it. I am also sympathetic to the idea that alternatives
should be evaluated and the best one at hand should be chosen. However, it
is a simple fact that the "best" solution possible is almost never going to
be found or created, even after absurd amounts of time (eg millenia). We
live in a time bound world, with time bound human lives. I assume you've
heard of the phrase "don't let the perfect become the enemy of the good". I
assert that your argument is to do just that: to make the perfect become
the enemy of the good.

There is some trade off between time to usage (think time to market) and
the quality of the solution. We didn't choose taproot because it was the
best possible solution, we chose it because it was a pretty good solution
and the solution we had. Yes alternatives have been discussed (at least
since 2013), but alternatives to CTV have also been discussed (eg OP_CAT)
for probably just as long. There have been a number of random
back-of-the-napkin alternative proposals to CTV. None have gained anything
resembling support. I proposed one of them
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>
myself. And I certainly agree that CTV isn't perfect and doesn't do
everything I want it to do. But despite this, I think having CTV is better
than not having it. Even if its eventually mostly replaced by some more
complex covenant opcode, CTV can provide a LOT of value in a number of ways
until that point (which will likely be at least 4 years). And its also
likely that a more full featured covenant opcode will take *longer* if CTV
doesn't get out there and show the uninformed why covenants are important.

As far as I can tell, its uncontroversial that CTV is the simplest and
safest of all the covenant proposals. Do you disagree?

> Taproot had overwhelming community consensus so it had much less chain
split risk

IMO this is a completely invalid argument. If a speedy trial is done and
90% miner activation happens, that is quite a high supermajority
percentage. If such a thing happens, there is basically 0 chance of any
chain split happening directly from activation. The only chain split risk,
then, would be from anyone who thinks it would be then worth it to hard
fork away from that chain, which you have already said you wouldn't be one
of. So I have to say, this additional chain split risk you speak of sounds
completely imaginary to me.

~BT

On Wed, Apr 20, 2022 at 8:49 AM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > The client has a Speedy trial release similar to Taproots with
> parameters proposed to be....
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it
> wastes the time of people who could be working on all sorts of valuable
> projects for the ecosystem. Worst case, we take a Russian roulette style
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new
> soft fork code, either CTV code or any new activation code. Running Bitcoin
> Core 23.0 out the box will not signal for any new soft fork and will not
> enforce any new soft fork rules (CTV or otherwise). Of course it will
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest
> blog post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client
> attempting to activate CTV. One would expect that many will continue to run
> versions of Bitcoin Core that will not enforce CTV rules and will not
> activate it. But whether Jeremy's client will be a majority, significant
> minority, insignificant minority of full nodes and miners would be
> speculation on my part. (Personally I highly doubt those running Jeremy's
> client will be a majority which leaves a significant minority and
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar
> parameters to that used for Taproot. That would mean seeking 90 percent of
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries again with a different activation
> attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but
> presumably still a possibility) then the CTV soft fork could activate
> unless full nodes resist it. This resistance would most likely be in the
> form of a UASF style client which rejects blocks that apply the CTV rules
> and/or includes transactions that don't meet the CTV rules post activation.
> We would now be in chain split territory with two different assets and
> blockchains like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk
> what should I do?
>
> Firstly, you can register your opposition to this soft fork activation
> attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it
> will be useful for others to see clearly that this a contentious soft fork
> activation attempt and act accordingly. So far only 3 individuals'
> opposition is registered on his site.
>
> Secondly, if it is looking like 90 percent (or whatever percentage Jeremy
> uses) of miners are going to signal for a CTV soft fork then you can
> consider joining a UASF style effort to resist the soft fork activation
> attempt. I will certainly seek to participate and will continue to inform
> this list of efforts in this direction.
>
> The saddest thing is that if Jeremy's soft fork activation attempt causes
> the uncertainty, confusion and disruption I fear it could it will make
> future soft forks that do have community consensus orders of magnitude
> harder to pull off. There are a number of soft fork proposals that I'm
> personally excited about (enabling covenants, eltoo, Simplicity, CISA etc)
> that long term we might get with a sensible approach to only activating
> soft forks that have community consensus. But the more uncertainty,
> confusion and disruption we create over contentious soft forks the more
> dangerous any soft fork of any form will appear. The primary focus will
> need to be resisting soft forks that don't have community consensus and
> ensuring Bitcoin doesn't splinter into a large number of different
> assets/blockchains with different combinations of soft forks active.
>
> So if you oppose this soft fork activation attempt please voice your
> opposition, run full node software that doesn't include CTV and CTV
> activation code such as Bitcoin Core and if/when necessary and available
> run full node software that proactively rejects application of the CTV
> rules.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Devs,
>
> In advance of the CTV meeting today, I wanted to share what my next step
> is in advocating for CTV, as well as 7 theses for why I believe it to be
> the right course of action to take at this time.
>
> Please see the post at
> https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.
>
> As always, open to hear any and all feedback,
>
> Jeremy
>
>
> archived at:
> https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000d3bb0d05dd2230c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Michael,<div><br></div><div>I&#39;m sympathetic to the =
idea of allowing time for the community to absorb, review, analyze, discuss=
, etc any new substantial change to bitcoin, especially consensus changes. =
I certainly think that over time the frequency of soft forks should general=
ly go down on average, with ossification at some point being the ideal endp=
oint (perhaps in the next 10-20 years).=C2=A0</div><div><br></div><div>Howe=
ver, many of the messages of opposition/caution seem to imply that analysis=
 of a consensus change can&#39;t begin until the last change has been compl=
eted. This is quite clearly not the case. And as far as I can tell the CTV =
spec was functionally completed *before* the taproot spec was (sometime in =
early 2020).=C2=A0</div><div><br></div><div>Jeremy included a nice list of =
&quot;ticked boxes&quot; that are all indicators of maturity of not only th=
e spec but implementations and testing. I would expect any considered oppos=
ition to CTV to at least address that checklist, but you did not.=C2=A0</di=
v><div><br></div><div>I think it would be interesting to compare the state =
of CTV now with the state of taproot when activation. One example is that T=
aproot had been on Signet for about <a href=3D"https://www.coindesk.com/tec=
h/2021/01/14/bitcoin-cores-latest-release-is-out-heres-whats-in-it/" target=
=3D"_blank">1 month</a>=C2=A0before <a href=3D"https://gnusha.org/taproot-a=
ctivation/2021-02-16.log" target=3D"_blank">consensus developed</a> in supp=
ort of pulling the trigger on a softfork for taproot. CTV has had a signet =
running for almost twice that long already if not longer. So Michael, what =
do you think is missing from Jeremy&#39;s checklist? Where do you think the=
 checklist fails to meet your ideal bar of acceptance?</div><div><br></div>=
<div>Not only that but CTV is a simpler change than taproot. I assume you&#=
39;d agree that a simpler change should require correspondingly less review=
/analysis/etc, right? If not, I&#39;d appreciate it if you could comment as=
 to why.</div><div><br></div><div>&gt;=C2=A0<span style=3D"font-family:aria=
l;font-size:14px">There are a number of individuals who have stated opposit=
ion to attempting to activate a CTV soft fork in the near term</span></div>=
<div><span style=3D"font-family:arial;font-size:14px"><br></span></div><div=
><span style=3D"font-family:arial;font-size:14px">As Jeremy has noted, none=
 of these indicate or suspect any technical issues in CTV. Basically all of=
 them are basically saying &quot;too soon&quot; without much concrete reaso=
ns. I believe in consensus weighted by quality-of-logic, and most of the on=
es in your list do not contain any supported logic at all. Many are borderl=
ine ad hominems at Jeremy. So to me, most hold little weight. The ones with=
 some logic included seem to basically be &quot;I&#39;m not involved enough=
 to know=C2=A0</span><span style=3D"font-family:arial;font-size:14px">or kn=
owledgeable</span><span style=3D"font-family:arial;font-size:14px">=C2=A0en=
ough to review</span><span style=3D"font-family:arial;font-size:14px">, and=
 therefore I&#39;m hesitant&quot;. Now to be fair, many of the acks listed =
in Jeremy&#39;s also hold little weight to me for the same reasons, with a =
few exceptions like <a href=3D"https://twitter.com/bramcohen/status/1224823=
869933899776" target=3D"_blank">Bram Cohen&#39;s discussion</a>=C2=A0and a =
<a href=3D"https://arxiv.org/abs/2005.11776" target=3D"_blank">Corenell pap=
er</a>. But there&#39;s clearly been quite a bit of review <a href=3D"https=
://github.com/bitcoin/bitcoin/pull/21702" target=3D"_blank">on the PR</a> a=
s well. By contrast I&#39;ve seen literally no opposition to CTV based on t=
he proposal at all.=C2=A0</span></div><div><span style=3D"font-family:arial=
;font-size:14px"><br></span></div><div>With regards to the idea that more t=
ime is needed to review/discuss. I wonder if any of those opposed to near t=
erm speedy trial of CTV plan on doing a deeper review/exploration of it in =
the next year? If not, then what will delaying do? Are these people simply =
waiting to see more people in their social bubble becomes familiar and comf=
ortable with CTV?</div><div><br></div><div>&gt;=C2=A0<span style=3D"font-fa=
mily:arial;font-size:14px">I have a better (and safer) way forward which is=
 to continue to build out use cases of CTV, convince the community it is th=
e best tool for the job (whatever use case(s) that is), compare it to other=
 existing covenant enabling proposals</span><span style=3D"font-family:aria=
l;font-size:14px">=C2=A0</span></div><div><span style=3D"font-family:arial;=
font-size:14px"><br></span></div><div><span style=3D"font-family:arial;font=
-size:14px">While I think this is a more valid position to take than your o=
ther points, I disagree with it. I am also sympathetic to the idea that alt=
ernatives should be evaluated and the best one at hand should be chosen. Ho=
wever, it is a simple fact that the &quot;best&quot; solution possible is a=
lmost never going to be found or created, even after absurd amounts of time=
 (eg millenia). We live in a time bound world, with time bound human lives.=
 I assume you&#39;ve heard of the phrase &quot;don&#39;t let the perfect be=
come the enemy of the good&quot;. I assert that your argument is to do just=
 that: to make the perfect become the enemy of the good.=C2=A0</span></div>=
<div><span style=3D"font-family:arial;font-size:14px"><br></span></div><div=
><span style=3D"font-family:arial;font-size:14px">There is some trade off b=
etween time to usage (think time to market) and the quality of the solution=
. We didn&#39;t choose taproot because it was the best possible solution, w=
e chose it because it was a pretty good solution and the solution we had. Y=
es alternatives have been discussed (at least since 2013), but alternatives=
 to CTV have also been discussed (eg OP_CAT) for probably just as long. The=
re have been a number of random back-of-the-napkin alternative proposals to=
 CTV. None have gained anything resembling support. I proposed <a href=3D"h=
ttps://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip=
-constraindestination.md">one of them</a> myself. And I certainly agree tha=
t CTV isn&#39;t perfect and doesn&#39;t do everything I want it to do. But =
despite this, I think having CTV is better than not having it. Even if its =
eventually mostly replaced by some more complex covenant opcode, CTV can pr=
ovide a LOT of value in a number of ways until that point (which will likel=
y be at least 4 years). And its also likely that a more full featured coven=
ant opcode will take *longer* if CTV doesn&#39;t get out there and show the=
 uninformed why covenants are important.=C2=A0</span><span style=3D"font-fa=
mily:arial;font-size:14px"><br></span></div><div><span style=3D"font-family=
:arial;font-size:14px"><br></span></div><div><span style=3D"font-family:ari=
al;font-size:14px">As far as I can tell, its uncontroversial that CTV is th=
e simplest and safest of all the covenant proposals. Do you disagree?=C2=A0=
</span></div><div><br></div><div><font face=3D"arial"><span style=3D"font-s=
ize:14px">&gt;=C2=A0</span></font><span style=3D"font-family:arial;font-siz=
e:14px">Taproot had overwhelming community consensus so it had much less ch=
ain split risk</span></div><div><span style=3D"font-family:arial;font-size:=
14px"><br></span></div><div><span style=3D"font-family:arial;font-size:14px=
">IMO this is a completely invalid argument. If a speedy=C2=A0trial is done=
 and 90% miner activation happens, that is quite a high supermajority perce=
ntage. If such a thing happens, there is basically 0 chance of any chain sp=
lit happening directly from activation. The only chain split risk, then, wo=
uld be from anyone who thinks it would be then worth it to hard fork away f=
rom that chain, which you have already said you wouldn&#39;t be one of. So =
I have to say, this additional chain split risk you speak of sounds complet=
ely imaginary to me.=C2=A0</span></div><div><span style=3D"font-family:aria=
l;font-size:14px"><br></span></div><div><span style=3D"font-family:arial;fo=
nt-size:14px">~BT</span></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Apr 20, 2022 at 8:49 AM Michael Folks=
on via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"f=
ont-family:arial;font-size:14px">&gt; The client has a Speedy trial release=
 similar to Taproots with parameters proposed to be....</div><div style=3D"=
font-family:arial;font-size:14px"><br></div><div style=3D"font-family:arial=
;font-size:14px">As I&#39;ve said before I was hoping we&#39;d avoid this e=
xercise. Best case, it wastes the time of people who could be working on al=
l sorts of valuable projects for the ecosystem. Worst case, we take a Russi=
an roulette style gamble with a chain split.=C2=A0</div><div style=3D"font-=
family:arial;font-size:14px"><br></div><div style=3D"font-family:arial;font=
-size:14px">But here&#39;s a summary of the basic facts:</div><div style=3D=
"font-family:arial;font-size:14px"><br></div><div style=3D"font-family:aria=
l;font-size:14px">The latest Bitcoin Core release candidate (23.0) does not=
 contain any new soft fork code, either CTV code or any new activation code=
. Running Bitcoin Core 23.0 out the box will not signal for any new soft fo=
rk and will not enforce any new soft fork rules (CTV or otherwise). Of cour=
se it will continue to enforce Taproot rules as Taproot activated last year=
.</div><div style=3D"font-family:arial;font-size:14px"><br></div><div style=
=3D"font-family:arial;font-size:14px">There are a number of individuals who=
 have stated opposition to attempting to activate a CTV soft fork in the ne=
ar term:</div><div style=3D"font-family:arial;font-size:14px"><br></div><di=
v style=3D"font-family:arial;font-size:14px"><a rel=3D"noreferrer nofollow =
noopener" href=3D"https://gist.github.com/michaelfolkson/352a503f4f9fc5de89=
af528d86a1b718" target=3D"_blank">https://gist.github.com/michaelfolkson/35=
2a503f4f9fc5de89af528d86a1b718</a>=C2=A0</div><div style=3D"font-family:ari=
al;font-size:14px"><br></div><div style=3D"font-family:arial;font-size:14px=
">Most of those individuals haven&#39;t logged their opposition on Jeremy&#=
39;s site:</div><div style=3D"font-family:arial;font-size:14px"><a rel=3D"n=
oreferrer nofollow noopener" href=3D"https://utxos.org/signals/" target=3D"=
_blank">https://utxos.org/signals/</a></div><div style=3D"font-family:arial=
;font-size:14px"><br></div><div style=3D"font-family:arial;font-size:14px">=
Hence their views haven&#39;t been included or discussed in Jeremy&#39;s la=
test blog post.</div><div style=3D"font-family:arial;font-size:14px"><br></=
div><div style=3D"font-family:arial;font-size:14px">Chain split risk</div><=
div style=3D"font-family:arial;font-size:14px"><br></div><div style=3D"font=
-family:arial;font-size:14px">I can&#39;t predict how many full nodes and m=
iners will run Jeremy&#39;s client attempting to activate CTV. One would ex=
pect that many will continue to run versions of Bitcoin Core that will not =
enforce CTV rules and will not activate it. But whether Jeremy&#39;s client=
 will be a majority, significant minority, insignificant minority of full n=
odes and miners would be speculation on my part. (Personally I highly doubt=
 those running Jeremy&#39;s client will be a majority which leaves a signif=
icant minority and insignificant minority as the most likely options).</div=
><div style=3D"font-family:arial;font-size:14px"><br></div><div style=3D"fo=
nt-family:arial;font-size:14px">Jeremy&#39;s client is intending to use Spe=
edy Trial presumably with similar parameters to that used for Taproot. That=
 would mean seeking 90 percent of miners to signal for this CTV soft fork a=
ctivation attempt.=C2=A0</div><div style=3D"font-family:arial;font-size:14p=
x"><br></div><div style=3D"font-family:arial;font-size:14px">Assuming 90 pe=
rcent of miners don&#39;t signal for it in one of the Speedy Trial windows =
then the activation attempt will have failed and it will be back in Jeremy&=
#39;s court whether he tries again with a different activation attempt.</di=
v><div style=3D"font-family:arial;font-size:14px"><br></div><div style=3D"f=
ont-family:arial;font-size:14px">Assuming 90 percent of miners do signal fo=
r it (unlikely in my opinion but presumably still a possibility) then the C=
TV soft fork could activate unless full nodes resist it. This resistance wo=
uld most likely be in the form of a UASF style client which rejects blocks =
that apply the CTV rules and/or includes transactions that don&#39;t meet t=
he CTV rules post activation. We would now be in chain split territory with=
 two different assets and blockchains like we had with BTC and BCH.</div><d=
iv style=3D"font-family:arial;font-size:14px"><br></div><div style=3D"font-=
family:arial;font-size:14px">If I oppose this activation attempt and the as=
sociated chain split risk what should I do?</div><div style=3D"font-family:=
arial;font-size:14px"><br></div><div style=3D"font-family:arial;font-size:1=
4px">Firstly, you can register your opposition to this soft fork activation=
 attempt on Jeremy&#39;s site:=C2=A0<span><a rel=3D"noreferrer nofollow noo=
pener" href=3D"https://utxos.org/signals/" target=3D"_blank">https://utxos.=
org/signals/</a></span></div><div style=3D"font-family:arial;font-size:14px=
"><br></div><div style=3D"font-family:arial;font-size:14px">It seems Jeremy=
 will continue this activation attempt regardless but it will be useful for=
 others to see clearly that this a contentious soft fork activation attempt=
 and act accordingly. So far only 3 individuals&#39; opposition is register=
ed on his site.</div><div style=3D"font-family:arial;font-size:14px"><br></=
div><div style=3D"font-family:arial;font-size:14px">Secondly, if it is look=
ing like 90 percent (or whatever percentage Jeremy uses) of miners are goin=
g to signal for a CTV soft fork then you can consider joining a UASF style =
effort to resist the soft fork activation attempt. I will certainly seek to=
 participate and will continue to inform this list of efforts in this direc=
tion.=C2=A0</div><div style=3D"font-family:arial;font-size:14px"><br></div>=
<div style=3D"font-family:arial;font-size:14px">The saddest thing is that i=
f Jeremy&#39;s soft fork activation attempt causes the uncertainty, confusi=
on and disruption I fear it could it will make future soft forks that do ha=
ve community consensus orders of magnitude harder to pull off. There are a =
number of soft fork proposals that I&#39;m personally excited about (enabli=
ng covenants, eltoo, Simplicity, CISA etc) that long term we might get with=
 a sensible approach to only activating soft forks that have community cons=
ensus. But the more uncertainty, confusion and disruption we create over co=
ntentious soft forks the more dangerous any soft fork of any form will appe=
ar. The primary focus will need to be resisting soft forks that don&#39;t h=
ave community consensus and ensuring Bitcoin doesn&#39;t splinter into a la=
rge number of different assets/blockchains with different combinations of s=
oft forks active.</div><div style=3D"font-family:arial;font-size:14px"><br>=
</div><div style=3D"font-family:arial;font-size:14px">So if you oppose this=
 soft fork activation attempt please voice your opposition, run full node s=
oftware that doesn&#39;t include CTV and CTV activation code such as Bitcoi=
n Core and if/when necessary and available run full node software that proa=
ctively rejects application of the CTV rules.</div><div style=3D"font-famil=
y:arial;font-size:14px"><br></div>
<div style=3D"font-family:arial;font-size:14px">
    <div>
        <div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospac=
e,monospace"><span style=3D"font-size:14px">--<br>Michael Folkson<br>Email:=
 michaelfolkson at </span></span></span><a href=3D"http://protonmail.com/" =
style=3D"line-height:normal;text-decoration:underline;font-family:SFMono-Re=
gular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospace,monospace;font-s=
ize:14px;font-style:normal;font-weight:400;letter-spacing:normal;text-inden=
t:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px" rel=3D"noo=
pener noreferrer" target=3D"_blank">protonmail.com</a><span style=3D"color:=
rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;text-=
indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;backgr=
ound-color:rgb(255,255,255);float:none;display:inline"><span style=3D"font-=
family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospace,=
monospace"><span style=3D"font-size:14px"> </span></span></span><br></div><=
div style=3D"font-family:arial;font-size:14px"><span style=3D"color:rgb(38,=
42,51);font-style:normal;font-weight:400;letter-spacing:normal;text-indent:=
0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;background-co=
lor:rgb(255,255,255);float:none;display:inline"><span style=3D"font-family:=
SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,monospace,monospa=
ce"><span style=3D"font-size:14px">Keybase: michaelfolkson<br>PGP: 43ED C99=
9 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</span></span></span><br></div>
    </div>

            <div>

            </div>
</div>
<div style=3D"font-family:arial;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Devs,</div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_d=
efault">In advance of the CTV meeting today, I wanted to share what my next=
 step is in advocating for CTV, as well as 7 theses for why I believe it to=
 be the right course of action to take at this time.</div><div style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Please see=
 the post at <a href=3D"https://rubin.io/bitcoin/2022/04/17/next-steps-bip1=
19/" rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://rubin.i=
o/bitcoin/2022/04/17/next-steps-bip119/</a>.<br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">As always, ope=
n to hear any and all feedback,</div><div><br></div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm=
ail_default">Jeremy</div><div><div dir=3D"ltr"><div dir=3D"ltr"><br></div><=
div dir=3D"ltr"><br></div><div dir=3D"ltr"><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defau=
lt">archived at: <a href=3D"https://web.archive.org/web/20220419172825/http=
s://rubin.io/bitcoin/2022/04/17/next-steps-bip119/" rel=3D"noreferrer nofol=
low noopener" target=3D"_blank">https://web.archive.org/web/20220419172825/=
https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/</a></div><br></div><=
/div></div></div>

        </blockquote><br>
    </div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d3bb0d05dd2230c0--