On Tue, Apr 06, 2021 at 10:34:57AM -0400, Russell O'Connor via bitcoin-dev wrote: > The other relevant value of giving enough time for users to upgrade is not > very sensitive. It's not like 180 days is magic number that going over is > safe and going below is unsafe.
I don't think it's the 180 days value that's important but the deadline to upgrade before taproot activates. With heights, some people will be conservative and say: You need to upgrade by $( date -d "66 days" ) Some people will just assume 10 minutes and say: You need to upgrade by $( date -d "$((10 * 2016 * 13)) minutes" ) Some people might assume 9 minutes, which I think is roughly our historic average: You need to upgrade by $( date -d "$((9 * 2016 * 13)) minutes" ) As a few weeks pass and the number of blocks left until activation decreases, it's likely everyone will be saying slightly different dates. Basically, it'll be like a few months before the recent halving where you could go to different sites that would give you wildly different estimates---several of them claiming to be better than the others because they factored in ____. We're stuck with that for halvings, but I think coordinating human actions around heights creates unnecessary confusion. Using Towns's updated MTP doesn't eliminate this problem, but it reduces it significantly, especially early in the process. Now conservative estimators can say: You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" ) Ten minute estimators can say: You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes" ) And nine minute estimators can say: You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 2016)) minutes" ) Those predictions are unlikely to change until shortly before the lockin period. I think those dates being much closer together (within 3 days) and static for several months makes it much easier to communicate to users (including organizations) the date by which they should upgrade if they want to help enforce the soft fork's new rules. As a side advantage, it also makes it easier to plan activation parties, which is something I think we'll especially want after we finally start doing something useful with the bikeshed we repainted so many times. :-) -Dave
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
