Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 67484C000A for ; Tue, 6 Apr 2021 17:18:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 55C1660B92 for ; Tue, 6 Apr 2021 17:18:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=blockstream-com.20150623.gappssmtp.com 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 pH5zVrLQhhpw for ; Tue, 6 Apr 2021 17:18:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by smtp3.osuosl.org (Postfix) with ESMTPS id 6837560B80 for ; Tue, 6 Apr 2021 17:18:11 +0000 (UTC) Received: by mail-qk1-x734.google.com with SMTP id x11so15688832qkp.11 for ; Tue, 06 Apr 2021 10:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KtcA3ZaMot2+8y1FXf+GulKqwiFo9294tW0+XrJrtVw=; b=tz7ZcTiW7HmK3u3e70qMMdk4Na5lZnPsrlKczxkFhfc0yeaeR7k6DX06nE9XITbQt8 I9nV51pWbx4BVME7qTTjUqu7wFwdbOpXdFT1tRICsxg3jBTuNxS0x1Uvl2hpqAQLazkX uMIyX7iDyyal1OEG486HlfdrDlUcebZp1EBGHTRRcFF9qyKvApyTnbT7ciseRpp/7gHA HviS0Sveq+wOJa4Z+VSIJyVdnW/82dnSSzN2MYaeXYeYPYCknpiyBRKpetLlfLUj34f8 7YvS/+KoTW+N1gXyN6uCo5KqUfYZTV1VwIsuxTusDddlYtH0srq99RGoUAWaafK+TLUx fAEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KtcA3ZaMot2+8y1FXf+GulKqwiFo9294tW0+XrJrtVw=; b=MzQUIwlbqyF/KZoS7CHEyhu9aWLpBmQE+aYodhOJjs1WVyiX2yeFvPQ/SyyyfcgTTp V+O3UuriXuoTAmu/6v8io88FIxT80OCY7b3ILxPO1cNUK5LVaInAvZiDyWMEP2nWCtBN 5PSAaotbtecLG2ji2B8mSbq01Qpg7V73U5NvzOTWHsFYMi294EodwCC+d+EUoBPoABd3 I8xo9MSQ5XBm4b7x2P66RAiLnM9Erc6l5ZG46lIrxmPRp4tWouVsYym3RWQgVZALODNf lXSTQl1Hkcb/ac3bDRJd2vEZsewYO0C1RtpFAN+r4ttj8SIAu9Bh30eVjESJVz46oezt RfOQ== X-Gm-Message-State: AOAM532bTcnEhAccUl+E4acEkpaI2CwkiPQVqttIpn7quxWDObZo0h/c vyu/7nS19V8Lz6FZO0VZOxtuBaiEFiN3+xakCC20kg== X-Google-Smtp-Source: ABdhPJwJD51bzw9yi7EsjIvnBUEAfAu+IOlBOp+OBwNOelK8jLLMASCDnoR9y3fpUiQUABsVFYnoETvwyxj9fdOTIpQ= X-Received: by 2002:a37:ad0a:: with SMTP id f10mr15065831qkm.384.1617729490145; Tue, 06 Apr 2021 10:18:10 -0700 (PDT) MIME-Version: 1.0 References: <20210405103452.GA15866@erisian.com.au> <20210406162216.k34aplxwznh5z25v@ganymede> In-Reply-To: From: "Russell O'Connor" Date: Tue, 6 Apr 2021 13:17:58 -0400 Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="0000000000009a65e305bf50ffcd" Cc: Bitcoin Protocol Discussion , 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 17:18:12 -0000 --0000000000009a65e305bf50ffcd Content-Type: text/plain; charset="UTF-8" On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor wrote: > On Tue, Apr 6, 2021 at 12:23 PM David A. Harding 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. --0000000000009a65e305bf50ffcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor <roconnor@blockstream.com> wrote:
<= div class=3D"gmail_quote">
On Tue, Apr= 6, 2021 at 12:23 PM David A. Harding <dave@dtrt.org> wrote:

=C2=A0 You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days&q= uot; )

Ten minute estimators can say:

=C2=A0 You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2= 016)) minutes" )

And nine minute estimators can say:

=C2=A0 You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 20= 16)) minutes" )

It isn't=C2=A0 "$MIN_LOCKIN_TIME = + $((10 * 2016)) minutes". It's "$MIN_LOCKIN_TIME + time unti= l next retargeting period=C2=A0+ $((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.=C2=A0 MTP risks having a persistent two week er= ror 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 prio= r to activation!=C2=A0 If MIN_LOCKIN_TIME ends up close to a retargeting bo= undary, then the MTP estimate becomes bimodal and provides much worse estim= ates than provided by height based activation, just as we are approaching t= he important 4 weeks (or is it 2 weeks?) prior to activation!

Compare this wi= th height based activation which simply becomes more and more accurate in i= ts estimation consistently (until, at less than two weeks prior to activati= on, the height based estimate and the corresponding MTP estimate have ident= ical distributions because they both become height based at that point in t= ime.) This works out nicely because of the overall simpler and easier to re= ason about design of height based activation.

The short of it is that MTP LOC= KIN only really guarantees a minimum 2 week notice prior to activation, whi= ch is largely the purpose of that LOCKIN period.=C2=A0 Whereas height based= activation gives an estimate whose distribution smoothly and continuously = becomes more and more accurate as activation approaches, with no abrupt cha= nges in estimates.
--0000000000009a65e305bf50ffcd--