From: "Russell O'Connor" <roconnor@blockstream•com>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
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 13:17:58 -0400 [thread overview]
Message-ID: <CAMZUoKnjjhYbYABL+iw5VivQfKTn64vV0ereOtz5VFEb6g0xvw@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkxMudxUsOqA3varpjiqeVv+e-QD6RB8JzEfhjSMLJqeg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]
On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor <roconnor@blockstream•com>
wrote:
> On Tue, Apr 6, 2021 at 12:23 PM David A. Harding <dave@dtrt•org> 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.
[-- Attachment #2: Type: text/html, Size: 3015 bytes --]
next prev parent reply other threads:[~2021-04-06 17:18 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
2021-04-06 16:27 ` Russell O'Connor
2021-04-06 17:17 ` Russell O'Connor [this message]
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=CAMZUoKnjjhYbYABL+iw5VivQfKTn64vV0ereOtz5VFEb6g0xvw@mail.gmail.com \
--to=roconnor@blockstream$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/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