path: root/00/e10f6160a03579e6fcc007bd6e060ed3be91cd

Return-Path: <jlrubin@mit.edu>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CE1BDC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 02:10:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id C9F408574B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 02:10:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id kENuyTCM6ET5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 02:10:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id EA04185485
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Feb 2021 02:10:48 +0000 (UTC)
Received: from mail-il1-f181.google.com (mail-il1-f181.google.com
 [209.85.166.181]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11N2AkaM014024
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 22 Feb 2021 21:10:47 -0500
Received: by mail-il1-f181.google.com with SMTP id w1so12708639ilm.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Feb 2021 18:10:47 -0800 (PST)
X-Gm-Message-State: AOAM532l1iOn0RTUk4uKP2P+OVXgEsj2R2vH/pd9/DjuEKrg4R3JLw+8
 vk7HbAJLZyJqvOIlR9YhPi9W7vsRiZTOxo3Mgos=
X-Google-Smtp-Source: ABdhPJxC7bd0yrMzY9oJMzr/9CplgguAyG4vWpUhw3VFlE2VdtklD4d7pxx6EImNJRPiJfp1fzSmQGqZXM6aBTKLL7A=
X-Received: by 2002:a05:6e02:164c:: with SMTP id
 v12mr17551324ilu.49.1614046246592; 
 Mon, 22 Feb 2021 18:10:46 -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>
In-Reply-To: <CABm2gDp5dRTrPEqPfrjOeeYBn6RMS=HFMbtkJ+MM0SMVnSfK5A@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 22 Feb 2021 18:10:34 -0800
X-Gmail-Original-Message-ID: <CAD5xwhg0pWJykWUusdoNQd60L9_MgCzzky1dvViLERADMcoysQ@mail.gmail.com>
Message-ID: <CAD5xwhg0pWJykWUusdoNQd60L9_MgCzzky1dvViLERADMcoysQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002dea2305bbf76d66"
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 02:10:50 -0000

--0000000000002dea2305bbf76d66
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">Not responding to anyo=
ne in particular, but it strikes me that one can think about the case where=
 a small minority (let&#39;s say H =3D 20%?) of nodes select the opposite o=
f what Core releases (LOT=3Dfalse, LOT=3Dtrue). I&#39;m ignoring the case w=
here a critical 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 d=
iff in that regard).</div><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><di=
v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)" class=3D"gmail_default">You&#39;ll note an asymmetry with LOT=3Dtr=
ue / false analysis. LOT=3Dtrue nodes are clearly updated (or lying), LOT=
=3Dfalse nodes may be un-upgraded (or however you want to interpret it).<br=
></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g=
mail_default"><b># 80% on LOT=3Dfalse, 20% LOT=3DTrue<br></b></div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">-=
 Case 1: Activates ahead of time anyways</div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_de=
fault"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">No issues.<br></div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult">- Case 2: Fails to Activate before timeout...<br></div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cla=
ss=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">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)" class=3D"gmail_default"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">Implication is that activation % being 90%, then =
X% fewer than 70% of miners are signaling for Taproot at this time.=C2=A0 I=
f X% is small the increased orphan rate caused by the LOT=3Dtrue miners wil=
l cause it to activate anyways. If X% is larger, then there will be a conse=
nsus split.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><=
b># 80% on LOT=3Dtrue, 20% LOT=3DFalse<br></b></div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm=
ail_default">- Case 1: Activates ahead of time Anyways</div><div><br></div>=
<div><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">No issues.<br></span></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"=
>- 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)" class=
=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">A% + B% + =
C% =3D 20%<br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default">A% (upgraded, signal activate) remain on majorit=
y chain with LOT=3Dfalse, blocks mined universally valid.  </div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">B% =
(upgraded, not signaling) succeeds in activating and maintaining consensus,=
 blocks are temporarily lost during the final period, but consensus re-emer=
ges.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cla=
ss=3D"gmail_default">C% (not upgraded/not signalling) both fail to activate=
 (not upgraded) and blocks are rejected (not signaling) during mandatory si=
gnalling. Essentially becomes an SPV miner, should still not select transac=
tions improperly given mempool policy, but may mine a bad tip.<br></div><di=
v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defau=
lt">(I argue that group B is irrational entirely, as in this case the major=
ity has upgraded, inevitably winning, and is orphaning their blocks so B sh=
ould 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 &gt; 50%. The only difference in lu=
mping B with C is that group C SPV mines after the fork and B should, in th=
eory, have full validation.).<br></div><div style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">=
<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Apologies =
if my base analysis is off -- happy to take corrections.</div><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" c=
lass=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></=
div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)" class=3D"gmail_default">My overall summary is thus:</div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult">1) People care what Core releases because we assume the majority will =
likely run it. If core were a minority project, we wouldn&#39;t really care=
 what core released.<br></div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">2) People=
 are upset with LOT=3Dtrue being suggested as release parameters because of=
 the <i>narrative</i> that it puts devs in control.</div><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">3) LOT=3Dtrue having a sizeable minority running it pres=
ents major issues to majority LOT=3Dfalse in terms of lost blocks during th=
e final period and in terms of a longer term fork.</div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">4) Majority LOT=3Dtrue has no long term instability on c=
onsensus (majority LOT=3Dtrue means the final period always activates, any =
instability is short lived + irrational).<br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default">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)" class=3D"gmail_default">6) Almost=
 paradoxically, choosing a <i>less safe</i> option for a narrative reason i=
s more of a show of dev control than choosing a more safe option despite ap=
pearances.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default">7) This all comes down =
to if we think that a reasonable number of important nodes will run LOT=3Dt=
rue. <br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)" class=3D"gmail_default">8) This all doesn&#39;t =
matter *that much* because taproot will have many opportunities to activate=
 before the brinksmanship period.<br></div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defau=
lt"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)" class=3D"gmail_default">As a plan of action, I th=
ink that means that either:</div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></=
div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)" class=3D"gmail_default">A) Core should release LOT=3Dtrue, =
as a less disruptive option given stated community intentions to do LOT=3Dt=
rue<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:rgb(0,0,0)" class=3D"gmail_default">B) Core=C2=A0 community sh=
ould vehemently anti-advocate running LOT=3Dtrue to ensure the % is as smal=
l as possible</div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)" class=3D"gmail_default">C) Do nothing</div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)" class=3D"gmail_default">D) Core community should release LOT=3Df=
alse and vehemently advocate manually changing to LOT=3Dtrue to ensure the =
% is supermajority, 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)" c=
lass=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></=
div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)" class=3D"gmail_default">Overall, I worry that plan B has a =
mild Streissand 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 lar=
ge majority, but would be not fun for anyone if LOT=3Dtrue + LOT=3Dfalse+si=
gnal yes are a small majority). Plan C most likely ends up with some % doin=
g LOT=3Dtrue anyways. D feels a little silly, but maybe a good tradeoff.<br=
></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g=
mail_default">If I had to summarize the emotional dynamic among developers =
around LOT=3Dtrue, I think devs wish it didn&#39;t exist because it is clea=
r LOT=3Dtrue *creates* the issues here. LOT=3Dfalse would be fine if the LO=
T=3Dtrue strategy didn&#39;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=3Dtrue 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.</di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_=
default">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&#39;t setting a precedent by=
 which all future forks should abide. Given my understanding of the tradeof=
fs, I believe that the safest choice is LOT=3Dtrue, but I wouldn&#39;t move=
 to hold back a plan of LOT=3Dfalse (but would probably take mitigative ste=
ps on community advocacy if it looks like there is non majority but non neg=
ligible LOT=3Dtrue uptake).<br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b=
r></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)" class=3D"gmail_default">Cheers,</div><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Jeremy<br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm=
ail_default"></div><br></div>

--0000000000002dea2305bbf76d66--