From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0F236C000A for ; Tue, 6 Apr 2021 16:23:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id F1F7860683 for ; Tue, 6 Apr 2021 16:23:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 3.935 X-Spam-Level: *** X-Spam-Status: No, score=3.935 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dtrt.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy7BlzZjJmK4 for ; Tue, 6 Apr 2021 16:23:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from newmail.dtrt.org (newmail.dtrt.org [IPv6:2600:3c03::f03c:91ff:fe7b:78d1]) by smtp3.osuosl.org (Postfix) with ESMTPS id 16CBE605EA for ; Tue, 6 Apr 2021 16:23:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org; s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Mc6i04U/1wJE2fGNDnm5pPqKHgumOeJhHith0ReCEyw=; b=8EvQQGWjs7eaHZBXkYPiULD7vH sfBeIuig6ZBvvka7sImB66urRgInEoupmdXAfa1lxrVdj3mnh/AAsolGIYQhZTnX3YadQzAatTA0I 3h5W+jqJa3QUXl3egDsS3KFZnwfYRlm0OhvEYi8vlZOkMGvb3mvF7UCHjEi8vjpmdBAM=; Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1lToUF-0000Hk-69; Tue, 06 Apr 2021 06:23:31 -1000 Date: Tue, 6 Apr 2021 06:22:16 -1000 From: "David A. Harding" To: Russell O'Connor , Bitcoin Protocol Discussion Message-ID: <20210406162216.k34aplxwznh5z25v@ganymede> References: <20210405103452.GA15866@erisian.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q5p2z2ruzm6bp4fd" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Cc: Anthony Towns Subject: Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 16:23:34 -0000 --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--