path: root/e0/69e68c851f3eb4ef2da83ccc575c51719a306d

Return-Path: <jtimon@jtimon.cc>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C5DCFC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 12:18:33 +0000 (UTC)
Received: by mail-yw1-x112d.google.com with SMTP id
 00721157ae682-2dc242a79beso90742087b3.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
In-Reply-To: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Fri, 11 Mar 2022 12:19:36 +0000
Message-ID: <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Fri, Mar 11, 2022, 00:12 Russell O&#39;Connor via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"auto"><br><div class=3D"gmail_quote" dir=3D"auto=
"><div dir=3D"ltr" class=3D"gmail_attr">On Thu., Mar. 10, 2022, 08:04 Jorge=
 Tim=C3=B3n via bitcoin-dev, &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" rel=3D"noreferrer noreferrer noreferrer noreferrer noreferre=
r noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"auto"><div><div class=3D"gmail_quote"><br></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">You&#39;re right, we shouldn&#=
39;t get personal. We shouldn&#39;t ignore feedback from me, mark friedenba=
ch or luke just because of who it comes from.</div></div></blockquote></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">For goodness sake Jorge, eno=
ugh with the persecution complex.</div></div></blockquote></div></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Thanks for answering.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">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 &quot;no=
-miner-veto&quot; faction.=C2=A0 I also listened to the &quot;devs-do-not-d=
ecide&quot; faction and the &quot;no-divegent-consensus-rules&quot; faction=
 and their concerns.</div></div></blockquote></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">That&#39;s great, but it still doesn&#39;t take=
 into account my concerns. I&#39;m not part of any of those &quot;factions&=
quot;. I guess I&#39;m part of the &quot;yes-user-veto&quot; faction. I kno=
w, I know, we don&#39;t matter because the &quot;no-divergent-rules&quot; &=
quot;faction&quot; matters too much for us to be listened.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"auto"><div dir=3D"auto">The &quot;no-miner-veto&quot; 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&#39;t really lost if they would have been waste=
d away anyways trying to find broad consensus on another deployment mechani=
sm.</div><div dir=3D"auto"><br></div><div dir=3D"auto">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.</div><div dir=3D"auto"><br></div><div dir=3D"auto">If you are=
 so concerned about listening to legitimate criticism, maybe you can design=
 a new deployment mechanism that addresses the concerns of the &quot;devs-d=
o-not-decide&quot; faction and the &quot;no-divegent-consensus-rules&quot; =
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></div></blockquote><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I talked about thi=
s. But the &quot;no-divergent-rules&quot; faction doesn&#39;t like it, so w=
e can pretend we have listened to this &quot;faction&quot; and addressed al=
l its concerns, I guess.</div><div dir=3D"auto">Or perhaps it&#39;s just &q=
uot;prosectution complex&quot;, but, hey, what do I know about psychology?=
=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto=
">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&#39;t be quickly updated or imagine if the problem had been hardware re=
lated.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">Yes, I like this solution too, with a little caveat: an easy =
mechanism for users to actively oppose a proposal.</div><div dir=3D"auto">L=
uke alao talked about this.</div><div dir=3D"auto">If users oppose, they sh=
ould use activation as a trigger to fork out of the network by invalidating=
 the block that produces activation.</div><div dir=3D"auto">The bad scenari=
o here is that miners want to deploy something but users don&#39;t want to.=
</div><div dir=3D"auto">&quot;But that may lead to a fork&quot;. Yeah, I kn=
ow.</div><div dir=3D"auto">I hope imagining a scenario in which developers =
propose something that most miners accept but some users reject is not tabo=
o.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Some of these discuss=
ions started at the time of segwit activation. Yes, segwit, not taproot.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">As for mark, he wasn&#39;t=
 talking about activation, but quantum computing concerns. Perhaps those ha=
ve been &quot;addressed&quot;?</div><div dir=3D"auto">I just don&#39;t know=
 where.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div class=3D"g=
mail_quote" dir=3D"auto"></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--00000000000044372705d9f054f5--