MIME-Version: 1.0
References: <CAD5xwhgvW_ATpWuMv1fF6hhjTyp8imkxfAY1CcCvYk1AwgqfhA@mail.gmail.com>
 <CABm2gDqMcgcyYErNgMe9shXUxX5E85n+VqheDf1_E1mPq3ijLg@mail.gmail.com>
 <CCrU07T0pDYBkAwCnUK3QZ3SFCtH1jSlH9ec6fUz5QxiNh7HT8lEx_2i6uR0Xedb6fdU94RZ4UXag9_Kchf6uELNjwSAxvyY4XgZ64aL-xI=@protonmail.com>
In-Reply-To: <CCrU07T0pDYBkAwCnUK3QZ3SFCtH1jSlH9ec6fUz5QxiNh7HT8lEx_2i6uR0Xedb6fdU94RZ4UXag9_Kchf6uELNjwSAxvyY4XgZ64aL-xI=@protonmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Thu, 10 Mar 2022 11:28:55 +0000
Message-ID: <CABm2gDoo0AruuT4cBSEdXLVkzfgS9suSH-s8mRmzPOPG5BHyZA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000040a7b805d9db8119"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5
Precedence: list

--00000000000040a7b805d9db8119
Content-Type: text/plain; charset="UTF-8"

Thank you for explaining. I agree with luke then, I'm against speedy trial.
I explained why already, I think.
In summary: speedy trial kind of means is miners and not users who decide
the rules.
It gives users less opportunities to react and oppose a malevolent change
in case miners want to impose such change on them.


Why specially jeremy?

I personally distrust him more from experience, but that's subjective, and
kind of offtopic. Sorry, I should try to distrust all the other devs as
much as I distrust him in particular.
"Don't trust, verify", right?


On Wed, Mar 9, 2022, 14:42 ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Jorge,
>
> > What is ST? If it may be a reason to oppose CTV, why not talk about it
> more explicitly so that others can understand the criticisms?
>
> ST is Speedy Trial.
> Basically, a short softfork attempt with `lockinontimeout=false` is first
> done.
> If this fails, then developers stop and think and decide whether to offer
> a UASF `lockinontimeout=true` version or not.
>
> Jeremy showed a state diagram of Speedy Trial on the IRC, which was
> complicated enough that I ***joked*** that it would be better to not
> implement `OP_CTV` and just use One OPCODE To Rule Them All, a.k.a.
> `OP_RING`.
>
> If you had actually read the IRC logs you would have understood it, I even
> explicitly asked "ST ?=" so that the IRC logs have it explicitly listed as
> "Speedy Trial".
>
>
> > It seems that criticism isn't really that welcomed and is just explained
> away.
>
> It seems that you are trying to grasp at any criticism and thus fell
> victim to a joke.
>
> > Perhaps it is just my subjective perception.
> > Sometimes it feels we're going from "don't trust, verify" to "just trust
> jeremy rubin", i hope this is really just my subjective perception. Because
> I think it would be really bad that we started to blindly trust people like
> that, and specially jeremy.
>
> Why "specially jeremy"?
> Any particular information you think is relevant?
>
> The IRC logs were linked, you know, you could have seen what was discussed.
>
> In particular, on the other thread you mention:
>
> > We should talk more about activation mechanisms and how users should be
> able to actively resist them more.
>
> Speedy Trial means that users with mining hashpower can block the initial
> Speedy Trial, and the failure to lock in ***should*** cause the developers
> to stop-and-listen.
> If the developers fail to stop-and-listen, then a counter-UASF can be
> written which *rejects* blocks signalling *for* the upgrade, which will
> chainsplit from a pro-UASF `lockinontimeout=true`, but clients using the
> initial Speedy Trial code will follow which one has better hashpower.
>
> If we assume that hashpower follows price, then users who want for /
> against a particular softfork will be able to resist the Speedy Trial, and
> if developers release a UASF `lockinontimeout=true` later, will have the
> choice to reject running the UASF and even running a counter-UASF.
>
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"auto"><div>Thank you for explaining. I agree with luke then, I&=
#39;m against speedy trial. I explained why already, I think.</div><div dir=
=3D"auto">In summary: speedy trial kind of means is miners and not users wh=
o decide the rules.</div><div dir=3D"auto">It gives users less opportunitie=
s to react and oppose a malevolent change in case miners want to impose suc=
h change on them.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Why specially jeremy?</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">I personally distrust him more from experience, but tha=
t&#39;s subjective, and kind of offtopic. Sorry, I should try to distrust a=
ll the other devs as much as I distrust him in particular.</div><div dir=3D=
"auto">&quot;Don&#39;t trust, verify&quot;, right?</div><div dir=3D"auto"><=
br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Wed, Mar 9, 2022, 14:42 ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPx=
j@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">Good morning Jorge,<br>
<br>
&gt; What is ST? If it may be a reason to oppose CTV, why not talk about it=
 more explicitly so that others can understand the criticisms?<br>
<br>
ST is Speedy Trial.<br>
Basically, a short softfork attempt with `lockinontimeout=3Dfalse` is first=
 done.<br>
If this fails, then developers stop and think and decide whether to offer a=
 UASF `lockinontimeout=3Dtrue` version or not.<br>
<br>
Jeremy showed a state diagram of Speedy Trial on the IRC, which was complic=
ated enough that I ***joked*** that it would be better to not implement `OP=
_CTV` and just use One OPCODE To Rule Them All, a.k.a. `OP_RING`.<br>
<br>
If you had actually read the IRC logs you would have understood it, I even =
explicitly asked &quot;ST ?=3D&quot; so that the IRC logs have it explicitl=
y listed as &quot;Speedy Trial&quot;.<br>
<br>
<br>
&gt; It seems that criticism isn&#39;t really that welcomed and is just exp=
lained away.<br>
<br>
It seems that you are trying to grasp at any criticism and thus fell victim=
 to a joke.<br>
<br>
&gt; Perhaps it is just my subjective perception.<br>
&gt; Sometimes it feels we&#39;re going from &quot;don&#39;t trust, verify&=
quot; to &quot;just trust jeremy rubin&quot;, i hope this is really just my=
 subjective perception. Because I think it would be really bad that we star=
ted to blindly trust people like that, and specially jeremy.<br>
<br>
Why &quot;specially jeremy&quot;?<br>
Any particular information you think is relevant?<br>
<br>
The IRC logs were linked, you know, you could have seen what was discussed.=
<br>
<br>
In particular, on the other thread you mention:<br>
<br>
&gt; We should talk more about activation mechanisms and how users should b=
e able to actively resist them more.<br>
<br>
Speedy Trial means that users with mining hashpower can block the initial S=
peedy Trial, and the failure to lock in ***should*** cause the developers t=
o stop-and-listen.<br>
If the developers fail to stop-and-listen, then a counter-UASF can be writt=
en which *rejects* blocks signalling *for* the upgrade, which will chainspl=
it from a pro-UASF `lockinontimeout=3Dtrue`, but clients using the initial =
Speedy Trial code will follow which one has better hashpower.<br>
<br>
If we assume that hashpower follows price, then users who want for / agains=
t a particular softfork will be able to resist the Speedy Trial, and if dev=
elopers release a UASF `lockinontimeout=3Dtrue` later, will have the choice=
 to reject running the UASF and even running a counter-UASF.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div></div>

--00000000000040a7b805d9db8119--