From: "David A. Harding" <dave@dtrt•org>
To: Russell O'Connor <roconnor@blockstream•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev
Date: Tue, 6 Apr 2021 06:22:16 -1000 [thread overview]
Message-ID: <20210406162216.k34aplxwznh5z25v@ganymede> (raw)
In-Reply-To: <CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-04-06 16:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-04 4:39 Jeremy
2021-04-04 9:31 ` Jorge Timón
2021-04-04 22:00 ` Robert Spigler
2021-04-05 10:34 ` Anthony Towns
2021-04-06 4:18 ` Jeremy
2021-04-06 14:34 ` Russell O'Connor
2021-04-06 14:51 ` Adam Back
2021-04-06 16:22 ` David A. Harding [this message]
2021-04-06 16:27 ` Russell O'Connor
2021-04-06 17:17 ` Russell O'Connor
2021-04-06 19:48 ` Anthony Towns
2021-04-06 21:31 ` David A. Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210406162216.k34aplxwznh5z25v@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox