On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor <rocon...@blockstream.com> wrote:
> On Tue, Apr 6, 2021 at 12:23 PM David A. Harding <d...@dtrt.org> wrote: > >> >> 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" ) >> > > It isn't "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's > "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016)) > minutes". > Not only that, but the "time_until_next_retargeting_period" is a variable whose distribution could straddle between 0 days and 14 days should the MIN_LOCKIN_TIME end up close to a retargeting boundary. MTP risks having a persistent two week error in estimating the activation time (which is the time that nodes need to strive to be upgraded) which may not be resolved until only two weeks prior to activation! If MIN_LOCKIN_TIME ends up close to a retargeting boundary, then the MTP estimate becomes bimodal and provides much worse estimates than provided by height based activation, just as we are approaching the important 4 weeks (or is it 2 weeks?) prior to activation! Compare this with height based activation which simply becomes more and more accurate in its estimation consistently (until, at less than two weeks prior to activation, the height based estimate and the corresponding MTP estimate have identical distributions because they both become height based at that point in time.) This works out nicely because of the overall simpler and easier to reason about design of height based activation. The short of it is that MTP LOCKIN only really guarantees a minimum 2 week notice prior to activation, which is largely the purpose of that LOCKIN period. Whereas height based activation gives an estimate whose distribution smoothly and continuously becomes more and more accurate as activation approaches, with no abrupt changes in estimates.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
