{"type":"rich","version":"1.0","author_name":"npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29","author_url":"https://nostr.ae/npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-03-01\n📝 Original message:How about a compromise?\n\nWith LOT=false, taproot will be activated if at least 95% of the miners \nvote yes.\nWith LOT=true, taproot will be activated if at least 0% of the miners \nvote yes.\n...with LOT=maybe, taproot will be activated if at least ~some% of the \nminers vote yes?\n\nIf you want the 'emergency cancel' feature without binding yourself to \nit, couldn't you have some middle-of-the-road solution? \"Taproot will be \nenabled if miner support ever goes above 95%, or on flag day if miner \nsupport is \u003e20% then\". That would prevent obstreperous miners from doing \ntoo much damage, while still hopefully making it possible to bail out of \na disaster.\n\nOn 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:\n\u003e On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev \n\u003e wrote:\n\u003e\u003e As we saw in 2017 with BIP 9, coordinating activation by miner signal \n\u003e\u003e alone,\n\u003e\u003e despite its potential benefits, also leaves open the door to a miner \n\u003e\u003e veto.\n\u003e \n\u003e To the contrary, we saw in 2017 that miners could *not* successfully\n\u003e veto a BIP 9 activation. It was certainly more effort and risk than was\n\u003e desirable to override the attempted veto, but the attempt at vetoing\n\u003e nevertheless failed.\n\u003e \n\u003e\u003e It wouldn't be much different than adding back the inflation bug\n\u003e\u003e (CVE-2018-17144) and trusting miners not to exploit it.\n\u003e \n\u003e That is ridiculous FUD.\n\u003e \n\u003e\u003e With LOT=False in the picture, however, things can get messy:\n\u003e \n\u003e LOT=false is always in the picture if we are talking about a soft-fork:\n\u003e the defining feature of a soft-fork is that old node software continues\n\u003e to work, and old node software will be entirely indifferent to whether\n\u003e activation is signalled or not.\n\u003e \n\u003e\u003e some users will\n\u003e\u003e enforce Taproot(eg) (those running LOT=True), while others will not \n\u003e\u003e (those\n\u003e\u003e with LOT=False)\n\u003e \n\u003e If you are following bip8 with lockinontimeout=false, you will enforce\n\u003e taproot rules if activation occurs, you will simply not reject blocks \n\u003e if\n\u003e activation does not occur.\n\u003e \n\u003e\u003e Users with LOT=True will still get all the safety thereof,\n\u003e\u003e but those with LOT=False will (in the event of miners deciding to \n\u003e\u003e produce a\n\u003e\u003e chain split) face an unreliable chain, being replaced by the LOT=True \n\u003e\u003e chain\n\u003e\u003e every time it overtakes the LOT=False chain in work.\n\u003e \n\u003e This assumes anyone mining the chain where taproot does not activate is\n\u003e not able to avoid a reorg, despite having majority hashpower (as \n\u003e implied\n\u003e by the lot=true chain having to overtake them repeatedly). That's \n\u003e absurd;\n\u003e avoiding a reorg is trivially achieved via running \"invalidateblock\", \n\u003e or\n\u003e via pool software examining block headers, or via a patch along the \n\u003e lines\n\u003e of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,\n\u003e here's a sketch of such a patch:\n\u003e \n\u003e https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f\n\u003e \n\u003e\u003e For 2 weeks, users with LOT=False would not have a usable network.\n\u003e \n\u003e That's also ridiculous FUD.\n\u003e \n\u003e If it were true, it would mean the activation mechanism was not\n\u003e acceptable, as non-upgraded nodes would also not have a usable network\n\u003e for the same reason.\n\u003e \n\u003e Fortunately, it's not true.\n\u003e \n\u003e More generally, if miners are willing to lose significant amounts of\n\u003e money mining orphan blocks, they can do that at any time. If they're\n\u003e not inclined to do so, it's incredibly straightforward for them to \n\u003e avoid\n\u003e doing so, whatever a minority of other miners might do.\n\u003e \n\u003e\u003e The overall risk is maximally reduced by LOT=True being the only \n\u003e\u003e deployed\n\u003e\u003e parameter, and any introduction of LOT=False only increases risk \n\u003e\u003e probability\n\u003e\u003e and severity.\n\u003e \n\u003e LOT=false is the default behaviour of everything single piece of node\n\u003e software out there. That behaviour doesn't need to be introduced, it's\n\u003e already universal.\n\u003e \n\u003e Cheers,\n\u003e aj\n\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"}