Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id C5DCFC000B for ; Fri, 11 Mar 2022 12:18:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B04A440632 for ; Fri, 11 Mar 2022 12:18:36 +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 C_HYhLs09Fan for ; Fri, 11 Mar 2022 12:18:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by smtp4.osuosl.org (Postfix) with ESMTPS id C343A4050F for ; Fri, 11 Mar 2022 12:18:33 +0000 (UTC) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-2dc242a79beso90742087b3.8 for ; Fri, 11 Mar 2022 04:18:33 -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; bh=1xwcQAWPSOiBFbwhQBxDBoOy5OsMA2w1fzoRQWL4Q5w=; b=gIpauXshofFImYh2SLUX3Wo+ruLFR8qF4bt9uldZ+cyKpaTlBlzkWn0iuPT2mTnDRs 99DSI0J+UxAf+y1JhV+1rlx++HyK6RgcFhxW9FcAKrEpCQq1mykgBwY+3gl/Yp9l1GJu jHMnNWp8foyD+b8Hldx9GKV8iHvQGlsetD9smGWnZRZMLSfl+5ZfPD00YTJAuctEx/i4 hyyX8D4ZO8mlFmx8s/YpmctERcMM61G6KeAauY8/XY+0FHqnsPTTFSv1mEuoocFJGq9G mcgaRjOJrsz7rYABo1kiBW5CdAmT0rDCsEYQoOVAe60dOd6lcoD0mZsSKcTrLo3vEfVJ pQNw== 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=1xwcQAWPSOiBFbwhQBxDBoOy5OsMA2w1fzoRQWL4Q5w=; b=wWbincGrcinspuHeqdRZmOJ7uRSk4XJe7zwup6+DAI5X2MbsWrOttIs7RC766W9L8b j82G7sPTu65b3tz9APhc4Mx/qknaxiZ602zROcEWWxgTGgpf4n+qfjMM7ZQMsseRkL9T kuBZPOrdGE+aWqJYAK/gYazsk0yKw3K2qfoObL0PzIZcWHEpMTztTiJna4gNR1JYMru7 Nul8KTinfiSVyANGQM6+vRIdI9T6MLPszubNMxxV2Z82ttoX8roD74w7Y6vjR+aev92X Ja2XvY/JoVz74R3+ebfV6HzeatGNjheYjGN4FJ3sE22kV0YpKHCNH90MI1Pj0f5SwJNF UDIA== X-Gm-Message-State: AOAM531pG7T3cZ+LJb9b9v3S2R2sMJ34S+NfezKshuZ5fAEUyLTAnhq5 HWs/X2PYXPl/QNwaHP1wnB/NIGDR4FjGddyBPzEDmQ== X-Google-Smtp-Source: ABdhPJyzKszpM7LoJCZgSaKY7A2r6MJj925lF/OeqaA37jKj38fpjRWjgRdPMn+MAlKXDd4wMP4iCf5PVJBVTduzHI4= X-Received: by 2002:a81:bc4b:0:b0:2d6:1bb7:dd62 with SMTP id b11-20020a81bc4b000000b002d61bb7dd62mr7927832ywl.366.1647001112683; Fri, 11 Mar 2022 04:18:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Fri, 11 Mar 2022 12:19:36 +0000 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000044372705d9f054f5" X-Mailman-Approved-At: Fri, 11 Mar 2022 12:22:37 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2022 12:18:36 -0000 --00000000000044372705d9f054f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 11, 2022, 00:12 Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Thu., Mar. 10, 2022, 08:04 Jorge Tim=C3=B3n via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> You're right, we shouldn't get personal. We shouldn't ignore feedback >> from me, mark friedenbach or luke just because of who it comes from. >> > > For goodness sake Jorge, enough with the persecution complex. > Thanks for answering. As the person who initially proposed the Speedy Trial deployment design, I > can say it was designed to take in account those concerns raised by luke-= jr > and the "no-miner-veto" faction. I also listened to the > "devs-do-not-decide" faction and the "no-divegent-consensus-rules" factio= n > and their concerns. > That's great, but it still doesn't take into account my concerns. I'm not part of any of those "factions". I guess I'm part of the "yes-user-veto" faction. I know, I know, we don't matter because the "no-divergent-rules" "faction" matters too much for us to be listened. The "no-miner-veto" concerns are, to an extent, addressed by the short > timeline of Speedy Trial. No more waiting 2 years on the miners dragging > their feet. If ST fails to active then we are back where we started with > at most a few weeks lost. And those weeks aren't really lost if they wou= ld > have been wasted away anyways trying to find broad consensus on another > deployment mechanism. > > I get that you don't like the design of Speedy Trial. You may even objec= t > that it fails to really address your concerns by leaving open how to foll= ow > up a failed Speedy Trial deployment. But regardless of how you feel, I > believe I did meaningfully address the those miner-veto concerns and othe= r > people agree with me. > > If you are so concerned about listening to legitimate criticism, maybe yo= u > can design a new deployment mechanism that addresses the concerns of the > "devs-do-not-decide" faction and the "no-divegent-consensus-rules" > faction. Or do you feel that their concerns are illegitimate? Maybe, by > sheer coincidence, all people you disagree with have illegitimate concern= s > while only your concerns are legitimate. > I talked about this. But the "no-divergent-rules" faction doesn't like it, so we can pretend we have listened to this "faction" and addressed all its concerns, I guess. Or perhaps it's just "prosectution complex", but, hey, what do I know about psychology? A major contender to the Speedy Trial design at the time was to mandate > eventual forced signalling, championed by luke-jr. It turns out that, at > the time of that proposal, a large amount of hash power simply did not ha= ve > the firmware required to support signalling. That activation proposal > never got broad consensus, and rightly so, because in retrospect we see > that the design might have risked knocking a significant fraction of mini= ng > power offline if it had been deployed. Imagine if the firmware couldn't = be > quickly updated or imagine if the problem had been hardware related. > Yes, I like this solution too, with a little caveat: an easy mechanism for users to actively oppose a proposal. Luke alao talked about this. If users oppose, they should use activation as a trigger to fork out of the network by invalidating the block that produces activation. The bad scenario here is that miners want to deploy something but users don't want to. "But that may lead to a fork". Yeah, I know. I hope imagining a scenario in which developers propose something that most miners accept but some users reject is not taboo. Some of these discussions started at the time of segwit activation. Yes, segwit, not taproot. As for mark, he wasn't talking about activation, but quantum computing concerns. Perhaps those have been "addressed"? I just don't know where. _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000044372705d9f054f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 11, 2022, 00:12 Russell O'Connor via b= itcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:

On Thu., Mar. 10, 2022, 08:04 Jorge= Tim=C3=B3n via bitcoin-dev, <bitcoin-de= v@lists.linuxfoundation.org> wrote:

<= div dir=3D"auto">
You're right, we shouldn&#= 39;t get personal. We shouldn't ignore feedback from me, mark friedenba= ch or luke just because of who it comes from.

For goodness sake Jorge, eno= ugh with the persecution complex.

Thanks for answering.

As the person who= initially proposed the Speedy Trial deployment design, I can say it was de= signed to take in account those concerns raised by luke-jr and the "no= -miner-veto" faction.=C2=A0 I also listened to the "devs-do-not-d= ecide" faction and the "no-divegent-consensus-rules" faction= and their concerns.
=
That's great, but it still doesn't take= into account my concerns. I'm not part of any of those "factions&= quot;. I guess I'm part of the "yes-user-veto" faction. I kno= w, I know, we don't matter because the "no-divergent-rules" &= quot;faction" matters too much for us to be listened.



<= div dir=3D"auto">
The "no-miner-veto" concerns a= re, to an extent, addressed by the short timeline of Speedy Trial.=C2=A0 No= more waiting 2 years on the miners dragging their feet.=C2=A0 If ST fails = to active then we are back where we started with at most a few weeks lost.= =C2=A0 And those weeks aren't really lost if they would have been waste= d away anyways trying to find broad consensus on another deployment mechani= sm.

I get that you don&#= 39;t like the design of Speedy Trial.=C2=A0 You may even object that it fai= ls to really address your concerns by leaving open how to follow up a faile= d Speedy Trial deployment.=C2=A0 But regardless of how you feel, I believe = I did meaningfully address the those miner-veto concerns and other people a= gree with me.

If you are= so concerned about listening to legitimate criticism, maybe you can design= a new deployment mechanism that addresses the concerns of the "devs-d= o-not-decide" faction and the "no-divegent-consensus-rules" = faction.=C2=A0 Or do you feel that their concerns are illegitimate?=C2=A0 M= aybe, by sheer coincidence, all people you disagree with have illegitimate = concerns while only your concerns are legitimate.
<= /div>

I talked about thi= s. But the "no-divergent-rules" faction doesn't like it, so w= e can pretend we have listened to this "faction" and addressed al= l its concerns, I guess.
Or perhaps it's just &q= uot;prosectution complex", but, hey, what do I know about psychology?= =C2=A0

A major contender to the Speedy Trial design at the time was to mandate e= ventual forced signalling, championed by luke-jr.=C2=A0 It turns out that, = at the time of that proposal, a large amount of hash power simply did not h= ave the firmware required to support signalling.=C2=A0 That activation prop= osal never got broad consensus, and rightly so, because in retrospect we se= e that the design might have risked knocking a significant fraction of mini= ng power offline if it had been deployed.=C2=A0 Imagine if the firmware cou= ldn't be quickly updated or imagine if the problem had been hardware re= lated.

Yes, I like this solution too, with a little caveat: an easy = mechanism for users to actively oppose a proposal.
L= uke alao talked about this.
If users oppose, they sh= ould use activation as a trigger to fork out of the network by invalidating= the block that produces activation.
The bad scenari= o here is that miners want to deploy something but users don't want to.=
"But that may lead to a fork". Yeah, I kn= ow.
I hope imagining a scenario in which developers = propose something that most miners accept but some users reject is not tabo= o.

Some of these discuss= ions started at the time of segwit activation. Yes, segwit, not taproot.

As for mark, he wasn't= talking about activation, but quantum computing concerns. Perhaps those ha= ve been "addressed"?
I just don't know= where.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--00000000000044372705d9f054f5--