📅 Original date posted:2021-04-06
📝 Original message:On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor <roconnor at blockstream.com>
wrote:
> On Tue, Apr 6, 2021 at 12:23 PM David A. Harding <dave at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/f713f795/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 22:51:13
in reply to nevent1q…m2xx
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 22:51:13Event JSON
{
"id": "e0215a6fbf8313d8ffcf029dad839aedb4632d3acded42300a3cde53b5a64454",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686178273,
"kind": 1,
"tags": [
[
"e",
"4a8fcc2e5a5f072bf4f8d2fa9f35b98817e71c0fecb9f6b8569b3021d902f19c",
"",
"root"
],
[
"e",
"7a6946342a511ff123f1fe5ae9456c241342e144e16971ddd9e00c5bdc3feaee",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2021-04-06\n📝 Original message:On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor \u003croconnor at blockstream.com\u003e\nwrote:\n\n\u003e On Tue, Apr 6, 2021 at 12:23 PM David A. Harding \u003cdave at dtrt.org\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e You need to upgrade by $( date -d \"$MIN_LOCKIN_TIME + 11 days\" )\n\u003e\u003e\n\u003e\u003e Ten minute estimators can say:\n\u003e\u003e\n\u003e\u003e You need to upgrade by $( date -d \"$MIN_LOCKIN_TIME + $((10 * 2016))\n\u003e\u003e minutes\" )\n\u003e\u003e\n\u003e\u003e And nine minute estimators can say:\n\u003e\u003e\n\u003e\u003e You need to upgrade by $( date -d \"$MIN_LOCKIN_TIME + $((9 * 2016))\n\u003e\u003e minutes\" )\n\u003e\u003e\n\u003e\n\u003e It isn't \"$MIN_LOCKIN_TIME + $((10 * 2016)) minutes\". It's\n\u003e \"$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))\n\u003e minutes\".\n\u003e\n\nNot only that, but the \"time_until_next_retargeting_period\" is a variable\nwhose distribution could straddle between 0 days and 14 days should the\nMIN_LOCKIN_TIME end up close to a retargeting boundary. MTP risks having a\npersistent two week error in estimating the activation time (which is the\ntime that nodes need to strive to be upgraded) which may not be resolved\nuntil only two weeks prior to activation! If MIN_LOCKIN_TIME ends up close\nto a retargeting boundary, then the MTP estimate becomes bimodal and\nprovides much worse estimates than provided by height based activation,\njust as we are approaching the important 4 weeks (or is it 2 weeks?) prior\nto activation!\n\nCompare this with height based activation which simply becomes more and\nmore accurate in its estimation consistently (until, at less than two weeks\nprior to activation, the height based estimate and the corresponding MTP\nestimate have identical distributions because they both become height based\nat that point in time.) This works out nicely because of the overall\nsimpler and easier to reason about design of height based activation.\n\nThe short of it is that MTP LOCKIN only really guarantees a minimum 2 week\nnotice prior to activation, which is largely the purpose of that LOCKIN\nperiod. Whereas height based activation gives an estimate whose\ndistribution smoothly and continuously becomes more and more accurate as\nactivation approaches, with no abrupt changes in estimates.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/f713f795/attachment.html\u003e",
"sig": "e976de9d4e4eb2be3f2e273ca378aa7bafc6bc63b1118b5bb4745da281df2d8be96450894bd2c169466aa8f2d3bb268cd91681f7704bdc77ece291227f54988c"
}