path: root/0b/68590ea931a5c1272fff6d5908be209731c78b

Return-Path: <keagan.mcclelland@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 80C13C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 19:33:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 5D93460677
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 19:33:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
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 Ex72K7iDv_-4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 19:33:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com
 [209.85.221.53])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 3C89D6066E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 19:33:24 +0000 (UTC)
Received: by mail-wr1-f53.google.com with SMTP id u14so23774233wri.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 11:33:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=+UfYIFmDkdVayFa7mrM35RuRLHN69K0x8XGM1YXMzJk=;
 b=PyEy8avSTvr+QPcIDA/Lp26bx8MT1OcO4GZmv8oeOKcHRMRHcokqQezuUa7/Q1H90l
 4FKr9WsA8ueqhZ49uUEZQfKDQalUHkUjEeaHD5GwaPEoMs1ixDD6GVlKM7lpMxQw3YWI
 hpWdiMX7zG27CP6KEMn+FYWZyRU8bVHRLLhB2dsgt5xOxvn4eg+g9BKI3UaMD3JwolC4
 X6VeC4MSJMSmkHHdh/goF3j3nmfGUD+y0KsE7GIGHmODbmK+lpxHS5HczBc8CHrtOZLE
 4gimWMCNKK1DloCCp7xGJzDEE7B5Kjy3748DujXmwYyDCK0hN5RFVlYLeXaybj8kb83j
 L8oA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=+UfYIFmDkdVayFa7mrM35RuRLHN69K0x8XGM1YXMzJk=;
 b=eJK7Qsj2vSgxtpixkeSQv/Yq9sOUbagDLOPtHyKbFdjzVbmYiHjSLRzguFEV70fkCp
 gFxrTPazu76X9ptAEDO3mS7XqTzPC6EFa4Lmm6jPI2bKW59OgS91cK+FyGsn5r+l6Zdt
 JC98QiRHKvSuJ50jo0C4uThTksVBdw0YKVSaQ3/nIYxpT6nO1g6B4Ic6VwTJyqZMtzE1
 uLFaZYt5EqI3MDeh69cAAs+EC9Ym6vystZPWWYOFl3WWNxNFXTbVtyHW6QvUo6cbDwj6
 2MMETqx4q+YVvuBBXNj0K2LxsqNaAIAie8C8HEZS12Vr0kKwzyPg7+YmNexQDOtUI0hW
 XUVQ==
X-Gm-Message-State: AOAM532ZPuKPHG8UHBQmd1jFv3FBUMiXY6CybZX1OB7GIvNn/UvqeUGz
 5Twm/HtpuhWlFqpuN0KkwyvVdLddH3OpMGRq7X0=
X-Google-Smtp-Source: ABdhPJxH1kU41DGM8QWeM9AsaECCbbW1fQtAIAfwg4l1qamw3mhTBalJ8ZlU+pm2NM89QYt/AmquEA+oISU7OwQaDgA=
X-Received: by 2002:adf:81f7:: with SMTP id 110mr27829607wra.35.1614108802388; 
 Tue, 23 Feb 2021 11:33:22 -0800 (PST)
MIME-Version: 1.0
References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au>
 <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>
 <CABm2gDrbKdxMuKdwYh0HBXNUxhqWtq1x2oLC0Ni=dbfP8b_a7Q@mail.gmail.com>
 <CABm2gDp5dRTrPEqPfrjOeeYBn6RMS=HFMbtkJ+MM0SMVnSfK5A@mail.gmail.com>
 <CAD5xwhg0pWJykWUusdoNQd60L9_MgCzzky1dvViLERADMcoysQ@mail.gmail.com>
In-Reply-To: <CAD5xwhg0pWJykWUusdoNQd60L9_MgCzzky1dvViLERADMcoysQ@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Tue, 23 Feb 2021 12:33:11 -0700
Message-ID: <CALeFGL1UbXx14aX7RK7nh7b4jwvmfF6AXrvqPJpriSB4ZvYT2A@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cb978405bc05fdb9"
X-Mailman-Approved-At: Tue, 23 Feb 2021 20:09:16 +0000
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
 lockinontimeout (LOT)
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: Tue, 23 Feb 2021 19:33:26 -0000

--000000000000cb978405bc05fdb9
Content-Type: text/plain; charset="UTF-8"

I wanted to follow up on what Jeremy and others are saying regards finding
consensus on LOT. I've seen a few other opinions saying that finding
consensus on the LOT value is far more important than what the LOT value
actually is. This makes sense because if 100% of economic activity is
running the same rule set, there is no divergence, regardless of which
value is picked.

It is my understanding that those who oppose LOT=true are mostly opposed on
the grounds of it *appearing* "unnecessarily coercive" and that this lack
of consensus can precipitate a chain split at the "brinksmanship period" as
Jeremy refers to it. I don't think that we can say that LOT=true is
coercive at all unless there is some opposition to Taproot itself.
Opposition on the grounds that it *may* be opposed by others and Core does
not want to assert control over the protocol is a conservative view but
ultimately contingent upon opposition to Taproot for more fundamental
reasons. If no one opposes it, then by definition you have consensus, and
in that case I also don't think that the LOT=true (or false) in that regard
sets meaningful precedent, as I would expect precedents to only be
meaningful if they were established during a contentious scenario. As it
stands we have precedents for both MASF's and UASF's to execute soft forks
in Bitcoin.

Of course it seems intractable to ascertain the views of ~100% of the
Bitcoin constituency, and therefore it gives credibility to the argument
that by coming to consensus on LOT=false among those who *are* speaking up
is safer with the embedded assumptions that modifying consensus beyond what
core ships is an active choice, presumably by those who know what they are
doing. However, the simple act of Core choosing to ship an unconfigurable
LOT=false value does not *prevent* the forking and creation of a UASF
client. As Jeremy points out, the LOT=true possibility always exists here,
and we have multiple high profile people saying they will be running that
regardless of how things turn out. It seems to me that in this scenario,
LOT=false does less to prevent a chain split.

In regards to precedent, there may be good reasons to force that minority
to fork themselves off the network, as would be the case if a hypothetical
soft fork was a consensus action to blacklist some UTXO's or something else
that weaponizes consensus against some subset of Bitcoin's user base, but I
haven't heard a single person who advocates for LOT=false on the grounds
that they *themselves* oppose the consensus change that is being proposed
here. So if the goal is to prevent a chain split, and the soft fork is
benign and essentially "annexing unoccupied territory" with respect to
script versions, and no one actually has opposed Taproot itself, then I
fail to see how LOT=false is safer in the presence of a grenade defense by
the LOT=true crowd.

I personally *prefer* LOT=true for these reasons, but I am NOT going to be
joining the ranks of the intolerant minority if Core ultimately ships
LOT=false. I think it is more important to stay in consensus, and as a
result I am able to be convinced that false is the right answer. My
question to everyone else (true AND false advocates) is this: what would
you have to observe, in order to change your mind or is it immutably made
up? If we have a significant portion of the community that is immutably
made up to go false, and another portion that is going to go true, the
asymmetry of the fork almost *requires* that those of us whose opinions are
malleable to break for true.

If social consensus is what drives technical consensus and not the other
way around it seems as if there cannot exist a valid (rational?) reason to
oppose Taproot itself, and then by extension with the arguments laid out
above, LOT=true seems to be the logical conclusion of all of this, even if
Core ships LOT=false at the outset.

Where am I wrong here?

Keagan

On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not responding to anyone in particular, but it strikes me that one can
> think about the case where a small minority (let's say H = 20%?) of nodes
> select the opposite of what Core releases (LOT=false, LOT=true). I'm
> ignoring the case where a critical bug is discovered in Taproot for reasons
> I could expand on if anyone is interested (I don't think LOT=true/false has
> much of a diff in that regard).
>
> You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes
> are clearly updated (or lying), LOT=false nodes may be un-upgraded (or
> however you want to interpret it).
>
>
> *# 80% on LOT=false, 20% LOT=True*
>
> - Case 1: Activates ahead of time anyways
>
> No issues.
>
> - Case 2: Fails to Activate before timeout...
>
> 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of
> multi block reorgs at time of fork relatively high, especially if network
> does not partition.
>
> Implication is that activation % being 90%, then X% fewer than 70% of
> miners are signaling for Taproot at this time.  If X% is small the
> increased orphan rate caused by the LOT=true miners will cause it to
> activate anyways. If X% is larger, then there will be a consensus split.
>
>
>
> *# 80% on LOT=true, 20% LOT=False*
> - Case 1: Activates ahead of time Anyways
>
> No issues.
>
> - Case 2: Fails to Activate before timeout...
>
> A% + B% + C% = 20%
>
> A% (upgraded, signal activate) remain on majority chain with LOT=false,
> blocks mined universally valid.
>
> B% (upgraded, not signaling) succeeds in activating and maintaining
> consensus, blocks are temporarily lost during the final period, but
> consensus re-emerges.
>
> C% (not upgraded/not signalling) both fail to activate (not upgraded) and
> blocks are rejected (not signaling) during mandatory signalling.
> Essentially becomes an SPV miner, should still not select transactions
> improperly given mempool policy, but may mine a bad tip.
>
> (I argue that group B is irrational entirely, as in this case the majority
> has upgraded, inevitably winning, and is orphaning their blocks so B should
> effectively be 0% or can be combined with group C as being somehow not
> upgraded if they are unable to switch once it becomes clear after say the
> first 100 blocks in the period that LOT > 50%. The only difference in
> lumping B with C is that group C SPV mines after the fork and B should, in
> theory, have full validation.).
>
>
>
> Apologies if my base analysis is off -- happy to take corrections.
>
>
> My overall summary is thus:
>
> 1) People care what Core releases because we assume the majority will
> likely run it. If core were a minority project, we wouldn't really care
> what core released.
> 2) People are upset with LOT=true being suggested as release parameters
> because of the *narrative* that it puts devs in control.
> 3) LOT=true having a sizeable minority running it presents major issues to
> majority LOT=false in terms of lost blocks during the final period and in
> terms of a longer term fork.
> 4) Majority LOT=true has no long term instability on consensus (majority
> LOT=true means the final period always activates, any instability is short
> lived + irrational).
> 5) On the balance, the safer parameter to release *seems* to be LOT=true.
> But because devs are sensitive to control narrative, LOT=false is preferred
> by devs.
> 6) Almost paradoxically, choosing a *less safe* option for a narrative
> reason is more of a show of dev control than choosing a more safe option
> despite appearances.
> 7) This all comes down to if we think that a reasonable number of
> important nodes will run LOT=true.
> 8) This all doesn't matter *that much* because taproot will have many
> opportunities to activate before the brinksmanship period.
>
> As a plan of action, I think that means that either:
>
> A) Core should release LOT=true, as a less disruptive option given stated
> community intentions to do LOT=true
> B) Core  community should vehemently anti-advocate running LOT=true to
> ensure the % is as small as possible
> C) Do nothing
> D) Core community should release LOT=false and vehemently advocate
> manually changing to LOT=true to ensure the % is supermajority, but leaving
> it as a user choice.
>
>
> Overall, I worry that plan B has a mild Streissand effect and would result
> in boosting LOT=true (which could be OK, so long as LOT=true +
> LOT=false+signal yes becomes the large majority, but would be not fun for
> anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C
> most likely ends up with some % doing LOT=true anyways. D feels a little
> silly, but maybe a good tradeoff.
>
> If I had to summarize the emotional dynamic among developers around
> LOT=true, I think devs wish it didn't exist because it is clear LOT=true
> *creates* the issues here. LOT=false would be fine if the LOT=true strategy
> didn't exist at all. But unfortunately the cat is out of the bag and cannot
> be put back in. To validate the emotions, I think it is fine to be angry
> about LOT=true and not like it, but we should either accept that it is most
> likely to create consensus OR we should find a new game theoretic
> activation strategy with better pro-social equilibriums.
>
> Personally, I think with either plan the ultimate risk of forking is low
> given probability to activate before timeout, so we should just pick
> something and move on, accepting that we aren't setting a precedent by
> which all future forks should abide. Given my understanding of the
> tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't
> move to hold back a plan of LOT=false (but would probably take mitigative
> steps on community advocacy if it looks like there is non majority but non
> negligible LOT=true uptake).
>
> Cheers,
>
> Jeremy
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr">I wanted to follow up on what Jeremy and =
others are saying regards finding consensus on LOT. I&#39;ve seen a few oth=
er opinions saying that finding consensus on the LOT value is far more impo=
rtant than what the LOT value actually is. This makes sense because if 100%=
 of economic activity is running the same rule set, there is no=C2=A0diverg=
ence, regardless of which value is picked.<div><br></div><div>It is my unde=
rstanding that those who oppose LOT=3Dtrue are mostly opposed on the ground=
s of it <i>appearing</i> &quot;unnecessarily coercive&quot; and that this l=
ack of consensus can precipitate a chain split at the &quot;brinksmanship=
=C2=A0period&quot; as Jeremy refers to it. I don&#39;t think that we can sa=
y that LOT=3Dtrue is coercive at all unless there is some opposition to Tap=
root itself. Opposition on the grounds that it <i>may</i> be opposed by oth=
ers and Core does not want to assert control over the protocol is a conserv=
ative view but ultimately contingent upon opposition to Taproot for more fu=
ndamental reasons. If no one opposes it, then by definition you have consen=
sus, and in that case I also don&#39;t think that the LOT=3Dtrue (or false)=
 in that regard sets meaningful precedent, as I would expect precedents to =
only be meaningful if they were established=C2=A0during a contentious scena=
rio. As it stands we have precedents for both MASF&#39;s and UASF&#39;s to =
execute soft forks in Bitcoin.</div><div><br></div><div>Of course it seems =
intractable to ascertain the views of ~100% of the Bitcoin constituency, an=
d therefore it gives credibility to the argument that by coming to consensu=
s on LOT=3Dfalse among those who <i>are</i> speaking up is safer with the e=
mbedded assumptions that modifying consensus beyond what core ships is an a=
ctive choice, presumably by those who know what they are doing. However, th=
e simple act of Core choosing to ship an unconfigurable LOT=3Dfalse value d=
oes not <i>prevent</i> the forking and creation of a UASF client. As Jeremy=
 points out, the LOT=3Dtrue possibility always exists here, and we have mul=
tiple high profile people saying they will be running that regardless of ho=
w things turn out. It seems to me that in this scenario, LOT=3Dfalse does l=
ess to prevent a chain split.=C2=A0</div><div><br></div><div>In regards to =
precedent, there may be good reasons to force that minority to fork themsel=
ves off the network, as would be the case if a hypothetical soft fork was a=
 consensus action to blacklist some UTXO&#39;s or something else that weapo=
nizes consensus against some subset of Bitcoin&#39;s user base, but I haven=
&#39;t heard a single person who advocates for LOT=3Dfalse on the grounds t=
hat they <i>themselves</i> oppose the consensus change that is being propos=
ed here. So if the goal is to prevent a chain split, and the soft fork is b=
enign and essentially &quot;annexing unoccupied territory&quot; with respec=
t to script versions, and no one actually has opposed Taproot itself, then =
I fail to see how LOT=3Dfalse is safer in the presence of a grenade defense=
 by the LOT=3Dtrue crowd.</div><div><br></div><div>I personally <i>prefer</=
i>=C2=A0LOT=3Dtrue for these reasons, but I am NOT going to be joining the =
ranks of the intolerant minority if Core ultimately ships LOT=3Dfalse. I th=
ink it is more important to stay in consensus, and as a result I am able to=
 be convinced that false is the right answer. My question to everyone else =
(true AND false advocates) is this: what would you have to observe, in orde=
r to change your mind or is it immutably made up? If we have a significant =
portion of the community that is immutably made up to go false, and another=
 portion that is going to go true, the asymmetry of the fork almost <i>requ=
ires</i>=C2=A0that those of us whose opinions are malleable to break for tr=
ue.</div><div><br></div><div>If social consensus is what drives technical c=
onsensus and not the other way around it seems as if there cannot exist a v=
alid (rational?) reason to oppose Taproot itself, and then by extension wit=
h the arguments laid out above, LOT=3Dtrue seems to be the logical conclusi=
on of all of this, even if Core ships LOT=3Dfalse at the outset.</div><div>=
<br></div><div>Where am I wrong here?</div><div><br></div><div>Keagan</div>=
<div><br></div></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)">Not responding to anyone in part=
icular, but it strikes me that one can think about the case where a small m=
inority (let&#39;s say H =3D 20%?) of nodes select the opposite of what Cor=
e releases (LOT=3Dfalse, LOT=3Dtrue). I&#39;m ignoring the case where a cri=
tical bug is discovered in Taproot for reasons I could expand on if anyone =
is interested (I don&#39;t think LOT=3Dtrue/false has much of a diff in tha=
t regard).</div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">You&#39;ll note an asymme=
try with LOT=3Dtrue / false analysis. LOT=3Dtrue nodes are clearly updated =
(or lying), LOT=3Dfalse nodes may be un-upgraded (or however you want to in=
terpret it).<br></div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b># 80% on LOT=3Df=
alse, 20% LOT=3DTrue<br></b></div><div style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Case =
1: Activates ahead of time anyways</div><div style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">N=
o issues.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Case 2: Fails to Act=
ivate before timeout...<br></div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">20% *may=
* fork off with LOT=3Dtrue. Bitcoin hashrate reduced, chance of multi block=
 reorgs at time of fork relatively high, especially if network does not par=
tition. <br></div><div style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)">Implication is that act=
ivation % being 90%, then X% fewer than 70% of miners are signaling for Tap=
root at this time.=C2=A0 If X% is small the increased orphan rate caused by=
 the LOT=3Dtrue miners will cause it to activate anyways. If X% is larger, =
then there will be a consensus split.<br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><b># 80% on LOT=3Dtrue, 20% LOT=3DFalse<br></b>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">- Case 1: Activates ahead of time Anyways</div><div><br><=
/div><div><span class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)">No issues.<br></span></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">- Case 2: Fails to Activate before timeout=
...<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)">A% + B% + C% =3D 20%<br></di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">A% (upgraded, signal activate) remain o=
n majority chain with LOT=3Dfalse, blocks mined universally valid.  </div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">B% (upgraded, not signaling) succeeds in a=
ctivating and maintaining consensus, blocks are temporarily lost during the=
 final period, but consensus re-emerges.<br></div><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)">C% (not upgraded/not signalling) both fail to activate (not upgrad=
ed) and blocks are rejected (not signaling) during mandatory signalling. Es=
sentially becomes an SPV miner, should still not select transactions improp=
erly given mempool policy, but may mine a bad tip.<br></div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br=
></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">(I argue that group B is irrational entirely, as in this=
 case the majority has upgraded, inevitably winning, and is orphaning their=
 blocks so B should effectively be 0% or can be combined with group C as be=
ing somehow not upgraded if they are unable to switch once it becomes clear=
 after say the first 100 blocks in the period that LOT &gt; 50%. The only d=
ifference in lumping B with C is that group C SPV mines after the fork and =
B should, in theory, have full validation.).<br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Apologies if my ba=
se analysis is off -- happy to take corrections.</div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)">My overall summary is thus:</div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)">1) People care what Core releases because we ass=
ume the majority will likely run it. If core were a minority project, we wo=
uldn&#39;t really care what core released.<br></div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) People a=
re upset with LOT=3Dtrue being suggested as release parameters because of t=
he <i>narrative</i> that it puts devs in control.</div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">3) LOT=
=3Dtrue having a sizeable minority running it presents major issues to majo=
rity LOT=3Dfalse in terms of lost blocks during the final period and in ter=
ms of a longer term fork.</div><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)">4) Majority LOT=3Dtrue has no lo=
ng term instability on consensus (majority LOT=3Dtrue means the final perio=
d always activates, any instability is short lived + irrational).<br></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">5) On the balance, the safer parameter to release *seems* to be=
 LOT=3Dtrue. But because devs are sensitive to control narrative, LOT=3Dfal=
se is preferred by devs.</div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">6) Almost paradoxically, choosing=
 a <i>less safe</i> option for a narrative reason is more of a show of dev =
control than choosing a more safe option despite appearances.</div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">7) This all comes down to if we think that a reasonable number of impor=
tant nodes will run LOT=3Dtrue. <br></div><div style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">8) This all doesn&#39=
;t matter *that much* because taproot will have many opportunities to activ=
ate before the brinksmanship period.<br></div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">As a plan of action, I think that means that either:</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)">A) Core should release LOT=3Dtrue, as a less disrup=
tive option given stated community intentions to do LOT=3Dtrue<br></div><di=
v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)">B) Core=C2=A0 community should vehemently anti-advocate running LO=
T=3Dtrue to ensure the % is as small as possible</div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">C) Do not=
hing</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">D) Core community should release LOT=3Dfalse and vehe=
mently advocate manually changing to LOT=3Dtrue to ensure the % is supermaj=
ority, but leaving it as a user choice.<br></div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">Overall, I worry that plan B has a mild Strei=
ssand effect and would result in boosting LOT=3Dtrue (which could be OK, so=
 long as LOT=3Dtrue=C2=A0+ LOT=3Dfalse+signal yes becomes the large majorit=
y, but would be not fun for anyone if LOT=3Dtrue + LOT=3Dfalse+signal yes a=
re a small majority). Plan C most likely ends up with some % doing LOT=3Dtr=
ue anyways. D feels a little silly, but maybe a good tradeoff.<br></div><di=
v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">If I had to summarize the emotional dynamic =
among developers around LOT=3Dtrue, I think devs wish it didn&#39;t exist b=
ecause it is clear LOT=3Dtrue *creates* the issues here. LOT=3Dfalse would =
be fine if the LOT=3Dtrue strategy didn&#39;t exist at all. But unfortunate=
ly the cat is out of the bag and cannot be put back in. To validate the emo=
tions, I think it is fine to be angry about LOT=3Dtrue and not like it, but=
 we should either accept that it is most likely to create consensus OR we s=
hould find a new game theoretic activation strategy with better pro-social =
equilibriums.</div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Personally, I think wi=
th either plan the ultimate risk of forking is low given probability to act=
ivate before timeout, so we should just pick something and move on, accepti=
ng that we aren&#39;t setting a precedent by which all future forks should =
abide. Given my understanding of the tradeoffs, I believe that the safest c=
hoice is LOT=3Dtrue, but I wouldn&#39;t move to hold back a plan of LOT=3Df=
alse (but would probably take mitigative steps on community advocacy if it =
looks like there is non majority but non negligible LOT=3Dtrue uptake).<br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">Cheers,</div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">Jeremy<br></div><div style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></div><br></d=
iv>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000cb978405bc05fdb9--