{"type":"rich","version":"1.0","author_name":"npub18cagy0gpu9gmpdcu6052xg0fnp86cm0m5gsanv6j25myfecdjqhqsw4acy","author_url":"https://nostr.ae/npub18cagy0gpu9gmpdcu6052xg0fnp86cm0m5gsanv6j25myfecdjqhqsw4acy","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-23\n📝 Original message:Relative to your arguments, Keagan and Jeremy, and speaking in favor of\nLOT=false, from my limited perspective:\n\n\u003e As Jeremy points out, the LOT=true possibility always exists here, and we\nhave multiple high profile people saying they will be running that\nregardless of how things turn out. It seems to me that in this scenario,\nLOT=false does less to prevent a chain split.\n\u003e So if the goal is to prevent a chain split, and the soft fork is benign\nand essentially \"annexing unoccupied territory\" with respect to script\nversions, and no one actually has opposed Taproot itself, then I fail to\nsee how LOT=false is safer in the presence of a grenade defense by the\nLOT=true crowd.\n\nI don't believe the goal is to avoid a chain split, nor to activate\nTaproot. Over the long term it will not have been important when exactly\nTaproot activated, or whether a minority forked off, but what culture and\nnorms we adopted in putting forward this change. A culture of deference to\nthe network makes Core worthy of remaining the reference implementation of\nBitcoin.\n\nGiven Core's special position in the client ecosystem, I see these outcomes\nare asymmetric:\na) If an intolerant minority signals LOT=true in contradiction to core,\nthey are splitting consensus / forking off consensus, which is their right\nto do in our open ecosystem.\nb) If Core ships LOT=true, we are in fact imposing a change on the network.\nThis may be justified in the end, but it should be used with discretion.\n\nIf LOT=false fails to activate, then the failure will have revealed\ninformation about sentiments and elements of the network, and we will have\nan opportunity then to address that information before proceeding with\nLOT=true.\n\nTo adopt b) as a pre-emptive defense against a) is to express will without\nevidence of necessity or opportunity for justification.\n\nFinally, as others have said, I think this option is likely to be moot -\nlet's not act defensively out of SEGWIT trauma, but with trust in the\nnetwork.\n\nBest,\nBen\n\nOn Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I wanted to follow up on what Jeremy and others are saying regards finding\n\u003e consensus on LOT. I've seen a few other opinions saying that finding\n\u003e consensus on the LOT value is far more important than what the LOT value\n\u003e actually is. This makes sense because if 100% of economic activity is\n\u003e running the same rule set, there is no divergence, regardless of which\n\u003e value is picked.\n\u003e\n\u003e It is my understanding that those who oppose LOT=true are mostly opposed\n\u003e on the grounds of it *appearing* \"unnecessarily coercive\" and that this\n\u003e lack of consensus can precipitate a chain split at the\n\u003e \"brinksmanship period\" as Jeremy refers to it. I don't think that we can\n\u003e say that LOT=true is coercive at all unless there is some opposition to\n\u003e Taproot itself. Opposition on the grounds that it *may* be opposed by\n\u003e others and Core does not want to assert control over the protocol is a\n\u003e conservative view but ultimately contingent upon opposition to Taproot for\n\u003e more fundamental reasons. If no one opposes it, then by definition you have\n\u003e consensus, and in that case I also don't think that the LOT=true (or false)\n\u003e in that regard sets meaningful precedent, as I would expect precedents to\n\u003e only be meaningful if they were established during a contentious scenario.\n\u003e As it stands we have precedents for both MASF's and UASF's to execute soft\n\u003e forks in Bitcoin.\n\u003e\n\u003e Of course it seems intractable to ascertain the views of ~100% of the\n\u003e Bitcoin constituency, and therefore it gives credibility to the argument\n\u003e that by coming to consensus on LOT=false among those who *are* speaking\n\u003e up is safer with the embedded assumptions that modifying consensus beyond\n\u003e what core ships is an active choice, presumably by those who know what they\n\u003e are doing. However, the simple act of Core choosing to ship an\n\u003e unconfigurable LOT=false value does not *prevent* the forking and\n\u003e creation of a UASF client. As Jeremy points out, the LOT=true possibility\n\u003e always exists here, and we have multiple high profile people saying they\n\u003e will be running that regardless of how things turn out. It seems to me that\n\u003e in this scenario, LOT=false does less to prevent a chain split.\n\u003e\n\u003e In regards to precedent, there may be good reasons to force that minority\n\u003e to fork themselves off the network, as would be the case if a hypothetical\n\u003e soft fork was a consensus action to blacklist some UTXO's or something else\n\u003e that weaponizes consensus against some subset of Bitcoin's user base, but I\n\u003e haven't heard a single person who advocates for LOT=false on the grounds\n\u003e that they *themselves* oppose the consensus change that is being proposed\n\u003e here. So if the goal is to prevent a chain split, and the soft fork is\n\u003e benign and essentially \"annexing unoccupied territory\" with respect to\n\u003e script versions, and no one actually has opposed Taproot itself, then I\n\u003e fail to see how LOT=false is safer in the presence of a grenade defense by\n\u003e the LOT=true crowd.\n\u003e\n\u003e I personally *prefer* LOT=true for these reasons, but I am NOT going to\n\u003e be joining the ranks of the intolerant minority if Core ultimately ships\n\u003e LOT=false. I think it is more important to stay in consensus, and as a\n\u003e result I am able to be convinced that false is the right answer. My\n\u003e question to everyone else (true AND false advocates) is this: what would\n\u003e you have to observe, in order to change your mind or is it immutably made\n\u003e up? If we have a significant portion of the community that is immutably\n\u003e made up to go false, and another portion that is going to go true, the\n\u003e asymmetry of the fork almost *requires* that those of us whose opinions\n\u003e are malleable to break for true.\n\u003e\n\u003e If social consensus is what drives technical consensus and not the other\n\u003e way around it seems as if there cannot exist a valid (rational?) reason to\n\u003e oppose Taproot itself, and then by extension with the arguments laid out\n\u003e above, LOT=true seems to be the logical conclusion of all of this, even if\n\u003e Core ships LOT=false at the outset.\n\u003e\n\u003e Where am I wrong here?\n\u003e\n\u003e Keagan\n\u003e\n\u003e On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Not responding to anyone in particular, but it strikes me that one can\n\u003e\u003e think about the case where a small minority (let's say H = 20%?) of nodes\n\u003e\u003e select the opposite of what Core releases (LOT=false, LOT=true). I'm\n\u003e\u003e ignoring the case where a critical bug is discovered in Taproot for reasons\n\u003e\u003e I could expand on if anyone is interested (I don't think LOT=true/false has\n\u003e\u003e much of a diff in that regard).\n\u003e\u003e\n\u003e\u003e You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes\n\u003e\u003e are clearly updated (or lying), LOT=false nodes may be un-upgraded (or\n\u003e\u003e however you want to interpret it).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e *# 80% on LOT=false, 20% LOT=True*\n\u003e\u003e\n\u003e\u003e - Case 1: Activates ahead of time anyways\n\u003e\u003e\n\u003e\u003e No issues.\n\u003e\u003e\n\u003e\u003e - Case 2: Fails to Activate before timeout...\n\u003e\u003e\n\u003e\u003e 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of\n\u003e\u003e multi block reorgs at time of fork relatively high, especially if network\n\u003e\u003e does not partition.\n\u003e\u003e\n\u003e\u003e Implication is that activation % being 90%, then X% fewer than 70% of\n\u003e\u003e miners are signaling for Taproot at this time.  If X% is small the\n\u003e\u003e increased orphan rate caused by the LOT=true miners will cause it to\n\u003e\u003e activate anyways. If X% is larger, then there will be a consensus split.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e *# 80% on LOT=true, 20% LOT=False*\n\u003e\u003e - Case 1: Activates ahead of time Anyways\n\u003e\u003e\n\u003e\u003e No issues.\n\u003e\u003e\n\u003e\u003e - Case 2: Fails to Activate before timeout...\n\u003e\u003e\n\u003e\u003e A% + B% + C% = 20%\n\u003e\u003e\n\u003e\u003e A% (upgraded, signal activate) remain on majority chain with LOT=false,\n\u003e\u003e blocks mined universally valid.\n\u003e\u003e\n\u003e\u003e B% (upgraded, not signaling) succeeds in activating and maintaining\n\u003e\u003e consensus, blocks are temporarily lost during the final period, but\n\u003e\u003e consensus re-emerges.\n\u003e\u003e\n\u003e\u003e C% (not upgraded/not signalling) both fail to activate (not upgraded) and\n\u003e\u003e blocks are rejected (not signaling) during mandatory signalling.\n\u003e\u003e Essentially becomes an SPV miner, should still not select transactions\n\u003e\u003e improperly given mempool policy, but may mine a bad tip.\n\u003e\u003e\n\u003e\u003e (I argue that group B is irrational entirely, as in this case the\n\u003e\u003e majority has upgraded, inevitably winning, and is orphaning their blocks so\n\u003e\u003e B should effectively be 0% or can be combined with group C as being somehow\n\u003e\u003e not upgraded if they are unable to switch once it becomes clear after say\n\u003e\u003e the first 100 blocks in the period that LOT \u003e 50%. The only difference in\n\u003e\u003e lumping B with C is that group C SPV mines after the fork and B should, in\n\u003e\u003e theory, have full validation.).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Apologies if my base analysis is off -- happy to take corrections.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e My overall summary is thus:\n\u003e\u003e\n\u003e\u003e 1) People care what Core releases because we assume the majority will\n\u003e\u003e likely run it. If core were a minority project, we wouldn't really care\n\u003e\u003e what core released.\n\u003e\u003e 2) People are upset with LOT=true being suggested as release parameters\n\u003e\u003e because of the *narrative* that it puts devs in control.\n\u003e\u003e 3) LOT=true having a sizeable minority running it presents major issues\n\u003e\u003e to majority LOT=false in terms of lost blocks during the final period and\n\u003e\u003e in terms of a longer term fork.\n\u003e\u003e 4) Majority LOT=true has no long term instability on consensus (majority\n\u003e\u003e LOT=true means the final period always activates, any instability is short\n\u003e\u003e lived + irrational).\n\u003e\u003e 5) On the balance, the safer parameter to release *seems* to be LOT=true.\n\u003e\u003e But because devs are sensitive to control narrative, LOT=false is preferred\n\u003e\u003e by devs.\n\u003e\u003e 6) Almost paradoxically, choosing a *less safe* option for a narrative\n\u003e\u003e reason is more of a show of dev control than choosing a more safe option\n\u003e\u003e despite appearances.\n\u003e\u003e 7) This all comes down to if we think that a reasonable number of\n\u003e\u003e important nodes will run LOT=true.\n\u003e\u003e 8) This all doesn't matter *that much* because taproot will have many\n\u003e\u003e opportunities to activate before the brinksmanship period.\n\u003e\u003e\n\u003e\u003e As a plan of action, I think that means that either:\n\u003e\u003e\n\u003e\u003e A) Core should release LOT=true, as a less disruptive option given stated\n\u003e\u003e community intentions to do LOT=true\n\u003e\u003e B) Core  community should vehemently anti-advocate running LOT=true to\n\u003e\u003e ensure the % is as small as possible\n\u003e\u003e C) Do nothing\n\u003e\u003e D) Core community should release LOT=false and vehemently advocate\n\u003e\u003e manually changing to LOT=true to ensure the % is supermajority, but leaving\n\u003e\u003e it as a user choice.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Overall, I worry that plan B has a mild Streissand effect and would\n\u003e\u003e result in boosting LOT=true (which could be OK, so long as LOT=true +\n\u003e\u003e LOT=false+signal yes becomes the large majority, but would be not fun for\n\u003e\u003e anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C\n\u003e\u003e most likely ends up with some % doing LOT=true anyways. D feels a little\n\u003e\u003e silly, but maybe a good tradeoff.\n\u003e\u003e\n\u003e\u003e If I had to summarize the emotional dynamic among developers around\n\u003e\u003e LOT=true, I think devs wish it didn't exist because it is clear LOT=true\n\u003e\u003e *creates* the issues here. LOT=false would be fine if the LOT=true strategy\n\u003e\u003e didn't exist at all. But unfortunately the cat is out of the bag and cannot\n\u003e\u003e be put back in. To validate the emotions, I think it is fine to be angry\n\u003e\u003e about LOT=true and not like it, but we should either accept that it is most\n\u003e\u003e likely to create consensus OR we should find a new game theoretic\n\u003e\u003e activation strategy with better pro-social equilibriums.\n\u003e\u003e\n\u003e\u003e Personally, I think with either plan the ultimate risk of forking is low\n\u003e\u003e given probability to activate before timeout, so we should just pick\n\u003e\u003e something and move on, accepting that we aren't setting a precedent by\n\u003e\u003e which all future forks should abide. Given my understanding of the\n\u003e\u003e tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't\n\u003e\u003e move to hold back a plan of LOT=false (but would probably take mitigative\n\u003e\u003e steps on community advocacy if it looks like there is non majority but non\n\u003e\u003e negligible LOT=true uptake).\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e\n\u003e\u003e Jeremy\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210223/90c7bfe1/attachment-0001.html\u003e"}