Date: Tue, 6 Apr 2021 06:22:16 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Russell O'Connor <roconnor@blockstream.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210406162216.k34aplxwznh5z25v@ganymede>
References: <CAD5xwhgTKLhA82=PsF9EXrhvmx6zcA=ffOvHD4qt4q1sAqzhng@mail.gmail.com>
 <20210405103452.GA15866@erisian.com.au>
 <CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="q5p2z2ruzm6bp4fd"
Content-Disposition: inline
In-Reply-To: <CAMZUoKk39YNFVgGQ2krFSx4GNHN0rO_M2j91ETMGSO01SHYEcw@mail.gmail.com>
User-Agent: NeoMutt/20180716
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th
 19:00 UTC bitcoin/bitcoin-dev
Precedence: list


--q5p2z2ruzm6bp4fd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--q5p2z2ruzm6bp4fd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmBsirgACgkQ2dtBqWwi
adPnaxAAuu4ityAei5sA2tjkOe9Tuil+6YVnEEA6KNoGKK25kHMec9LYqhTh7M4A
FxSSE+N/qBTMgMgh/oWtFYvx74mKh2eL6r6ApJ+PSodJVXENwNK/v9ILOheg6uOr
wftz8SIuu+06XzNGeA525muYz1RCiA2xbd+eU3OfuUdnKm5or3IXUvDFDAbft3Kd
wuG06UR2PBLs9pzwMwp/2gy+q/dGTxpSfGmh7nePyDzrzPJHXTsehWr/vsSh8xom
H2eosmylAaQtZpBn/qf5D2HrKl5TE+L2IY+rBEpQNLUdJKprFkUSYBSHqK85JNXy
QJfItwCxlgZh9Y61ZaCPbg2eiutA8pm2GcNsR/L6C2MbqhgNf1xMPtBEeEyoElmY
UMdKUVYPW/t1Hijq1Cl1JZm6SsPUIADgC+XOt6LHNZ25LG+n8D115FwGpZXPiB9g
nokIzlaQCkPjwc5OG61vBLaDNVcRxyWf/BKM/NVDWEwwcPZbvL9FWUTu0qQEACYq
Fj/9DNT5IfpWswMO1Nj40bNLbJum+29Yia97tYGJ/IYeCCgFsvhigSz1dVyE4gw2
bsvkMA+wCXC7e1xRoVNjcyIVC17NZRx6+fHtq0hDWACc3gWyx6/VdouVJR1zKQ25
g7L28yvbqwg45QA9Hio/AMoMZTxIbOx4iqrlPIhzqq4PELkJEns=
=EkLA
-----END PGP SIGNATURE-----

--q5p2z2ruzm6bp4fd--