David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-06 📝 Original message:On Tue, Apr 06, 2021 at ...
📅 Original date posted:2021-04-06
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/e48fbe57/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/e48fbe57/attachment.sig>;