Concept nack. This has no advantage over bip8(true). Bip9(false) is just bip9. Thr only reasonable argument against bip8(true) is "some people may do bip8(false) instead", which is a stypid argument applyable to any activation method.
People against taproot should want code to forbid its activation rather than limiting themselves to suport bip9/bip8(false) and hope it doesn't get activated it. Some other arguments seem to be based on the wrong assumption that miners should decide the rules. Thisproposal solves nothing, just adds to the noise and thus is really disappointing. On Sat, Mar 6, 2021, 12:33 Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote: > > On 3/3/21 09:59, Anthony Towns wrote: > > > A couple of days ago I would have disagreed with this; but with Luke > > > now strongly pushing against implementing lot=false, I can at least see > > > your point... > > Right. It may be the case that the minority group threatening to fork off > > onto a lot=true chain is not large enough to give a second thought to. > > However, I'm not certain that its worth the risk, and, as Chris noted in > his > > post this morning, that approach is likely to include more drama. > > I think there's two different interpretations of what a "user-activated > fork" means: > > 1) if people try to take bitcoin in a direction that risks destroying > it, it's possible to ignore both devs and hashpower entirely and force > a chain split to ensure it's possible to continue transacting with > "the real bitcoin". > > 2) removing miners' influence over consensus rules entirely -- so that > not only can users overcome miner objections by risking a chain split, > but so that miners don't have any greater ability to object than > anyone else in the ecosystem. > > In my opinion, bip8's optional lockinontimeout setting and must-signal > approach is well-designed for case 1; if miners object for good reasons, > then there is no need to override them (if there's a good reason not to do > something, it shouldn't be done!), while still having the possibility to > override them if they object for bad reasons. Because hashpower disagrees, > there's always a risk of a chain split in that case, so the additional > risk introduced by a signalling requirement is pretty minimal. That the > lockinontimeout value is a setting means it can be switched only when > we're sure there aren't good reasons for the objection. > > There is a lot of work to be done to make bitcoind have an acceptable > chance of gracefully *surviving* a network split introduced by this sort > of conflict; but provided no one started setting lockinontimeout=true > until we were six or so months into an activation attempt (and hence > had the opportunity to judge whether the reasons for not activating > were bad), that would likely be enough time to start implementing some > safety mechanisms. > > But there seems to be much more signficant support for the case 2 than I > expected; as evidenced by the "let's do lockinontimeout=true immediately" > advocacy, eg: > > I am not willing to go to war for Taproot. I'll be honest the reason > I'm interested at all is that devs I respect spent a lot of energy and > time on it and I was reluctant to let their marginally beneficial work > go to waste. > > I am, however, willing to go to war against LOT=False. > > -- https://twitter.com/francispouliot_/status/1363876292169465856 > > I don't think bip8 is well-designed for that approach: most importantly, > with early adoption of lockinontimeout=true, bip8 *encourages* a consensus > split in the event that good reasons for not activating are discovered > afterwards, because lockinontimeout=false nodes remain able to abandon > the activation attempt. Consensus splits are terrible; they should be > a last resort used only in the event that bitcoin's fundamental nature > is threatened, not a standard risk if bugs happened to be discovered > late. But additionally, if we are worried miners might not be acting > in the interests of all bitcoin users, there are other games they could > play, such as "if you want X activated quickly, also give us Y; otherwise > we'll delay it as long as possible". > > Losing the opportunity to abandon an activation attempt, by whatever > mechanism, also puts a lot more pressure on being absolutely sure of the > desirability of the change at the point when it's merged; because miners, > third-party devs, businesses, and users don't even have the option of > attempting to influence miners, all objections needs to be raised when > the activation parameters are merged, which raises the stakes for that > event substantially. > > I think my conclusions from that are: > > * as it stands, people are expecting to run bip8/lot=true nodes on the > network immediately; so deploying bip8/lot=false with compatible > parameters risks causing consensus splits, and should not be done > > * David Harding's "speedy trial" approach probably doesn't suffer from > the problems -- running a lot=true variant would require enforcing > signalling prior to the end of July, which is an unreasonable timeframe > to expect the majority of economic nodes to upgrade in; if bip9 is > used, then the risk of enforcement occuring with minority hashrate > (and thus having fewer retarget periods before the timeout is > reached) would also make a bip148/lot=true variant difficulty > > * if people want a "taproot is guaranteed to activate no later than X" > PR merged, someone needs to do a *lot* more outreach to be sure that > that's the right outcome, and it's not just devs/maintainers making > the call > > * IMO, Matt's proposed approach is both a better and simpler approach > to avoid giving miners undue influence on consensus; as such I've > drafted up a sample implementation: > > https://github.com/bitcoin/bitcoin/pull/21378 > > (Backporting it to 0.21 just requires backporting #19438, which is > straightforward) > > So I think that means my preference is to do the "speedy trial" with > signalling first, and if that fails, then either we've established there > are real problems with taproot and will go back to the drawing board to > fix them, or if we have not found problems by that time we should simply > switch to a straight flag day activation as Matt proposes. Presumably > we'll have established broard community consensus for activation if no > objections are discovered during the speedy trial. > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
