Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7A75CC002D for ; Fri, 6 May 2022 22:44:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 62B3960B4D for ; Fri, 6 May 2022 22:44:38 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfZe4ip6NCoh for ; Fri, 6 May 2022 22:44:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by smtp3.osuosl.org (Postfix) with ESMTPS id 69DAA60687 for ; Fri, 6 May 2022 22:44:37 +0000 (UTC) Received: by mail-yb1-xb2e.google.com with SMTP id g28so15223016ybj.10 for ; Fri, 06 May 2022 15:44:37 -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; bh=Pbj1s5szWwNcgt1G+XaOCAFPwuBQajNSxNWSWrECBOQ=; b=ZFLlxcEzORwiRlEvwqCr5Kol/1ILyW+FTZaq6J0/SqagESoF1uDpBbkd1ZCJCY8Kkb T38dqHkSc2pIL3aBRLvHScjrlXjmFF7Y6gh+vhrftd808zK599wOCWyhBKix2ur7vslh IRDBPUocJGsj719qch8rrPzXs44h/0t/fjLNnj5m63ocZunPVrFqSei/4u3U5ZPWrW6b Vpt5I+HtyyZ3IPkndA5oIk117yT9rDqDUU+jnxGo+48D+Iyw4INHGgtIVVgbcKfwf9NX DTRGzFXw/8WNWJ72HYFkEpYwuB655LuTyB09/L6gSA89QhOnWukgQ79j8TV580/ffldp vrLg== 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; bh=Pbj1s5szWwNcgt1G+XaOCAFPwuBQajNSxNWSWrECBOQ=; b=OBJclIc/H9JtCTu6kNEN1B4C7KcTzfQdBiYwdFkF8cpESQT2KwgT/5tTGahVCL2Pf4 iQiRsutPYcvpKxYyxw5YBMt1amcbUcHGiM09DPhUOrJBzKRHsYTQYlQqcCU6pkaElfZD T8VK/cHSqIGK6S5rgukxMR0jRuw02cnPqFWWVp8WmeNjEFlCkJuAGmF507VYR49HONyy eK1n2f1tq52mrzVytR/2eMvsVpJJWcy4TqyeAIBXKWBR/6zaTHPvtd61seN0KVv3ucwc CK8sLmFbag4qCWVjvCo7pJKsiY12TiHXPfjBHaK6KaSnQmqyoW6IOQfzUUqUJxSlcBpw A4QQ== X-Gm-Message-State: AOAM531xwdJ/j8b7ldKiBmf6MhpcZ2GPKtV98v9a0mtvjTmujYh631C8 VHWM9FFs8bAcHc7woVDYcL991Hn6PsXQPuAEtr5xBQ== X-Google-Smtp-Source: ABdhPJwTZN3OeCz8TfT86D4bp9wDQKsKercF9NjE1/u+h54ft1tdFOHVL+uGA2Sae5rXBnavc65I+gnX1bHcC0VkbG0= X-Received: by 2002:a5b:dc8:0:b0:624:a898:dea6 with SMTP id t8-20020a5b0dc8000000b00624a898dea6mr4103877ybr.600.1651877076344; Fri, 06 May 2022 15:44:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Sat, 7 May 2022 00:44:24 +0200 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000059355a05de5f9a0e" X-Mailman-Approved-At: Fri, 06 May 2022 23:42:26 +0000 Subject: Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2022 22:44:38 -0000 --00000000000059355a05de5f9a0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, to be clear, you didn't design speedy trial "to make everyone unhappy" as Ryan claims, no? That's a really strange claim on his part. When the grace period for slower activation after lock in was added, I don't think it was added to make me or people like me who dislike that proposal unhappy. On the contrary, I think the goal was precisely to address some of our concerns. But it doesn't address them all, as I've tried to explain other times. I truly think you wanted to make everyone happy with speedy trial, but you didn't do it, sorry. I know it' not a lack of capacity because you did impressive and genius things like simplicity. But despite your best intentions and your great capacity, I still think speedy trial is a very bad proposal because you got the analysis wrong. Let me reiterate that this is not attack against you, but only against one of your ideas. Sorry if I sounded sarcastic, but I was trying to be sarcastic with ryan, not with you. On Fri, May 6, 2022 at 8:24 PM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, May 6, 2022 at 2:01 PM Jorge Tim=C3=B3n via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> Russell O'Connor wrote the definitive explanation for how ST arose in >>> the consensus process and how it was designed to make everyone >>> unhappy. It's a great explanation of what we went through last year. >>> >>> https://r6.ca/blog/20210615T191422Z.html >>> >>> "On Building Consensus and Speedy Trial" >>> >>> on | 2021-06-15T19:14:22Z >>> by | Russell O'Connor >>> >> >> That's a lot of text, are you sure he said in there he designed speedy >> trial to make everyone unhappy? >> Well, if we're still talking about it, that proves that it failed at its >> own design criterion of failing fast. >> > > Quoting from https://r6.ca/blog/20210615T191422Z.html: > > > Speedy Trial=E2=80=99s design is not based on any sort of activation ph= ilosophy > about failing fast. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000059355a05de5f9a0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, to be clear, you didn't design speedy trial &= quot;to make everyone unhappy" as Ryan claims, no?
That'= s a really strange claim on his part.
When the grace period for s= lower activation after lock in was added, I don't think it was added to= make me or people like me who dislike that proposal unhappy. On the contra= ry, I think the goal was precisely to address some of our concerns.
But it doesn't address them all, as I've tried to explain other = times.
I truly think you wanted to make everyone happy with = speedy trial, but you didn't do it, sorry.
I know it' not= a lack of capacity because you did impressive and genius things like simpl= icity.
But despite your best intentions and your great capaci= ty, I still think speedy trial is a very bad proposal because you got the a= nalysis wrong.
Let me reiterate that this is not attack again= st you, but only against one of your ideas.
Sorry if I sounded sa= rcastic, but I was trying to be sarcastic with ryan, not with you.


On Fri, May 6, 2022 at 8:24 PM Russell O'Connor via bi= tcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
On Fri, May 6, 2022 at 2:01 PM Jorg= e Tim=C3=B3n via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:

Russell O'Connor wrote the definitive explanation for how ST arose in the consensus process and how it was designed to make everyone
unhappy.=C2=A0 It's a great explanation of what we went through last ye= ar.

=C2=A0 https://r6.ca/blog/20210615T191422Z.html

=C2=A0 =C2=A0 "On Building Consensus and Speedy Trial"

=C2=A0 =C2=A0 on | 2021-06-15T19:14:22Z
=C2=A0 =C2=A0 by | Russell O'Connor

That's a lot of text, are you sure he said in there he designed speedy= trial to make everyone unhappy?
Well, if we're still talking= about it, that proves that it failed at its own design criterion of failin= g fast.


> Speedy = Trial=E2=80=99s design is not based on any sort of activation philosophy ab= out failing fast.=C2=A0
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000059355a05de5f9a0e--