path: root/ed/fb5dbded13662d44be2e87879f8cff6a893e5f

Return-Path: <jtimon@jtimon.cc>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 22E06C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 11:11:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 0A04F410E4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 11:11:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.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 u9b7Drxgt6yD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 11:11:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com
 [IPv6:2607:f8b0:4864:20::1134])
 by smtp4.osuosl.org (Postfix) with ESMTPS id ABE2F410DE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 11:11:54 +0000 (UTC)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-2f7b815ac06so47544007b3.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 Apr 2022 04:11:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=AtugZfflFx/ajuhqnjqehs1YUwvT7mAIxxnIefXKi3U=;
 b=aRt4MTP6AhjtU9CTDlIV/h3wosnhCHMxcclHCmyg7b4cTTwAAfgsyggwQfOqaGsx2W
 nJIue1uQaIaWdbmwMABhNDyMV4oBP+zRu8iF/YpWTvUo8bpKxleeni49R2woCbX0m4dU
 BpT47On8MJCEBOo4VE9glXKQXIlNUAU8DBTubVgsA0OxGwNhF3BT6SkFCs3DV/Aq9GPo
 t2p1sQBLh141jz1Lgf5kKx3XFnzAeDXqHtGHgQQCZU0S4ottH1HtTIQVzCJbU6KR6hJl
 +gzuaE+AF76NO7uAJtSEdovCv8XGyY40xVfTP9VwSivTjBgLiSAJCYqzQBaE8BIXqQNA
 LOMg==
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=AtugZfflFx/ajuhqnjqehs1YUwvT7mAIxxnIefXKi3U=;
 b=P2ZUPMQICoDV4/vs0juzxI8YJlvIkpMK0+VkXgGbrlsHUUnYqKMST8LprSpSFDP6w4
 WqjxE9EW6jktiYvZi9X3Fu25han77gKWuwEe0CG1z60+Gp+wjs3kAuBq20zcNWLp34C+
 2+fqa43e8qfGEwIkd9DwPcK++1pZO3KAw1UWUm3YrUBtvzdUCTcoDxuq6El9a4IgixL+
 zCop0+5slrwLAtY7qOIFTTCBAEZODTaPNF+lkwXnoRbKmXy22tZ1VXMvYFZAvxAEaF5w
 QfU89NxEJJ/i+yZ99Nt+ws6zcfMJJezYCrdQgQo4P/vE1RPkB1ZRgvxDaKxpQdXtbQ5J
 /f3Q==
X-Gm-Message-State: AOAM531Kc+YUDwcIGfVmsIer0OAZCYy43wFo33+cy/r386q12fg2QJhs
 F2mwbIR6W6RoymtMHIioJfsnWzOMdUjbaGwBM3PD2UlFSMNkjA==
X-Google-Smtp-Source: ABdhPJzauVpDppB7CldDT1Uyl32gnozg/d+Cpk2GuqffbBnG38d5gyvIEc2WLhkkSKa07FXObJJDhGBCGlog8EpUC9Y=
X-Received: by 2002:a0d:df46:0:b0:2f7:bba8:9cc1 with SMTP id
 i67-20020a0ddf46000000b002f7bba89cc1mr8003907ywe.441.1650798713531; Sun, 24
 Apr 2022 04:11:53 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
 <CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
 <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>
In-Reply-To: <20220411130522.GA3633@erisian.com.au>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sun, 24 Apr 2022 12:13:08 +0100
Message-ID: <CABm2gDqw7ZSLwuFvWstLpkRAFT_4DLWkhNFBLW8m_E46_VWG3A@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000ea856705dd6486d3"
X-Mailman-Approved-At: Sun, 24 Apr 2022 18:57:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy Trial
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: Sun, 24 Apr 2022 11:11:57 -0000

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

You're not even considering user resistance in your cases. You're purely
relying on miners and calling speedy trial superior. I don't know if you're
being obtuse on purpose, I'm explaining myself very badly...

I DON'T WANT TO RELY ON MINERS TO RESIST CHANGES I DON'T WANT TO.
Sorry for the tone, but, please, make sure you understand that before
answering further, or otherwise it is a waste of time.

Note that it doesn't have to be in bitcoin core, speedy trial could be used
for attempting to activate a controversial softfork (it doesn't need to be
an evil fork, even) outside of core. Like what jeremy is trying to do with
his proposal, for example.
Now, go ahead and tell me that if miners reject it, then doesn't matter,
because nobody ever has told me that before, I need to hear it one more
time.
And I'll tell you I don't care about what miners will do, because you
obviously need to hear it one more time as well.
Or just tell the list that you resolved all my concerns, like jeremy does
about any criticism of his proposals, "well, it has consensus because only
people seeking dissent don't like it". Likd with speedy trial.
"Some people conplained, but we told them theur concerns were addressed and
even though they disagreed and claimed we didn't understand their
concerns...it looked like they were seeking dissent, so we told them to f@$=
k
off and now there's consensus".

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. You're not ignoring
my points on purpose, are you?
Nah, of course not, it's just that communication is hard.
Surely it wouldn't be fair if I accused you of being dishonest or
pretending to be dumb.
Most probably, I'm not clear or direct enough.
Whatever the real explanation is for you not understanding me, you're not
understanding me and it feels luke a waste of time for both of us.
So, I'm sorry, it's over.


On Mon, Apr 11, 2022, 14:05 Anthony Towns <aj@erisian.com.au> wrote:

> On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Tim=C3=B3n via bitcoin-de=
v
> wrote:
> > On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns <aj@erisian.com.au> wrote=
:
> > > > Let's discuss those too. Feel free to point out how bip8 fails at
> some
> > > > hypothetical cases speedy trial doesn't.
> > > Any case where a flawed proposal makes it through getting activation
> > > parameters set and released, but doesn't achieve supermajority
> hashpower
> > > support is made worse by bip8/lot=3Dtrue in comparison to speedy tria=
l
> > I disagree. Also, again, not the hypothetical case I want to discuss.
>
> You just said "Let's discuss those" and "Feel free to point out how bip8
> fails at some hypothetical cases speedy trial doesn't", now you're
> saying it's not what you want to discuss?
>
> But the above does include your "evil soft fork" hypothetical (I mean,
> unless you think being evil isn't a flaw?). The evil soft fork gets
> proposed, and due to some failure in review, merged with activation
> parameters set (via either speedy trial or bip8), then:
>
>  a) supermajority hashpower support is achieved quickly:
>      - both speedy trial and bip8+lot=3Dtrue activate the evil fork
>
>  b) supermajority hashpower support is achieved slowly:
>      - speedy trial does *not* activate the evil fork, as it times out
>        quickly
>      - bip8 *does* activate the fork
>
>  c) supermajority hashpower support support is never achieved:
>      - speedy trial does *not* activate the evil fork
>      - bip8+lot=3Dfalse does *not* activate the evil fork, but only after=
 a
>        long timeout
>      - bip8+lot=3Dtrue *does* activate the evil fork
>
> In case (a), they both do the same thing; in case (b) speedy trial is
> superior to bip8 no matter whether lot=3Dtrue/false since it blocks the
> evil fork, and in case (c) speedy trial is better than lot=3Dfalse becaus=
e
> it's quicker, and much better than lot=3Dtrue because lot=3Dtrue activate=
s
> the evil fork.
>
> > > > >  0') someone has come up with a good idea (yay!)
> > > > >  1') most of bitcoin is enthusiastically behind the idea
> > > > >  2') an enemy of bitcoin is essentially alone in trying to stop i=
t
> > > > >  3') almost everyone remains enthusiastic, despite that guy's
> > > incoherent
> > > > >      raving
> > > > >  4') nevertheless, the enemies of bitcoin should have the power t=
o
> stop
> > > > >      the good idea
> > > > "That guy's incoherent raving"
> > > > "I'm just disagreeing".
> > >
> > > Uh, you realise the above is an alternative hypothetical, and not
> talking
> > > about you? I would have thought "that guy" being "an enemy of bitcoin=
"
> > > made that obvious... I think you're mistaken; I don't think your emai=
ls
> > > are incoherent ravings.
> > Do you realize IT IS NOT the hypothetical case I wanted to discuss.
>
> Yes, that's what "alternative" means: a different one.
>
> > I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
> > don't seem interested in listening to me and understanding me at all, b=
ut
> > only in "addressing my concerns". Obviously we understand different
> things
> > by "addressing concerns".
> > Perhaps it's the language barrier or something.
>
> My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> 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... But
> just saying "I disagree" and "I don't want to talk about that" isn't
> going to convince anyone.
>
> I really don't think the claim above should be surprising; bip8 is meant
> for activating good proposals, bad ones need to be stopped in review --
> as "pushd" has said in this thread: "Flawed proposal making it through
> activation is a failure of review process", and Luke's said similar thing=
s
> as well. The point of bip8 isn't to make it easier to reject bad forks,
> it's to make it easier to ensure *good* forks don't get rejected. But
> that's not your hypothetical, and you don't want to talk about all the
> ways to stop an evil fork prior to an activation attempt...
>
> Cheers,
> aj
>
>

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

<div dir=3D"auto">You&#39;re not even considering user resistance in your c=
ases. You&#39;re purely relying on miners and calling speedy trial superior=
. I don&#39;t know if you&#39;re being obtuse on purpose, I&#39;m explainin=
g myself very badly...<div dir=3D"auto"><br></div><div dir=3D"auto">I DON&#=
39;T WANT TO RELY ON MINERS TO RESIST CHANGES I DON&#39;T WANT TO.</div><di=
v dir=3D"auto">Sorry for the tone, but, please, make sure you understand th=
at before answering further, or otherwise it is a waste of time.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Note that it doesn&#39;t have to b=
e in bitcoin core, speedy trial could be used for attempting to activate a =
controversial softfork (it doesn&#39;t need to be an evil fork, even) outsi=
de of core. Like what jeremy is trying to do with his proposal, for example=
.</div><div dir=3D"auto">Now, go ahead and tell me that if miners reject it=
, then doesn&#39;t matter, because nobody ever has told me that before, I n=
eed to hear it one more time.</div><div dir=3D"auto">And I&#39;ll tell you =
I don&#39;t care about what miners will do, because you obviously need to h=
ear it one more time as well.</div><div dir=3D"auto">Or just tell the list =
that you resolved all my concerns, like jeremy does about any criticism of =
his proposals, &quot;well, it has consensus because only people seeking dis=
sent don&#39;t like it&quot;. Likd with speedy trial.</div><div dir=3D"auto=
">&quot;Some people conplained, but we told them theur concerns were addres=
sed and even though they disagreed and claimed we didn&#39;t understand the=
ir concerns...it looked like they were seeking dissent, so we told them to =
f@$k off and now there&#39;s consensus&quot;.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Sorry for the aggressive tone, but I when people igno=
re some of my points repeteadly, I start to wonder if they do it on purpose=
. You&#39;re not ignoring my points on purpose, are you?</div><div dir=3D"a=
uto">Nah, of course not, it&#39;s just that communication is hard.</div><di=
v dir=3D"auto">Surely it wouldn&#39;t be fair if I accused you of being dis=
honest or pretending to be dumb.</div><div dir=3D"auto">Most probably, I&#3=
9;m not clear or direct enough.</div><div dir=3D"auto">Whatever the real ex=
planation is for you not understanding me, you&#39;re not understanding me =
and it feels luke a waste of time for both of us.</div><div dir=3D"auto">So=
, I&#39;m sorry, it&#39;s over.</div><div dir=3D"auto"><br></div><br><div c=
lass=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On =
Mon, Apr 11, 2022, 14:05 Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com=
.au">aj@erisian.com.au</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Tim=C3=B3n via bitcoin-d=
ev wrote:<br>
&gt; On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns &lt;<a href=3D"mailto:aj=
@erisian.com.au" target=3D"_blank" rel=3D"noreferrer">aj@erisian.com.au</a>=
&gt; wrote:<br>
&gt; &gt; &gt; Let&#39;s discuss those too. Feel free to point out how bip8=
 fails at some<br>
&gt; &gt; &gt; hypothetical cases speedy trial doesn&#39;t.<br>
&gt; &gt; Any case where a flawed proposal makes it through getting activat=
ion<br>
&gt; &gt; parameters set and released, but doesn&#39;t achieve supermajorit=
y hashpower<br>
&gt; &gt; support is made worse by bip8/lot=3Dtrue in comparison to speedy =
trial<br>
&gt; I disagree. Also, again, not the hypothetical case I want to discuss.<=
br>
<br>
You just said &quot;Let&#39;s discuss those&quot; and &quot;Feel free to po=
int out how bip8<br>
fails at some hypothetical cases speedy trial doesn&#39;t&quot;, now you&#3=
9;re<br>
saying it&#39;s not what you want to discuss?<br>
<br>
But the above does include your &quot;evil soft fork&quot; hypothetical (I =
mean,<br>
unless you think being evil isn&#39;t a flaw?). The evil soft fork gets<br>
proposed, and due to some failure in review, merged with activation<br>
parameters set (via either speedy trial or bip8), then:<br>
<br>
=C2=A0a) supermajority hashpower support is achieved quickly:<br>
=C2=A0 =C2=A0 =C2=A0- both speedy trial and bip8+lot=3Dtrue activate the ev=
il fork<br>
<br>
=C2=A0b) supermajority hashpower support is achieved slowly:<br>
=C2=A0 =C2=A0 =C2=A0- speedy trial does *not* activate the evil fork, as it=
 times out<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0quickly<br>
=C2=A0 =C2=A0 =C2=A0- bip8 *does* activate the fork<br>
<br>
=C2=A0c) supermajority hashpower support support is never achieved:<br>
=C2=A0 =C2=A0 =C2=A0- speedy trial does *not* activate the evil fork<br>
=C2=A0 =C2=A0 =C2=A0- bip8+lot=3Dfalse does *not* activate the evil fork, b=
ut only after a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0long timeout<br>
=C2=A0 =C2=A0 =C2=A0- bip8+lot=3Dtrue *does* activate the evil fork<br>
<br>
In case (a), they both do the same thing; in case (b) speedy trial is<br>
superior to bip8 no matter whether lot=3Dtrue/false since it blocks the<br>
evil fork, and in case (c) speedy trial is better than lot=3Dfalse because<=
br>
it&#39;s quicker, and much better than lot=3Dtrue because lot=3Dtrue activa=
tes<br>
the evil fork.<br>
<br>
&gt; &gt; &gt; &gt;=C2=A0 0&#39;) someone has come up with a good idea (yay=
!)<br>
&gt; &gt; &gt; &gt;=C2=A0 1&#39;) most of bitcoin is enthusiastically behin=
d the idea<br>
&gt; &gt; &gt; &gt;=C2=A0 2&#39;) an enemy of bitcoin is essentially alone =
in trying to stop it<br>
&gt; &gt; &gt; &gt;=C2=A0 3&#39;) almost everyone remains enthusiastic, des=
pite that guy&#39;s<br>
&gt; &gt; incoherent<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 raving<br>
&gt; &gt; &gt; &gt;=C2=A0 4&#39;) nevertheless, the enemies of bitcoin shou=
ld have the power to stop<br>
&gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0 the good idea<br>
&gt; &gt; &gt; &quot;That guy&#39;s incoherent raving&quot;<br>
&gt; &gt; &gt; &quot;I&#39;m just disagreeing&quot;.<br>
&gt; &gt;<br>
&gt; &gt; Uh, you realise the above is an alternative hypothetical, and not=
 talking<br>
&gt; &gt; about you? I would have thought &quot;that guy&quot; being &quot;=
an enemy of bitcoin&quot;<br>
&gt; &gt; made that obvious... I think you&#39;re mistaken; I don&#39;t thi=
nk your emails<br>
&gt; &gt; are incoherent ravings.<br>
&gt; Do you realize IT IS NOT the hypothetical case I wanted to discuss. <b=
r>
<br>
Yes, that&#39;s what &quot;alternative&quot; means: a different one.<br>
<br>
&gt; I&#39;m sorry, but I&#39;m tired of trying to explain. and quite, hone=
stly, you<br>
&gt; don&#39;t seem interested in listening to me and understanding me at a=
ll, but<br>
&gt; only in &quot;addressing my concerns&quot;. Obviously we understand di=
fferent things<br>
&gt; by &quot;addressing concerns&quot;.<br>
&gt; Perhaps it&#39;s the language barrier or something.<br>
<br>
My claim is that for *any* bad (evil, flawed, whatever) softfork, then<br>
attempting activation via bip8 is *never* superior to speedy trial,<br>
and in some cases is worse.<br>
<br>
If I&#39;m missing something, you only need to work through a single exampl=
e<br>
to demonstrate I&#39;m wrong, which seems like it ought to be easy... But<b=
r>
just saying &quot;I disagree&quot; and &quot;I don&#39;t want to talk about=
 that&quot; isn&#39;t<br>
going to convince anyone.<br>
<br>
I really don&#39;t think the claim above should be surprising; bip8 is mean=
t<br>
for activating good proposals, bad ones need to be stopped in review --<br>
as &quot;pushd&quot; has said in this thread: &quot;Flawed proposal making =
it through<br>
activation is a failure of review process&quot;, and Luke&#39;s said simila=
r things<br>
as well. The point of bip8 isn&#39;t to make it easier to reject bad forks,=
<br>
it&#39;s to make it easier to ensure *good* forks don&#39;t get rejected. B=
ut<br>
that&#39;s not your hypothetical, and you don&#39;t want to talk about all =
the<br>
ways to stop an evil fork prior to an activation attempt...<br>
<br>
Cheers,<br>
aj<br>
<br>
</blockquote></div></div>

--000000000000ea856705dd6486d3--