diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2022-03-10 11:28:55 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-03-10 11:27:55 +0000 |
| commit | 80e869c26eebab8fbeefd0d85388b680ced6938d (patch) | |
| tree | 7229f0e34839d0e22087e0be4d97d75a35464357 | |
| parent | 4c37e67807d974d86ac3c387c46cf624e03d9fb0 (diff) | |
| download | pi-bitcoindev-80e869c26eebab8fbeefd0d85388b680ced6938d.tar.gz pi-bitcoindev-80e869c26eebab8fbeefd0d85388b680ced6938d.zip | |
Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5
| -rw-r--r-- | d3/5f4fade3ad88465b1c995c3533c5416ff84432 | 251 |
1 files changed, 251 insertions, 0 deletions
diff --git a/d3/5f4fade3ad88465b1c995c3533c5416ff84432 b/d3/5f4fade3ad88465b1c995c3533c5416ff84432 new file mode 100644 index 000000000..fe1634847 --- /dev/null +++ b/d3/5f4fade3ad88465b1c995c3533c5416ff84432 @@ -0,0 +1,251 @@ +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'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">"Don't trust, verify", 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 <<a href=3D"mailto:ZmnSCPx= +j@protonmail.com">ZmnSCPxj@protonmail.com</a>> 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> +> 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 "ST ?=3D" so that the IRC logs have it explicitl= +y listed as "Speedy Trial".<br> +<br> +<br> +> It seems that criticism isn'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> +> Perhaps it is just my subjective perception.<br> +> Sometimes it feels we're going from "don't trust, verify&= +quot; to "just trust jeremy rubin", 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 "specially jeremy"?<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> +> 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-- + |