path: root/d8/b318b8710ad549713775c43ca833d4e732aa77

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 57399C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 15:23:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 37F654160B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 15:23:32 +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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2QmVipUklPX7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 15:23:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [IPv6:2a00:1450:4864:20::52c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 749D7408C9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 15:23:30 +0000 (UTC)
Received: by mail-ed1-x52c.google.com with SMTP id f21so30122576eds.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 07:23:30 -0800 (PST)
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=ybhhuYFiz7bypdruCr46IMCV3wAeS2mg1mejmXku+nk=;
 b=F3sWRFsbT+PfRwD8OiD27U57RZcIjMa9YhKeoSzKBC9cCqo71/FSR+5xaF3kVfYxQ7
 5sRqiMAYM1+/KQ56j5AU7bXO/oLFh0utYXqHc2ewzEEmzTssUDhnWt6V9RbBJmvyLsGN
 BNsoI4sajFwjT80VG3oTb4FbwYM199Vou/1aYaIV+TWyhY38Lsec/u8YjVz/H/purzDy
 wkddgYUbxpTabUgnDsXkoSH7G0Weefg2VUfWFLb3rydYsRjLkYx7E7sY4lcLo2xhKc6X
 0c0XQWP74kdaN4NgrZF1s7e7rzBwPWAwnHESG0DxYT5jRlSWU1YhsMwHqZDgmlwwn44q
 mofQ==
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=ybhhuYFiz7bypdruCr46IMCV3wAeS2mg1mejmXku+nk=;
 b=GQo9WCfuSzrMViIF45c7Q2ztdvbks60ZGsfmKrZgDrmLra5yvTMgw1esv7xVaucDnc
 OuuhOXtruwFoCp48Dd/56jw/9tr6kyLxdAShwVeCyXqPPNlcliv4CrL72nLLkO4VhnPm
 F/ZftUg8+4rFeKvKzVxnNjUhYNqBA/pI26lxmev46WfmOwHnN3ZhmzoS852ppf7zCcVc
 l8wvj8UFNHw9ykLYt0JC5vV55cnvPBTDWhW8o955/4SoR/Y3xawa7E5jPELI2Jeo5eYM
 LorFNdmHn5/eAZS1n+mM5Nz+GEuPxrfS2NNiVd1vk73EvtH53KFZwD7DJEyyE09u0S7w
 3Q8A==
X-Gm-Message-State: AOAM530HiRtEfyM/nKyN0OWvMRiMbYWqF2pQW0vz71/UP6wyie/rnHSZ
 uGd1fhQNZr/5RBMQNbMbvzfurFClsKcOZylhqN4k+WMHlIQ=
X-Google-Smtp-Source: ABdhPJxIc9lCTSD+Mb+hAS8Tx5ZEcrGKWtiHXQJDXa+1/yeLE+RxzD2LuLzoXbq82THuy0CxRF1tcHadUJbB3CLLKX4=
X-Received: by 2002:aa7:db41:: with SMTP id n1mr36525385edt.307.1642692208404; 
 Thu, 20 Jan 2022 07:23:28 -0800 (PST)
MIME-Version: 1.0
References: <202201182119.02687.luke@dashjr.org>
 <02cc01d80cb7$1339c050$39ad40f0$@voskuil.org>
 <202201182209.46044.luke@dashjr.org>
 <000601d80cbf$2f6a1d80$8e3e5880$@voskuil.org>
 <up51VtT2s-vcSvah3qiIm8G3KHjcnE5AwZLpTpe_CwRUgrWNJC8BvKFK0vHtYqzh1kTFtVVVLE0lXqBBBVhRR2Rkm3uFbp-Xmqs0KZ4gTUo=@protonmail.com>
In-Reply-To: <up51VtT2s-vcSvah3qiIm8G3KHjcnE5AwZLpTpe_CwRUgrWNJC8BvKFK0vHtYqzh1kTFtVVVLE0lXqBBBVhRR2Rkm3uFbp-Xmqs0KZ4gTUo=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 20 Jan 2022 09:23:09 -0600
Message-ID: <CAGpPWDZiNiBoq9KNh8TsZC8fQTNsP5iVZnX2NHwN9x7dSPZmFQ@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008eae9305d60515f0"
X-Mailman-Approved-At: Thu, 20 Jan 2022 15:27:28 +0000
Subject: Re: [bitcoin-dev] CTV BIP review
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, 20 Jan 2022 15:23:32 -0000

--0000000000008eae9305d60515f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm curious to hear clarification on most of Luke's non-activation related
comments.

> I would ideally like to see fully implemented BIPs for at least one of
these

While that would be interesting, I think that's a heavy burden to be placed
on this BIP. More in depth exploration would be helpful, but a fully
implemented BIP I think is more than necessary.

> Why is it a problem for them to use an Eltoo-like protocol?

I think he was saying it is a problem *unless* its an eltoo-like protocol.
Why I'm not sure. Maybe you can clarify Jeremy?

> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get
added.

Even were these opcodes to be implemented in bitcoin, a script writer could
choose to not use them, making it still possible to use CTV to create
covenant chains with a finite number of steps.

>  w.r.t. the language cleanups... the legal definition of covenant ... I
do think things like CLTV/CSV are covenants

Maybe it would be useful to specify that these are "child covenants" or
"inherited covenants" or something like that, since unlike things like
CLTV, CTV and similar proposed opcodes place restrictions on the child
output of the output containing the opcode call, which is the interesting
unique behavior. Tho I don't think we need to be bound to the legal or
dictionary definition in usage of the word covenant in the realm of bitcoin
- its gonna have its own definition in this context anyway.

Thank you Eric for pointing out the factual errors in LukeJr's mention and
implications around BIP8. The fact is that the ST pull request was
described as "BIP9-based" <https://github.com/bitcoin/bitcoin/pull/21377>.
TBH BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8
nor BIP9, so characterization one way or another is moot IMO. In any case,
I also agree with Michael that this isn't the place to have a long
discussion about activation method. That discussion should be kept
separate. I'd go so far to say that BIPs should not advocate for any
particular activation method, but should only go so far as to mention what
types of activation methods are possible (if some types aren't possible for
some reason). Separation of concerns would be very useful on that front
to reduce noise in conversations.

Thanks,
BT


On Wed, Jan 19, 2022 at 6:37 AM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Eric, Luke
>
> Can I request that you don't discuss activation methods for future soft
> forks on a thread for CTV BIP review? I (and a number of others [0]) do n=
ot
> support an upcoming activation attempt of standalone OP_CTV. If you want =
to
> discuss activation methods for soft forks generally it would be much bett=
er
> if you set up a separate thread. OP_CTV is not the only current soft fork
> proposal and there will likely be more.
>
> The activation discussion for Taproot was deliberately kept separate from
> the review of the Taproot BIPs and implementation. It only commenced once
> there was overwhelming community consensus for the soft fork to be
> activated (months after in fact). Though you are free to discuss whatever
> topics you wish (obviously) discussing soft fork activation methods on a
> OP_CTV thread might give the mistaken impression that OP_CTV is the next
> soft fork to be activated which is mere speculation at this point. In an
> ideal world the promoters of OP_CTV would follow the strong precedent set
> by the authors and contributors to the Taproot BIPs but regrettably that
> seems to have gone out the window at this point.
>
> Thanks
> Michael
>
> [0]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED 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 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev =
<
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > -----Original Message-----
> >
> > From: Luke Dashjr luke@dashjr.org
> >
> > Sent: Tuesday, January 18, 2022 2:10 PM
> >
> > To: eric@voskuil.org
> >
> > Cc: 'Bitcoin Protocol Discussion' bitcoin-dev@lists.linuxfoundation.org
> >
> > Subject: Re: [bitcoin-dev] CTV BIP review
> >
> > On Tuesday 18 January 2022 22:02:24 eric@voskuil.org wrote:
> >
> > > The only material distinction between BIP9 and BIP8 is that the latte=
r
> > >
> > > may activate without signaled support of hash power enforcement.
> > >
> > > As unenforced soft forks are not "backward compatible" they produce a
> > >
> > > chain split.
> >
> > Enforcement of the Bitcoin consensus protocol is by users, not miners.
>
> Given that I stated "hash power enforcement" it is quite clear that this =
is
>
> in fact only produced by mining. You are misrepresenting my statement to
>
> make an emotional appeal. Without "hash power enforcement", a soft fork i=
s
>
> NOT backward compatible.
>
> "[enforcement of] consensus protocol" is of course by merchants, but that
> is
>
> not the question at hand. The question is explicitly compatibility. Anyon=
e
>
> can activate a soft fork at any time, but without "hash power enforcement=
"
>
> soft forks are NOT backward compatible.
>
> > Softforks never produce a chain split. Miners can, and might try to do =
it
>
> to cause disruption in retaliation, but the softfork itself does not.
>
> Maybe you are trying to split hairs given the fact that blocks are produc=
ed
>
> only by miners, so only miners can "cause" a split.
>
> But through not intention ("disruption in retaliation") whatsoever by
>
> mining, a soft fork will result in those activating the rule being split
> off
>
> the original chain unless majority hash power enforces the rule. The fact
>
> that doing nothing apart from deploying the rule will result in a split i=
s
>
> the very definition of NOT compatible.
>
> I assume you will argue that the original chain is not "valid" and
> therefore
>
> irrelevant (as if no chain split occurred). But again the point is about
>
> compatibility. The appearance of multiple chains, which appear valid
>
> according to either the previous or new rules, is obviously the
>
> incompatibility.
>
> I shouldn't have to point this out, but observed chain splits have occurr=
ed
>
> in more the one large scale soft fork deployment. These splits have only
>
> been resolved through hash power enforcement. In 2010 it took 51 blocks
>
> before the current chain took the lead. In 2012 minority chains persisted
>
> for months. The deployment of soft forks caused these splits, NOT the
>
> actions of miners. And unless majority hash power eventually enforces it,
>
> the soft fork branch necessarily dies.
>
> > > It was for this reason alone that BIP8 never gained sufficient
> > >
> > > support.
> >
> > BIP 8 in fact achieved consensus for Taproot activation.
>
> Please define "achieved consensus", because by any definition I can
> imagine,
>
> this is simply untrue.
>
> > > This is one of the most misleading statements I've seen here. It's no=
t
> > >
> > > technically a lie, because it states what "should" happen. But it is
> > >
> > > clearly intended to lead people to believe that BIP8 was actually use=
d
> > >
> > > ("again") - it was not. ST was some technical tweaks to BIP9.
> >
> > BIP 8 was used to activate Taproot.
>
> No, it wasn't. I find it hard to imaging how you rationalize such grossly
>
> misleading statements.
>
> > > The outright deception around this one topic has led to significant
> > >
> > > unnecessary conflict in the community. Make your argument, but make i=
t
> > >
> > > honestly.
> >
> > You are the one attempting to deceive here.
>
> That is for others to decide. I appreciate your responses above, since th=
ey
>
> certainly help clarify what is happening here.
>
> e
>
> bitcoin-dev mailing list
>
> bitcoin-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>I&#39;m curious to hear clarification on most of Luke=
&#39;s non-activation related comments.=C2=A0</div><div><br></div><div>&gt;=
 I would ideally like to see fully implemented BIPs for at least one of the=
se</div><div><br></div><div>While=C2=A0that would be interesting, I think t=
hat&#39;s a heavy burden to be placed on this BIP. More in depth exploratio=
n would be helpful, but a fully implemented BIP I think is more than necess=
ary.</div><div><br></div><div>&gt; Why is it a problem for them to use an E=
ltoo-like protocol?</div><div><br></div><div>I think he was saying it is a =
problem *unless* its an eltoo-like protocol. Why I&#39;m not sure. Maybe yo=
u can clarify Jeremy?</div><div><br></div><div>&gt; It&#39;s not clear to m=
e that this holds if OP_CAT or OP_SHA256STREAM get added.</div><div><br></d=
iv><div>Even were these opcodes to be implemented in bitcoin, a script writ=
er could choose to not use them, making it still possible to use CTV to cre=
ate covenant chains with a finite number of steps.=C2=A0</div><div><br></di=
v>&gt;=C2=A0

<font color=3D"#000000" face=3D"arial, helvetica, sans-serif">w.r.t. the la=
nguage cleanups... the legal definition of covena</font>nt ... I do think t=
hings like CLTV/CSV are covenants=C2=A0<div><br></div><div>Maybe it would b=
e useful to specify that these are &quot;child covenants&quot; or &quot;inh=
erited covenants&quot; or something like that, since unlike things like CLT=
V, CTV and similar proposed opcodes place restrictions on the child output =
of the output containing the opcode call, which is the interesting unique b=
ehavior. Tho I don&#39;t think we need to be bound to the legal or dictiona=
ry definition in usage of the word covenant in the realm of bitcoin - its g=
onna have its own definition in this context anyway.=C2=A0</div><div><br></=
div><div>Thank you Eric for pointing out the factual errors in LukeJr&#39;s=
 mention and implications around BIP8. The fact is that the <a href=3D"http=
s://github.com/bitcoin/bitcoin/pull/21377">ST pull request was described as=
 &quot;BIP9-based&quot;</a>. TBH BIP8 is also BIP9 based, and ST is its own=
 thing that&#39;s neither BIP8 nor BIP9, so characterization one way or ano=
ther is moot IMO. In any case, I also agree with Michael that this isn&#39;=
t the place to have a long discussion about activation method. That discuss=
ion should be kept separate. I&#39;d go so far to say that BIPs should not =
advocate for any particular activation method, but should only go so far as=
 to mention what types of activation methods are possible (if some types ar=
en&#39;t possible for some reason). Separation of concerns would be very us=
eful on that front to=C2=A0reduce noise in conversations.</div><div><br></d=
iv><div>Thanks,</div><div>BT</div><div><br></div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 19, 2022 at 6:=
37 AM Michael Folkson via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Eric, Luke<br>
<br>
Can I request that you don&#39;t discuss activation methods for future soft=
 forks on a thread for CTV BIP review? I (and a number of others [0]) do no=
t support an upcoming activation attempt of standalone OP_CTV. If you want =
to discuss activation methods for soft forks generally it would be much bet=
ter if you set up a separate thread. OP_CTV is not the only current soft fo=
rk proposal and there will likely be more.<br>
<br>
The activation discussion for Taproot was deliberately kept separate from t=
he review of the Taproot BIPs and implementation. It only commenced once th=
ere was overwhelming community consensus for the soft fork to be activated =
(months after in fact). Though you are free to discuss whatever topics you =
wish (obviously) discussing soft fork activation methods on a OP_CTV thread=
 might give the mistaken impression that OP_CTV is the next soft fork to be=
 activated which is mere speculation at this point. In an ideal world the p=
romoters of OP_CTV would follow the strong precedent set by the authors and=
 contributors to the Taproot BIPs but regrettably that seems to have gone o=
ut the window at this point.<br>
<br>
Thanks<br>
Michael<br>
<br>
[0]: <a href=3D"https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af=
528d86a1b718" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/=
michaelfolkson/352a503f4f9fc5de89af528d86a1b718</a><br>
--<br>
Michael Folkson<br>
Email: michaelfolkson at <a href=3D"http://protonmail.com" rel=3D"noreferre=
r" target=3D"_blank">protonmail.com</a><br>
Keybase: michaelfolkson<br>
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br>
<br>
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<br>
<br>
On Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
&gt; -----Original Message-----<br>
&gt;<br>
&gt; From: Luke Dashjr <a href=3D"mailto:luke@dashjr.org" target=3D"_blank"=
>luke@dashjr.org</a><br>
&gt;<br>
&gt; Sent: Tuesday, January 18, 2022 2:10 PM<br>
&gt;<br>
&gt; To: <a href=3D"mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil=
.org</a><br>
&gt;<br>
&gt; Cc: &#39;Bitcoin Protocol Discussion&#39; <a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a><br>
&gt;<br>
&gt; Subject: Re: [bitcoin-dev] CTV BIP review<br>
&gt;<br>
&gt; On Tuesday 18 January 2022 22:02:24 <a href=3D"mailto:eric@voskuil.org=
" target=3D"_blank">eric@voskuil.org</a> wrote:<br>
&gt;<br>
&gt; &gt; The only material distinction between BIP9 and BIP8 is that the l=
atter<br>
&gt; &gt;<br>
&gt; &gt; may activate without signaled support of hash power enforcement.<=
br>
&gt; &gt;<br>
&gt; &gt; As unenforced soft forks are not &quot;backward compatible&quot; =
they produce a<br>
&gt; &gt;<br>
&gt; &gt; chain split.<br>
&gt;<br>
&gt; Enforcement of the Bitcoin consensus protocol is by users, not miners.=
<br>
<br>
Given that I stated &quot;hash power enforcement&quot; it is quite clear th=
at this is<br>
<br>
in fact only produced by mining. You are misrepresenting my statement to<br=
>
<br>
make an emotional appeal. Without &quot;hash power enforcement&quot;, a sof=
t fork is<br>
<br>
NOT backward compatible.<br>
<br>
&quot;[enforcement of] consensus protocol&quot; is of course by merchants, =
but that is<br>
<br>
not the question at hand. The question is explicitly compatibility. Anyone<=
br>
<br>
can activate a soft fork at any time, but without &quot;hash power enforcem=
ent&quot;<br>
<br>
soft forks are NOT backward compatible.<br>
<br>
&gt; Softforks never produce a chain split. Miners can, and might try to do=
 it<br>
<br>
to cause disruption in retaliation, but the softfork itself does not.<br>
<br>
Maybe you are trying to split hairs given the fact that blocks are produced=
<br>
<br>
only by miners, so only miners can &quot;cause&quot; a split.<br>
<br>
But through not intention (&quot;disruption in retaliation&quot;) whatsoeve=
r by<br>
<br>
mining, a soft fork will result in those activating the rule being split of=
f<br>
<br>
the original chain unless majority hash power enforces the rule. The fact<b=
r>
<br>
that doing nothing apart from deploying the rule will result in a split is<=
br>
<br>
the very definition of NOT compatible.<br>
<br>
I assume you will argue that the original chain is not &quot;valid&quot; an=
d therefore<br>
<br>
irrelevant (as if no chain split occurred). But again the point is about<br=
>
<br>
compatibility. The appearance of multiple chains, which appear valid<br>
<br>
according to either the previous or new rules, is obviously the<br>
<br>
incompatibility.<br>
<br>
I shouldn&#39;t have to point this out, but observed chain splits have occu=
rred<br>
<br>
in more the one large scale soft fork deployment. These splits have only<br=
>
<br>
been resolved through hash power enforcement. In 2010 it took 51 blocks<br>
<br>
before the current chain took the lead. In 2012 minority chains persisted<b=
r>
<br>
for months. The deployment of soft forks caused these splits, NOT the<br>
<br>
actions of miners. And unless majority hash power eventually enforces it,<b=
r>
<br>
the soft fork branch necessarily dies.<br>
<br>
&gt; &gt; It was for this reason alone that BIP8 never gained sufficient<br=
>
&gt; &gt;<br>
&gt; &gt; support.<br>
&gt;<br>
&gt; BIP 8 in fact achieved consensus for Taproot activation.<br>
<br>
Please define &quot;achieved consensus&quot;, because by any definition I c=
an imagine,<br>
<br>
this is simply untrue.<br>
<br>
&gt; &gt; This is one of the most misleading statements I&#39;ve seen here.=
 It&#39;s not<br>
&gt; &gt;<br>
&gt; &gt; technically a lie, because it states what &quot;should&quot; happ=
en. But it is<br>
&gt; &gt;<br>
&gt; &gt; clearly intended to lead people to believe that BIP8 was actually=
 used<br>
&gt; &gt;<br>
&gt; &gt; (&quot;again&quot;) - it was not. ST was some technical tweaks to=
 BIP9.<br>
&gt;<br>
&gt; BIP 8 was used to activate Taproot.<br>
<br>
No, it wasn&#39;t. I find it hard to imaging how you rationalize such gross=
ly<br>
<br>
misleading statements.<br>
<br>
&gt; &gt; The outright deception around this one topic has led to significa=
nt<br>
&gt; &gt;<br>
&gt; &gt; unnecessary conflict in the community. Make your argument, but ma=
ke it<br>
&gt; &gt;<br>
&gt; &gt; honestly.<br>
&gt;<br>
&gt; You are the one attempting to deceive here.<br>
<br>
That is for others to decide. I appreciate your responses above, since they=
<br>
<br>
certainly help clarify what is happening here.<br>
<br>
e<br>
<br>
bitcoin-dev mailing list<br>
<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<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>
_______________________________________________<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>

--0000000000008eae9305d60515f0--