MIME-Version: 1.0
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
 <202203110028.09249.luke@dashjr.org>
In-Reply-To: <202203110028.09249.luke@dashjr.org>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 10 Mar 2022 23:41:58 -0600
Message-ID: <CAGpPWDaQrFPUGUqqDUQ4RhxT2G5nVP6wqqPOp60Yh5qocOfZ2A@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f157e505d9eacac4"
Subject: Re: [bitcoin-dev] Speedy Trial
Precedence: list

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

>  BIP 8 did in fact have broad consensus

I hear you claim this often Luke, but claiming its so does not make it so.
Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some evidence
<https://www.youtube.com/watch?v=U7rXOgL4oFQ> and present it.

On Thu, Mar 10, 2022 at 6:38 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:
> > The "no-miner-veto" concerns are, to an extent, addressed by the short
> > timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
> > their feet.
>
> It's still a miner veto. The only way this works is if the full deployment
> (with UASF fallback) is released in parallel.
>
> > If you are so concerned about listening to legitimate criticism, maybe
> you
> > can design a new deployment mechanism that addresses the concerns of the
> > "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> > faction.
>
> BIP8 already does that.
>
> > A major contender to the Speedy Trial design at the time was to mandate
> > eventual forced signalling, championed by luke-jr.  It turns out that, at
> > the time of that proposal, a large amount of hash power simply did not
> have
> > the firmware required to support signalling.  That activation proposal
> > never got broad consensus,
>
> BIP 8 did in fact have broad consensus before some devs decided to ignore
> the
> community and do their own thing. Why are you trying to rewrite history?
>
> > and rightly so, because in retrospect we see
> > that the design might have risked knocking a significant fraction of
> mining
> > power offline if it had been deployed.  Imagine if the firmware couldn't
> be
> > quickly updated or imagine if the problem had been hardware related.
>
> They had 18 months to fix their broken firmware. That's plenty of time.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt;=C2=A0

BIP 8 did in fact have broad consensus<div><br></div><div>I hear you claim =
this often Luke, but claiming its so does not make it so. Do you think BIP8=
 still has broad consensus? If that&#39;s the case, maybe all that&#39;s ne=
eded is to gather some <a href=3D"https://www.youtube.com/watch?v=3DU7rXOgL=
4oFQ" target=3D"_blank">evidence</a> and present it.=C2=A0</div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar=
 10, 2022 at 6:38 PM Luke Dashjr via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">On Friday 11 March 2022 00:12:19 Russell O&#39;Connor via bi=
tcoin-dev wrote:<br>
&gt; The &quot;no-miner-veto&quot; concerns are, to an extent, addressed by=
 the short<br>
&gt; timeline of Speedy Trial.=C2=A0 No more waiting 2 years on the miners =
dragging<br>
&gt; their feet.<br>
<br>
It&#39;s still a miner veto. The only way this works is if the full deploym=
ent <br>
(with UASF fallback) is released in parallel.<br>
<br>
&gt; If you are so concerned about listening to legitimate criticism, maybe=
 you<br>
&gt; can design a new deployment mechanism that addresses the concerns of t=
he<br>
&gt; &quot;devs-do-not-decide&quot; faction and the &quot;no-divegent-conse=
nsus-rules&quot;<br>
&gt; faction.<br>
<br>
BIP8 already does that.<br>
<br>
&gt; A major contender to the Speedy Trial design at the time was to mandat=
e<br>
&gt; eventual forced signalling, championed by luke-jr.=C2=A0 It turns out =
that, at<br>
&gt; the time of that proposal, a large amount of hash power simply did not=
 have<br>
&gt; the firmware required to support signalling.=C2=A0 That activation pro=
posal<br>
&gt; never got broad consensus,<br>
<br>
BIP 8 did in fact have broad consensus before some devs decided to ignore t=
he <br>
community and do their own thing. Why are you trying to rewrite history?<br=
>
<br>
&gt; and rightly so, because in retrospect we see <br>
&gt; that the design might have risked knocking a significant fraction of m=
ining<br>
&gt; power offline if it had been deployed.=C2=A0 Imagine if the firmware c=
ouldn&#39;t be<br>
&gt; quickly updated or imagine if the problem had been hardware related.<b=
r>
<br>
They had 18 months to fix their broken firmware. That&#39;s plenty of time.=
<br>
<br>
Luke<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>

--000000000000f157e505d9eacac4--