path: root/5f/9bcdfc72dbe5719c5f0a6bb2857b3674041e28

Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B5CC6C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Mar 2022 13:35:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id A51A784163
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Mar 2022 13:35:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3OfOmcKXP2mi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Mar 2022 13:35:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com
 [IPv6:2607:f8b0:4864:20::f2f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3D4FE83E04
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Mar 2022 13:35:12 +0000 (UTC)
Received: by mail-qv1-xf2f.google.com with SMTP id b12so9185617qvk.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Mar 2022 05:35:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=Yyva06hKk3Fim5bojJ9ppTTVwA+qfbwL7g1yrf8TMEA=;
 b=FF92oFi6ibvRawXDDA2z+x5l1enfP+qtW6MYQWPQmNil5qqKqnPoUEcu84LNKTm+8f
 9LAAZlYynTunw3hf7qP8Y+av8OWGJ5/V9KctwtG7Gqgti+h5ypS2KbyQen/g4e98gaEx
 uPPuSRVx9+0CidnJg/R63kGm4FbRIG1piQSRRBDRsbwavnOnvhkQ7FVs89CO/A/rPBa3
 8vS0ehzSau2Pp+Dv96ziegX+CYdxHNVtjsMM7ktxoBjLcozEXint+jhfP0UYF4DhTk3r
 sHfbURaZ7kdg90bwwJ8p8bckjef7fLNq4Nckjd7h8CZulfyiPmo6YsozDMfC36ctt1Pq
 a5RQ==
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=Yyva06hKk3Fim5bojJ9ppTTVwA+qfbwL7g1yrf8TMEA=;
 b=f2lJAo+HLR0tOyvw3edroM0DHfG9AD5glMiFwDC7dL1hnLQqz+L07SiiKl/eg3eQQ3
 ziy883mGvMilS3aBBkd2BP2vfovue0IqY0UYRNx3tDEeFKXmXnVRLlCdQdwKl+XKTpuB
 VxN1EjZzkzF2k5f7S1RRsEPHD7iZ61UMuTs/UQFiolk0ttWn7u0S61GZXeFBhQXg0q0O
 cSq7tIN2jNbRanceTGbTzS6F3tzNbIcC0zFbcIEFkYf/O6oArjwYE52feNYXp0dZMFN5
 WYXl3s2A9+iEOz7BZBwhJVu3gBRdfGbObklpioAIJbc/f38ybS6+MF735nsxgY1vM8P0
 HzGQ==
X-Gm-Message-State: AOAM532NTbQL6MTD9Yg8hfxTTq4l9a6nAuUY22W5Sc0qZ5Za91vt1+6V
 tPpnNBdEqe2gFL3meW3CEtaFyxd6Wsw1nco03vTFc8SuQcYzA1AB
X-Google-Smtp-Source: ABdhPJz3GSNoApFJ8w2OXUn3JyV5QX0qGggYounHxFnRA1/yJXwSgZFRFBsvYPE8HdLCYlEJCgOOIzDbR0HFv1N+OEQ=
X-Received: by 2002:a05:6214:22c:b0:432:6b2b:95d0 with SMTP id
 j12-20020a056214022c00b004326b2b95d0mr11640572qvt.63.1647092110834; Sat, 12
 Mar 2022 05:35:10 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
 <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
 <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
 <CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
In-Reply-To: <CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sat, 12 Mar 2022 08:34:59 -0500
Message-ID: <CAMZUoKkPF6gPGpDWy1U+0GCONF-_qsTcOz0S1X+vx8_Kfqr8mw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002dd0df05da0584e0"
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: Sat, 12 Mar 2022 13:35:13 -0000

--0000000000002dd0df05da0584e0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 11, 2022 at 9:03 AM Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:

>
> 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, a=
t
>> the time of that proposal, a large amount of hash power simply did not h=
ave
>> 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 min=
ing
>> 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.
>>>
>>
>> This topic is not taboo.
>>
>> There are a couple of ways of opting out of taproot.  Firstly, users can
>> just not use taproot.  Secondly, users can choose to not enforce taproot
>> either by running an older version of Bitcoin Core or otherwise forking =
the
>> source code.  Thirdly, if some users insist on a chain where taproot is
>> "not activated", they can always softk-fork in their own rule that
>> disallows the version bits that complete the Speedy Trial activation
>> sequence, or alternatively soft-fork in a rule to make spending from (or
>> to) taproot addresses illegal.
>>
>
> Since it's about activation in general and not about taproot specifically=
,
> your third point is the one that applies.
> Users could have coordinated to have "activation x" never activated in
> their chains if they simply make a rule that activating a given proposal
> (with bip8) is forbidden in their chain.
> But coordination requires time.
>

A mechanism of soft-forking against activation exists.  What more do you
want? Are we supposed to write the code on behalf of this hypothetical
group of users who may or may not exist for them just so that they can have
a node that remains stalled on Speedy Trial lockin?  That simply isn't
reasonable, but if you think it is, I invite you to create such a fork.


> Please, try to imagine an example for an activation that you wouldn't lik=
e
> yourself. Imagine it gets proposed and you, as a user, want to resist it.
>

If I believe I'm in the economic majority then I'll just refuse to upgrade
my node, which was option 2. I don't know why you dismissed it.

Not much can prevent a miner cartel from enforcing rules that users don't
want other than hard forking a replacement POW.  There is no effective
difference between some developers releasing a malicious soft-fork of
Bitcoin and the miners releasing a malicious version themselves.  And when
the miner cartel forms, they aren't necessarily going to be polite enough
to give a transparent signal of their new rules.  However, without the
economic majority enforcing their set of rules, the cartel continuously
risks falling apart from the temptation of transaction fees of the censored
transactions.

On the other hand, If I find out I'm in the economic minority then I have
little choice but to either accept the existence of the new rules or sell
my Bitcoin.  Look, you cannot have the perfect system of money all by your
lonesome self.  Money doesn't have economic value if no one else wants to
trade you for it.  Just ask that poor user who YOLO'd his own taproot
activation in advance all by themselves.  I'm sure they think they've got
just the perfect money system, with taproot early and everything.  But now
their node is stuck at block 692261
<https://b10c.me/blog/007-spending-p2tr-pre-activation/> and hasn't made
progress since.  No doubt they are hunkered down for the long term,
absolutely committed to their fork and just waiting for the rest of the
world to come around to how much better their version of Bitcoin is than
the rest of us.

Even though you've dismissed it, one of the considerations of taproot was
that it is opt-in for users to use the functionality.  Future soft-forks
ought to have the same considerations to the extent possible.

--0000000000002dd0df05da0584e0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Fri, Mar 11, 2022 at 9:03 AM Jorge Tim=C3=B3n &lt;<a href=3D"mail=
to:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><b=
r><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"auto"><div dir=3D"auto">A major contender to the Speedy Tri=
al design at the time was to mandate eventual 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 have the firmware required to support =
signalling.=C2=A0 That activation proposal never got broad consensus, and r=
ightly so, because in retrospect we see that the design might have risked k=
nocking a significant fraction of mining power offline if it had been deplo=
yed.=C2=A0 Imagine if the firmware couldn&#39;t be quickly updated or imagi=
ne if the problem had been hardware related.</div></div></blockquote></div>=
<div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"auto"><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">Luke alao talked about this.</div><div dir=3D"auto">If users oppo=
se, they should use activation as a trigger to fork out of the network by i=
nvalidating the block that produces activation.</div><div dir=3D"auto">The =
bad scenario 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 know.</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 taboo.</div></div></blockquote><div><br></div><div>This topic is not=
 taboo.<br></div><div><br></div><div><div>There are a couple of ways of opt=
ing out of taproot.=C2=A0 Firstly, users can just=20
not use taproot.=C2=A0 Secondly, users can choose to not enforce taproot ei=
ther by running an older version of Bitcoin Core or otherwise forking the s=
ource code.=C2=A0 Thirdly, if some users insist on a chain where taproot is=
 &quot;not activated&quot;, they can always softk-fork in their own rule th=
at disallows
 the version bits that complete the Speedy Trial activation sequence, or al=
ternatively soft-fork in a rule to make spending from (or to) taproot addre=
sses illegal.</div></div></div></div></blockquote></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Since it&#39;s about activation in general and n=
ot about taproot specifically, your third point is the one that applies.</d=
iv><div dir=3D"auto">Users could have coordinated to have &quot;activation =
x&quot; never activated in their chains if they simply make a rule that act=
ivating a given proposal (with bip8) is forbidden in their chain.</div><div=
 dir=3D"auto">But coordination requires time.</div></div></blockquote><div>=
<br></div><div>A mechanism of soft-forking against activation exists.=C2=A0=
 What more do you want? Are we supposed to write the code on behalf of this=
 hypothetical group of users who may or may not exist for them just so that=
 they can have a node that remains stalled on Speedy Trial lockin?=C2=A0 Th=
at simply isn&#39;t reasonable, but if you think it is, I invite you to cre=
ate such a fork.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">Please, try to imagin=
e an example for an activation that you wouldn&#39;t like yourself. Imagine=
 it gets proposed and you, as a user, want to resist it.</div></div></block=
quote><div><br></div>If I believe I&#39;m in the economic majority then I&#=
39;ll just refuse to upgrade my node, which was option 2. I don&#39;t know =
why you dismissed it.</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">Not much can prevent a miner cartel from enforcing rules t=
hat users don&#39;t want other than hard forking a replacement POW.=C2=A0 T=
here is no effective difference between some developers releasing a malicio=
us soft-fork of Bitcoin and the miners releasing a malicious version themse=
lves.=C2=A0  And when the miner cartel forms, they aren&#39;t necessarily g=
oing to be polite enough to give a transparent signal of their new rules.=
=C2=A0 However, without the economic majority enforcing their set of rules,=
 the cartel continuously risks falling apart from the temptation of transac=
tion fees of the censored transactions.<br><div><br></div><div><div>On the =
other hand, If I find out I&#39;m in the economic minority then I have litt=
le choice but to either accept the existence of the new rules or sell my Bi=
tcoin.=C2=A0 Look, you cannot have the perfect system of money all by your =
lonesome self.=C2=A0 Money doesn&#39;t have economic value if no one else w=
ants to trade you for it.=C2=A0 Just ask that poor user who YOLO&#39;d his =
own taproot activation in advance all by themselves.=C2=A0 I&#39;m sure the=
y think they&#39;ve got just the perfect money system, with taproot early a=
nd everything.=C2=A0 But now their node is stuck at block <a href=3D"https:=
//b10c.me/blog/007-spending-p2tr-pre-activation/">692261</a> and hasn&#39;t=
 made progress since.=C2=A0 No doubt they are hunkered down for the long te=
rm, absolutely committed to their fork and just waiting for the rest of the=
 world to come around to how much better their version of Bitcoin is than t=
he rest of us.<br></div><div><br></div></div><div>Even though you&#39;ve di=
smissed it, one of the considerations of taproot was that it is opt-in for =
users to use the functionality.=C2=A0 Future soft-forks ought to have the s=
ame considerations to the extent possible.<br></div></div></div>

--0000000000002dd0df05da0584e0--