Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8AAC5C0001 for ; Tue, 23 Feb 2021 23:15:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 64CAE4302E for ; Tue, 23 Feb 2021 23:15:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o43J5-cqjNJ for ; Tue, 23 Feb 2021 23:15:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by smtp2.osuosl.org (Postfix) with ESMTPS id 435874302B for ; Tue, 23 Feb 2021 23:15:02 +0000 (UTC) Received: by mail-wm1-f51.google.com with SMTP id o16so264272wmh.0 for ; Tue, 23 Feb 2021 15:15:02 -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 :cc; bh=TCykj0qhorR6CehTewjN4OqYN5YPBAR6r31SW0pzLIQ=; b=DvtFYUM870E8rRJA6blnzGNCjqJhE1I0adGT+NH+291MfVNaVbyJnE7oX1QohFpLHX 7sFT4CNhwW2oqImFo6kPMvGrdGJfPd9CUHDu+zaRRfnfnk52e1bX1BLVGVD3Wk2+S1dD qI2Gm69C+I0aLGKU5lLNx8mUcwNRwmWKzLudRUGJjOsj0PDJ9qWQ0qMiGs4CODIzUh3t dG/JcGW/RBYgVh3HvbzK/Mdc6oIefoB0GD+UZW6h3q9yRqhcxGUqT7jAhrfzW8leGEcT 0vtx195UH9pvyFczHrZdsflzUKrt8TpBU0ypXiz0Q1zDN7Lt1bLfc3upZwfSVVgy/Ekt 5t7g== 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:cc; bh=TCykj0qhorR6CehTewjN4OqYN5YPBAR6r31SW0pzLIQ=; b=VgVja2lU3NJLzHYYmWoZOm3xrj7wy6l1NUuTUm0aYJdhjOVue7mryyjdLcfiExOXAV a3+7o0unnxob7zuEHWJnmsuQOmJUCZ8YO9In8FodpYDVK0/7y0kv4lNTW6Kv7D6zMnYG ci1hN1cgIG97pqeo1fThiXhO2KXglxMCEo1bd3Ts0AYcOfj5n1Zq9qBhSVwOS0UkohAT gdvS6AJDTZSm3jUWrB2GirK32waoOd6qsKDgUWTKjmjfJs+4uuYRfXZGALgcS4GH7Bj0 TIiatj9cpchRXvnDzRsErWMC5DT/9jooDM6DSCHmG9KRStCfIs2H5Hk7NxRk2mEg7W9a CIeQ== X-Gm-Message-State: AOAM531QYfeAR/wWokLq9H+L5lrv06a8dH4or3zbkCJUf8dSyUMsJave 8HiNZ6lezZ+jcwTQvT3+1w0WznEw/MyfXCe+7xQ= X-Google-Smtp-Source: ABdhPJxEE+oTy1lTm/oGOWJA6vQH8cgldZcWEJIYKGp+n3N5FPCKttIfJMA4h0f4M5YNU50a1+9BTrLB/itybjRizy4= X-Received: by 2002:a1c:4c09:: with SMTP id z9mr962585wmf.122.1614122100295; Tue, 23 Feb 2021 15:15:00 -0800 (PST) MIME-Version: 1.0 References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au> <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com> In-Reply-To: From: Ben Woosley Date: Tue, 23 Feb 2021 15:14:33 -0800 Message-ID: To: Keagan McClelland , Jeremy Content-Type: multipart/alternative; boundary="000000000000698b7705bc091640" X-Mailman-Approved-At: Wed, 24 Feb 2021 00:01:47 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 23:15:04 -0000 --000000000000698b7705bc091640 Content-Type: text/plain; charset="UTF-8" Relative to your arguments, Keagan and Jeremy, and speaking in favor of LOT=false, from my limited perspective: > 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. > 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 don't believe the goal is to avoid a chain split, nor to activate Taproot. Over the long term it will not have been important when exactly Taproot activated, or whether a minority forked off, but what culture and norms we adopted in putting forward this change. A culture of deference to the network makes Core worthy of remaining the reference implementation of Bitcoin. Given Core's special position in the client ecosystem, I see these outcomes are asymmetric: a) If an intolerant minority signals LOT=true in contradiction to core, they are splitting consensus / forking off consensus, which is their right to do in our open ecosystem. b) If Core ships LOT=true, we are in fact imposing a change on the network. This may be justified in the end, but it should be used with discretion. If LOT=false fails to activate, then the failure will have revealed information about sentiments and elements of the network, and we will have an opportunity then to address that information before proceeding with LOT=true. To adopt b) as a pre-emptive defense against a) is to express will without evidence of necessity or opportunity for justification. Finally, as others have said, I think this option is likely to be moot - let's not act defensively out of SEGWIT trauma, but with trust in the network. Best, Ben On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000698b7705bc091640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Relative to your arguments, Keagan and Jeremy, and speakin= g in favor of LOT=3Dfalse, from my limited perspective:

> As Jere= my points out, the LOT=3Dtrue possibility always exists here, and we have m= ultiple high profile people saying they will be running that regardless of = how things turn out. It seems to me that in this scenario, LOT=3Dfalse does= less to prevent a chain split.
> So if the goal is to prevent a chai= n split, and the soft fork is benign and essentially "annexing unoccup= ied territory" with respect to script versions, and no one actually ha= s opposed Taproot itself, then I fail to see how LOT=3Dfalse is safer in th= e presence of a grenade defense by the LOT=3Dtrue crowd.

I don't= believe the goal is to avoid a chain split, nor to activate Taproot. Over = the long term it will not have been important when exactly Taproot activate= d, or whether a minority forked off, but what culture and norms we adopted = in putting forward this change. A culture of deference to the network makes= Core worthy of remaining the reference implementation of Bitcoin.

G= iven Core's special position in the client ecosystem, I see these outco= mes are asymmetric:
a) If an intolerant minority signals LOT=3Dtrue in c= ontradiction to core, they are splitting consensus / forking off consensus,= which is their right to do in our open ecosystem.
b) If Core ships LOT= =3Dtrue, we are in fact imposing a change on the network. This may be justi= fied in the end, but it should be used with discretion.

If LOT=3Dfal= se fails to activate, then the failure will have revealed information about= sentiments and elements of the network, and we will have an opportunity th= en to address that information before proceeding with LOT=3Dtrue.

To= adopt b) as a pre-emptive defense against a) is to express will without ev= idence of necessity or opportunity for justification.

Fi= nally, as others have said, I think this option is likely to be moot - let&= #39;s not act defensively out of SEGWIT trauma, but with trust in the netwo= rk.

Best,
Ben

On Tue, Feb 23, 2021= at 12:09 PM Keagan McClelland via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org> wrote:
I wanted to follow up on what Jeremy and others are saying re= gards finding consensus on LOT. I've seen a few other opinions saying t= hat 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 activit= y is running the same rule set, there is no=C2=A0divergence, regardless of = which value is picked.

It is my understanding that those= who oppose LOT=3Dtrue 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=C2=A0period" as = Jeremy refers to it. I don't think that we can say that LOT=3Dtrue is c= oercive at all unless there is some opposition to Taproot itself. Oppositio= n 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 ultimat= ely 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=3Dtrue (or false) in that regard sets m= eaningful precedent, as I would expect precedents to only be meaningful if = they were established=C2=A0during a contentious scenario. As it stands we h= ave precedents for both MASF's and UASF's to execute soft forks in = Bitcoin.

Of course it seems intractable to ascerta= in the views of ~100% of the Bitcoin constituency, and therefore it gives c= redibility to the argument that by coming to consensus on LOT=3Dfalse among= those who are speaking up is safer with the embedded assumptions th= at modifying consensus beyond what core ships is an active choice, presumab= ly by those who know what they are doing. However, the simple act of Core c= hoosing to ship an unconfigurable LOT=3Dfalse value does not prevent= the forking and creation of a UASF client. As Jeremy points out, the LOT= =3Dtrue possibility always exists here, and we have multiple high profile p= eople saying they will be running that regardless of how things turn out. I= t seems to me that in this scenario, LOT=3Dfalse does less to prevent a cha= in split.=C2=A0

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 agai= nst some subset of Bitcoin's user base, but I haven't heard a singl= e person who advocates for LOT=3Dfalse on the grounds that they themselv= es oppose the consensus change that is being proposed here. So if the g= oal is to prevent a chain split, and the soft fork is benign and essentiall= y "annexing unoccupied territory" with respect to script versions= , and no one actually has opposed Taproot itself, then I fail to see how LO= T=3Dfalse is safer in the presence of a grenade defense by the LOT=3Dtrue c= rowd.

I personally prefer=C2=A0LOT=3Dtrue f= or these reasons, but I am NOT going to be joining the ranks of the intoler= ant minority if Core ultimately ships LOT=3Dfalse. I think it is more impor= tant to stay in consensus, and as a result I am able to be convinced that f= alse is the right answer. My question to everyone else (true AND false advo= cates) is this: what would you have to observe, in order to change your min= d or is it immutably made up? If we have a significant portion of the commu= nity that is immutably made up to go false, and another portion that is goi= ng to go true, the asymmetry of the fork almost requires=C2=A0that t= hose 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?) rea= son to oppose Taproot itself, and then by extension with the arguments laid= out above, LOT=3Dtrue seems to be the logical conclusion of all of this, e= ven if Core ships LOT=3Dfalse at the outset.

Where= am I wrong here?

Keagan

On Mon, F= eb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.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 =3D 20%?) = of nodes select the opposite of what Core releases (LOT=3Dfalse, LOT=3Dtrue= ). 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 LO= T=3Dtrue/false has much of a diff in that regard).

You'll note an asymmetry with LOT=3Dtrue / false analysi= s. LOT=3Dtrue nodes are clearly updated (or lying), LOT=3Dfalse nodes may b= e un-upgraded (or however you want to interpret it).
<= br>
# 80% on LOT=3Dfalse, 20% LOT=3DTrue
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r= gb(0,0,0)">
- Case 1: Activates ahead of time anyways<= /div>

No issues.

=
- Case 2: Fails to Activate before timeout...

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 partition.

<= /div>
Implication is that activation % being 90%, then X% fewer = than 70% of miners are signaling for Taproot at this time.=C2=A0 If X% is s= mall the increased orphan rate caused by the LOT=3Dtrue miners will cause i= t to activate anyways. If X% is larger, then there will be a consensus spli= t.


# 80= % on LOT=3Dtrue, 20% LOT=3DFalse
- Case 1: Activat= es ahead of time Anyways

No issues.

- = Case 2: Fails to Activate before timeout...

=
A% + B% + C% =3D 20%

A% (upgraded, signal activate) remain on majority chain with LOT=3Dfalse,= blocks mined universally valid.

B= % (upgraded, not signaling) succeeds in activating and maintaining consensu= s, blocks are temporarily lost during the final period, but consensus re-em= erges.

C% (not upgraded/not sign= alling) both fail to activate (not upgraded) and blocks are rejected (not s= ignaling) during mandatory signalling. Essentially becomes an SPV miner, sh= ould still not select transactions improperly given mempool policy, but may= mine a bad tip.

(I argue that g= roup B is irrational entirely, as in this case the majority has upgraded, i= nevitably 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 a= re 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 t= hat group C SPV mines after the fork and B should, in theory, have full val= idation.).



Apologies if my base analysis is off -- happy to ta= ke corrections.


My overall summary is thus:

1) Peo= ple 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=3Dtrue being su= ggested as release parameters because of the narrative that it puts = devs in control.
3) LOT=3Dtrue having a sizeable minority = running it presents major issues to majority LOT=3Dfalse in terms of lost b= locks during the final period and in terms of a longer term fork.
4) Majority LOT=3Dtrue has no long term instability on consensus (m= ajority LOT=3Dtrue 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=3Dtrue. But because devs are s= ensitive to control narrative, LOT=3Dfalse is preferred by devs.
6) Almost paradoxically, choosing a less safe option for a na= rrative reason is more of a show of dev control than choosing a more safe o= ption despite appearances.
7) This all comes down to if we= think that a reasonable number of important nodes will run LOT=3Dtrue.
8) This all doesn't matter *that much* because tapro= ot will have many opportunities to activate before the brinksmanship period= .

As a plan of action, I think t= hat means that either:

A) Core shoul= d release LOT=3Dtrue, as a less disruptive option given stated community in= tentions to do LOT=3Dtrue
B) Core=C2=A0 community shou= ld vehemently anti-advocate running LOT=3Dtrue to ensure the % is as small = as possible
C) Do nothing
D) Core communi= ty should release LOT=3Dfalse and vehemently advocate manually changing to = LOT=3Dtrue to ensure the % is supermajority, but leaving it as a user choic= e.


Overall= , I worry that plan B has a mild Streissand effect and would result in boos= ting LOT=3Dtrue (which could be OK, so long as LOT=3Dtrue=C2=A0+ LOT=3Dfals= e+signal yes becomes the large majority, but would be not fun for anyone if= LOT=3Dtrue + LOT=3Dfalse+signal yes are a small majority). Plan C most lik= ely ends up with some % doing LOT=3Dtrue anyways. D feels a little silly, b= ut maybe a good tradeoff.

If I h= ad to summarize the emotional dynamic among developers around LOT=3Dtrue, I= think devs wish it didn't exist because it is clear LOT=3Dtrue *create= s* the issues here. LOT=3Dfalse would be fine if the LOT=3Dtrue strategy di= dn't exist at all. But unfortunately the cat is out of the bag and cann= ot 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 m= ost likely to create consensus OR we should find a new game theoretic activ= ation strategy with better pro-social equilibriums.

Personally, I think with either plan the ultimate risk of f= orking is low given probability to activate before timeout, so we should ju= st pick something and move on, accepting that we aren't setting a prece= dent by which all future forks should abide. Given my understanding of the = tradeoffs, I believe that the safest choice is LOT=3Dtrue, but I wouldn'= ;t move to hold back a plan of LOT=3Dfalse (but would probably take mitigat= ive steps on community advocacy if it looks like there is non majority but = non negligible LOT=3Dtrue uptake).

Cheers,

Jeremy


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000698b7705bc091640--