path: root/d3/5f4fade3ad88465b1c995c3533c5416ff84432

Return-Path: <jtimon@jtimon.cc>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A8A11C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 11:27:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 8238940286
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 11:27:55 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Uz9HZouFKTrF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 11:27:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com
 [IPv6:2607:f8b0:4864:20::1135])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 4559A400C9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 11:27:54 +0000 (UTC)
Received: by mail-yw1-x1135.google.com with SMTP id
 00721157ae682-2dc0364d2ceso54003177b3.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Mar 2022 03:27:54 -0800 (PST)
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=uAzqJZHp8Jp6Ld0HI4EGetoa50PoJTeB0N+WMwNCiFg=;
 b=ibTmZT5Q3S9xk3g/ffp4h4Lc/liEo0ofO9GUZ6pbHJuk0kXEdJ9m0zLiP5d4n3ha8d
 J3fWk+ftv/EL3IjmQp00zqTPOCZoCYP4VXdkiJCbY0Z3MJrFV34mTMLgMufAU0ly7hg+
 x/gg108JwyeNJBKtKJWJ3eNIgiKMocrMQ7wW/dAxxF/xFkadH9SL81xK0BvtRhLkXS2c
 hIvm606Y3omRiCea+9j2t2R6AhwzPOOpy4F0t8yF6Luzt0UY7gAyytMXffWCoip8Ke2I
 vcXw8lDxu02pYIkX30nmUX3JbLm1XjxgamKuRD/7MW931CrHyePjb3IEy41N+jp4zDoj
 cdiw==
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=uAzqJZHp8Jp6Ld0HI4EGetoa50PoJTeB0N+WMwNCiFg=;
 b=nMGPgfoo4drumr1BzbfsNGaAaoCHOI/9MlxIFsigq0xRdcfpzv5q14YFBHhT45eeq5
 37pXOk9lDE6V7HXeZ7TtrKK9WsdrO/Qv2q5EkuEf0WcINMxlhDQO0lcsRk+6bfMct54L
 8XHTeBObSIkvyQdDwWA7MXTzlavUqU7OESmtx2JBgOGl0VObi785uZaLFAD4rwfm0vjj
 +VPBSR9qmZqIqL8koNbJahoQ1C6FKWsKLPj8jxDMaaBvaZXa+4g+gOA4rc0PJi2ZpLjX
 EYX8OoT4i+OP8zK+cgYHu/zkFqf2dDmIGXApVqV/NgXvGYxzQEzHCJe4Iwtn/QATHOOG
 WsfQ==
X-Gm-Message-State: AOAM531zy2Sj0JUF+7mm/cylqfIPY6+kOa1EdgS9ZPg8YJX7CrynI4hn
 NEWI6hOrXIMSuaoA9kUqqqwILnJtyoUd/r++39kM7g==
X-Google-Smtp-Source: ABdhPJwcpf0TBim6FSzKduhbAp4L31JjJlLToRQZHgyIrthkHZ1fLwsjWCqFfpCpFf/eDEww1Ccd4r2DpIA0OZ2rNcg=
X-Received: by 2002:a81:bc4b:0:b0:2d6:1bb7:dd62 with SMTP id
 b11-20020a81bc4b000000b002d61bb7dd62mr3477202ywl.366.1646911673111; Thu, 10
 Mar 2022 03:27:53 -0800 (PST)
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"
X-Mailman-Approved-At: Thu, 10 Mar 2022 13:04:30 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5
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, 10 Mar 2022 11:27:55 -0000

--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--