{"type":"rich","version":"1.0","author_name":"npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","author_url":"https://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-23\n📝 Original message:Not responding to anyone in particular, but it strikes me that one can\nthink about the case where a small minority (let's say H = 20%?) of nodes\nselect the opposite of what Core releases (LOT=false, LOT=true). I'm\nignoring the case where a critical bug is discovered in Taproot for reasons\nI could expand on if anyone is interested (I don't think LOT=true/false has\nmuch of a diff in that regard).\n\nYou'll note an asymmetry with LOT=true / false analysis. LOT=true nodes are\nclearly updated (or lying), LOT=false nodes may be un-upgraded (or however\nyou want to interpret it).\n\n\n*# 80% on LOT=false, 20% LOT=True*\n\n- Case 1: Activates ahead of time anyways\n\nNo issues.\n\n- Case 2: Fails to Activate before timeout...\n\n20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of multi\nblock reorgs at time of fork relatively high, especially if network does\nnot partition.\n\nImplication is that activation % being 90%, then X% fewer than 70% of\nminers are signaling for Taproot at this time.  If X% is small the\nincreased orphan rate caused by the LOT=true miners will cause it to\nactivate anyways. If X% is larger, then there will be a consensus split.\n\n\n\n*# 80% on LOT=true, 20% LOT=False*\n- Case 1: Activates ahead of time Anyways\n\nNo issues.\n\n- Case 2: Fails to Activate before timeout...\n\nA% + B% + C% = 20%\n\nA% (upgraded, signal activate) remain on majority chain with LOT=false,\nblocks mined universally valid.\n\nB% (upgraded, not signaling) succeeds in activating and maintaining\nconsensus, blocks are temporarily lost during the final period, but\nconsensus re-emerges.\n\nC% (not upgraded/not signalling) both fail to activate (not upgraded) and\nblocks are rejected (not signaling) during mandatory signalling.\nEssentially becomes an SPV miner, should still not select transactions\nimproperly given mempool policy, but may mine a bad tip.\n\n(I argue that group B is irrational entirely, as in this case the majority\nhas upgraded, inevitably winning, and is orphaning their blocks so B should\neffectively be 0% or can be combined with group C as being somehow not\nupgraded if they are unable to switch once it becomes clear after say the\nfirst 100 blocks in the period that LOT \u003e 50%. The only difference in\nlumping B with C is that group C SPV mines after the fork and B should, in\ntheory, have full validation.).\n\n\n\nApologies if my base analysis is off -- happy to take corrections.\n\n\nMy overall summary is thus:\n\n1) People care what Core releases because we assume the majority will\nlikely run it. If core were a minority project, we wouldn't really care\nwhat core released.\n2) People are upset with LOT=true being suggested as release parameters\nbecause of the *narrative* that it puts devs in control.\n3) LOT=true having a sizeable minority running it presents major issues to\nmajority LOT=false in terms of lost blocks during the final period and in\nterms of a longer term fork.\n4) Majority LOT=true has no long term instability on consensus (majority\nLOT=true means the final period always activates, any instability is short\nlived + irrational).\n5) On the balance, the safer parameter to release *seems* to be LOT=true.\nBut because devs are sensitive to control narrative, LOT=false is preferred\nby devs.\n6) Almost paradoxically, choosing a *less safe* option for a narrative\nreason is more of a show of dev control than choosing a more safe option\ndespite appearances.\n7) This all comes down to if we think that a reasonable number of important\nnodes will run LOT=true.\n8) This all doesn't matter *that much* because taproot will have many\nopportunities to activate before the brinksmanship period.\n\nAs a plan of action, I think that means that either:\n\nA) Core should release LOT=true, as a less disruptive option given stated\ncommunity intentions to do LOT=true\nB) Core  community should vehemently anti-advocate running LOT=true to\nensure the % is as small as possible\nC) Do nothing\nD) Core community should release LOT=false and vehemently advocate manually\nchanging to LOT=true to ensure the % is supermajority, but leaving it as a\nuser choice.\n\n\nOverall, I worry that plan B has a mild Streissand effect and would result\nin boosting LOT=true (which could be OK, so long as LOT=true +\nLOT=false+signal yes becomes the large majority, but would be not fun for\nanyone if LOT=true + LOT=false+signal yes are a small majority). Plan C\nmost likely ends up with some % doing LOT=true anyways. D feels a little\nsilly, but maybe a good tradeoff.\n\nIf I had to summarize the emotional dynamic among developers around\nLOT=true, I think devs wish it didn't exist because it is clear LOT=true\n*creates* the issues here. LOT=false would be fine if the LOT=true strategy\ndidn't exist at all. But unfortunately the cat is out of the bag and cannot\nbe put back in. To validate the emotions, I think it is fine to be angry\nabout LOT=true and not like it, but we should either accept that it is most\nlikely to create consensus OR we should find a new game theoretic\nactivation strategy with better pro-social equilibriums.\n\nPersonally, I think with either plan the ultimate risk of forking is low\ngiven probability to activate before timeout, so we should just pick\nsomething and move on, accepting that we aren't setting a precedent by\nwhich all future forks should abide. Given my understanding of the\ntradeoffs, I believe that the safest choice is LOT=true, but I wouldn't\nmove to hold back a plan of LOT=false (but would probably take mitigative\nsteps on community advocacy if it looks like there is non majority but non\nnegligible LOT=true uptake).\n\nCheers,\n\nJeremy\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210222/019548d1/attachment-0001.html\u003e"}