MIME-Version: 1.0
References: <20220315154549.GA7580@erisian.com.au>
 <CABm2gDpK8eRx3ATbxkF5ic1usUdT4vKiPJyjmPVc-HEOGkxm-g@mail.gmail.com>
 <20220322234951.GB11179@erisian.com.au>
 <CABm2gDoC5Y=o6Vu7urzBoioVmXBf+YBLg95w-kupx9nidRDBPg@mail.gmail.com>
 <20220326014546.GA12225@erisian.com.au>
 <CABm2gDpMxN0sBCpcbmvYsQbdsGp=JRjAyLhsd6BWyAxdCY95+A@mail.gmail.com>
 <20220330042106.GA13161@erisian.com.au>
 <CABm2gDrsZ9ZimFTkNrdj+wr7328h2N2GmRCawq8xYv3BqyHNow@mail.gmail.com>
 <20220411130522.GA3633@erisian.com.au>
 <CABm2gDqw7ZSLwuFvWstLpkRAFT_4DLWkhNFBLW8m_E46_VWG3A@mail.gmail.com>
 <20220424121429.GA7363@erisian.com.au>
 <CABm2gDo0=psMAKY6Pvfp8b-RvAJdUabiESJpff_yzgwmy7cigQ@mail.gmail.com>
In-Reply-To: <CABm2gDo0=psMAKY6Pvfp8b-RvAJdUabiESJpff_yzgwmy7cigQ@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Mon, 25 Apr 2022 10:11:45 -0600
Message-ID: <CALeFGL19G7eLdM7J9dQrumdVTgo1OyoK6UbzF3oJMkGG55qLzg@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d1ba7305dd7cd5fc"
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Speedy Trial
Precedence: list

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

Hi AJ,

> Under *any* other circumstance, when they're used to activate a bad soft
fork, speedy trial and bip8 are the same. If a resistance method works
against bip8, it works against speedy trial; if it fails against speedy
trial, it fails against bip8.

IIRC one essential difference between ST (which is a variant of BIP9) and
BIP8 is that since there is no mandatory signaling during the lockin
period, you can't do a counter soft fork as easily. This is one of the
points that Luke mentioned to me that made clear the benefits of the
mandatory signaling. A variant of ST that does require mandatory signaling
may actually be something that can improve the process and give users a
more effective means of forking away from SF changes that they reject.

Keagan

On Sun, Apr 24, 2022 at 12:58 PM Jorge Tim=C3=B3n via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns <aj@erisian.com.au> wrote:
>
>> On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Tim=C3=B3n wrote:
>> > You're not even considering user resistance in your cases.
>>
>> Of course I am. Again:
>>
>
> No, you're relying on miners to stop bad proposals.
>
>
>> > > My claim is that for *any* bad (evil, flawed, whatever) softfork, th=
en
>> > > attempting activation via bip8 is *never* superior to speedy trial,
>> > > and in some cases is worse.
>> > >
>> > > If I'm missing something, you only need to work through a single
>> example
>> > > to demonstrate I'm wrong, which seems like it ought to be easy... Bu=
t
>> > > just saying "I disagree" and "I don't want to talk about that" isn't
>> > > going to convince anyone.
>>
>> The "some cases" where bip8 with lot=3Dtrue is *worse* than speedy trial
>> is when miners correctly see that a bad fork is bad.
>>
>> Under *any* other circumstance, when they're used to activate a bad soft
>> fork, speedy trial and bip8 are the same. If a resistance method works
>> against bip8, it works against speedy trial; if it fails against speedy
>> trial, it fails against bip8.
>>
>
> You're wrong.
>
>
>> > Sorry for the aggressive tone, but I when people ignore some of my
>> points
>> > repeteadly, I start to wonder if they do it on purpose.
>>
>> Perhaps examine the beam in your own eye.
>>
>
> Yeah, whether you do that yourself or not: sorry, it's over.
>
>
>> Cheers,
>> aj
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Hi AJ,</div><div><br></div>&gt; Under *any* other cir=
cumstance, when they&#39;re used to activate a bad soft<br>fork, speedy tri=
al and bip8 are the same. If a resistance method works<br>against bip8, it =
works against speedy trial; if it fails against speedy<br>trial, it fails a=
gainst bip8.<div><br></div><div>IIRC one essential difference between ST (w=
hich is a variant of BIP9) and BIP8 is that since there is no mandatory sig=
naling during the lockin period, you can&#39;t do a counter soft fork as ea=
sily. This is one of the points that Luke mentioned to me that made clear t=
he benefits of the mandatory signaling. A variant of ST that does require m=
andatory signaling may actually be something that can improve the process a=
nd give users a more effective means of forking away from SF changes that t=
hey reject.</div><div><br></div><div>Keagan</div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 24, 2022 at 12=
:58 PM Jorge Tim=C3=B3n via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<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"><div dir=3D"=
ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns &lt=
;<a href=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj@erisian.com.au</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On=
 Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Tim=C3=B3n wrote:<br>
&gt; You&#39;re not even considering user resistance in your cases. <br>
<br>
Of course I am. Again:<br></blockquote><div><br></div><div>No, you&#39;re r=
elying on miners to stop bad proposals.<br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
&gt; &gt; My claim is that for *any* bad (evil, flawed, whatever) softfork,=
 then<br>
&gt; &gt; attempting activation via bip8 is *never* superior to speedy tria=
l,<br>
&gt; &gt; and in some cases is worse.<br>
&gt; &gt;<br>
&gt; &gt; If I&#39;m missing something, you only need to work through a sin=
gle example<br>
&gt; &gt; to demonstrate I&#39;m wrong, which seems like it ought to be eas=
y... But<br>
&gt; &gt; just saying &quot;I disagree&quot; and &quot;I don&#39;t want to =
talk about that&quot; isn&#39;t<br>
&gt; &gt; going to convince anyone.<br>
<br>
The &quot;some cases&quot; where bip8 with lot=3Dtrue is *worse* than speed=
y trial<br>
is when miners correctly see that a bad fork is bad.<br>
<br>
Under *any* other circumstance, when they&#39;re used to activate a bad sof=
t<br>
fork, speedy trial and bip8 are the same. If a resistance method works<br>
against bip8, it works against speedy trial; if it fails against speedy<br>
trial, it fails against bip8.<br></blockquote><div><br></div><div>You&#39;r=
e wrong.<br></div><div>=C2=A0</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">
&gt; Sorry for the aggressive tone, but I when people ignore some of my poi=
nts<br>
&gt; repeteadly, I start to wonder if they do it on purpose. <br>
<br>
Perhaps examine the beam in your own eye.<br></blockquote><div><br></div><d=
iv>Yeah, whether you do that yourself or not: sorry, it&#39;s over.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
aj<br>
</blockquote></div></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>

--000000000000d1ba7305dd7cd5fc--