{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-03-01\n📝 Original message:On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev wrote:\n\u003e As we saw in 2017 with BIP 9, coordinating activation by miner signal alone, \n\u003e despite its potential benefits, also leaves open the door to a miner veto. \n\nTo the contrary, we saw in 2017 that miners could *not* successfully\nveto a BIP 9 activation. It was certainly more effort and risk than was\ndesirable to override the attempted veto, but the attempt at vetoing\nnevertheless failed.\n\n\u003e It wouldn't be much different than adding back the inflation bug \n\u003e (CVE-2018-17144) and trusting miners not to exploit it.\n\nThat is ridiculous FUD.\n\n\u003e With LOT=False in the picture, however, things can get messy:\n\nLOT=false is always in the picture if we are talking about a soft-fork:\nthe defining feature of a soft-fork is that old node software continues\nto work, and old node software will be entirely indifferent to whether\nactivation is signalled or not.\n\n\u003e some users will \n\u003e enforce Taproot(eg) (those running LOT=True), while others will not (those \n\u003e with LOT=False)\n\nIf you are following bip8 with lockinontimeout=false, you will enforce\ntaproot rules if activation occurs, you will simply not reject blocks if\nactivation does not occur.\n\n\u003e Users with LOT=True will still get all the safety thereof, \n\u003e but those with LOT=False will (in the event of miners deciding to produce a \n\u003e chain split) face an unreliable chain, being replaced by the LOT=True chain \n\u003e every time it overtakes the LOT=False chain in work.\n\nThis assumes anyone mining the chain where taproot does not activate is\nnot able to avoid a reorg, despite having majority hashpower (as implied\nby the lot=true chain having to overtake them repeatedly). That's absurd;\navoiding a reorg is trivially achieved via running \"invalidateblock\", or\nvia pool software examining block headers, or via a patch along the lines\nof MUST_SIGNAL enforcement, but doing the opposite. For concreteness,\nhere's a sketch of such a patch:\n\nhttps://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f\n\n\u003e For 2 weeks, users with LOT=False would not have a usable network.\n\nThat's also ridiculous FUD.\n\nIf it were true, it would mean the activation mechanism was not\nacceptable, as non-upgraded nodes would also not have a usable network\nfor the same reason.\n\nFortunately, it's not true.\n\nMore generally, if miners are willing to lose significant amounts of\nmoney mining orphan blocks, they can do that at any time. If they're\nnot inclined to do so, it's incredibly straightforward for them to avoid\ndoing so, whatever a minority of other miners might do.\n\n\u003e The overall risk is maximally reduced by LOT=True being the only deployed \n\u003e parameter, and any introduction of LOT=False only increases risk probability \n\u003e and severity.\n\nLOT=false is the default behaviour of everything single piece of node\nsoftware out there. That behaviour doesn't need to be introduced, it's\nalready universal.\n\nCheers,\naj"}