On Tue, Mar 02, 2021 at 01:06:14AM +1000, 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.
You cannot prove a statement to be false by making another statement. > > > 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. That is an analogy not FUD. A strong one nevertheless but still an analogy. > > > 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. > That is the correct description of how soft-forks should work in principle. > > 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. Also correct in principle. > > 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 If lot=true has majority of hashpower it wins. Having to overtake them repeatedly assumes a 50/50 split one chain taking over the other repeatedly. In which case OP's statement that the LOT=True chain is safer holds true. > > > For 2 weeks, users with LOT=False would not have a usable network. > > That's also ridiculous FUD. In context thats not FUD and most certainly it's not ridiculous FUD. Assuming a 50/50 hashpower split the Lot=False chain has no stability till difficulty re-adjustment. > > 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. In the split scenario non-upgraded nodes don't play, right? aka they're part of both chains. > > 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. Except that when incentives change so does miner behavior. > > > 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. You are again making an "in principle" statement. > > Cheers, > aj If you meant this to be a rebuttal, it is not. It is mostly blanket statements and attacking OP. -- _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
