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