📅 Original date posted:2021-04-06
📝 Original message:I'm pretty sure that the question of "is signalling still possible by the
time enough miners have upgraded and are ready to start signalling?"
Strongly benefits from a guaranteed number of signaling periods that height
based activation offers. Especially for the short activation period of
Speedy Trial.
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.
That said, as Jeremy has pointed out before (maybe it was on IRC), we can
almost ensure a minimum of 7 retargeting periods by carefully selecting
signaling start and end dates to line up in the middle of expected
retargeting periods that we would otherwise chose with height based
activation. Why we would rather use MTP to fake a height based activation,
I will never understand. But if this is what it takes to activate taproot,
that is fine by me.
The differences between height and MTP activation are too small to matter
that much for what is ultimately transient code. As long as MTP activation
can pass code review it is okay with me.
On Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:
> > As such, the main conversation in this agenda item is
> > around the pros/cons of height or MTP and determining if we can reach
> consensus
> > on either approach.
>
> Here's some numbers.
>
> Given a desired signalling period of xxx days, where signaling begins
> on the first retarget boundary after the starttime and ends on the last
> retarget boundary before the endtime, this is how many retarget periods
> you get (based on blocks since 2015-01-01):
>
> 90 days: mainnet 5-7 full 2016-block retarget periods
> 180 days: mainnet 11-14
> 365 days: mainnet 25-27
> 730 days: mainnet 51-55
>
> (This applies to non-signalling periods like the activation/lock in delay
> too of course. If you change it so that it ends at the first retarget
> period after endtime, all the values just get incremented -- ie, 6-8,
> 12-15 etc)
>
> If I've got the maths right, then requiring 1814 of 2016 blocks to signal,
> means that having 7 periods instead of 5 lets you get a 50% chance of
> successful activation by maintaining 89.04% of hashpower over the entire
> period instead of 89.17%, while 55 periods instead of 51 gives you a 50%
> chance of success with 88.38% hashpower instead of 88.40% hashpower.
> So the "repeated trials" part doesn't look like it has any significant
> effect on mainnet.
>
> If you target yy periods instead of xxx days, starting and ending on a
> retarget boundary, you get the following stats from the last few years
> of mainnet (again starting at 2015-01-01):
>
> 1 period: mainnet 11-17 days (range 5.2 days)
> 7 periods: mainnet 87-103 days (range 15.4 days)
> 13 periods: mainnet 166-185 days (range 17.9 days)
> 27 periods: mainnet 352-377 days (range 24.4 days)
> 54 periods: mainnet 711-747 days (range 35.0 days)
>
> As far as I can see the questions that matter are:
>
> * is signalling still possible by the time enough miners have upgraded
> and are ready to start signalling?
>
> * have nodes upgraded to enforce the new rules by the time activation
> occurs, if it occurs?
>
> But both those benefit from less real time variance, rather than less
> variance in the numbers of signalling periods, at least in every way
> that I can think of.
>
> Corresponding numbers for testnet:
>
> 90 days: testnet 5-85
> 180 days: testnet 23-131
> 365 days: testnet 70-224
> 730 days: testnet 176-390
>
> (A 50% chance of activating within 5 periods requires sustaining 89.18%
> hashpower; within 85 periods, 88.26% hashpower; far smaller differences
> with all the other ranges -- of course, presumably the only way the
> higher block rates ever actually happen is by someone pointing an ASIC at
> testnet, and thus controlling 100% of blocks for multiple periods anyway)
>
> 1 period: testnet 5.6minutes-26 days (range 26.5 days)
> 13 periods: testnet 1-135 days (range 133.5 days)
> 27 periods: testnet 13-192 days (range 178.3 days)
> 54 periods: testnet 39-283 days (range 243.1 days)
> 100 periods: testnet 114-476 days (range 360.9 days)
> (this is the value used in [0] in order to ensure 3 months'
> worth of signalling is available)
> 132 periods: testnet 184-583 days (range 398.1 days)
> 225 periods: testnet 365-877 days (range 510.7 days)
> 390 periods: testnet 725-1403 days (range 677.1 days)
>
> [0] https://github.com/bitcoin/bips/pull/1081#pullrequestreview-621934640
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/1049635d/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:31:09
in reply to nevent1q…syd3
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:31:09Event JSON
{
"id": "e9febf4b5551f235a3ad3be40992717631eb32f5668d1983eb7fd19d71435d85",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686162669,
"kind": 1,
"tags": [
[
"e",
"250a34520fd2c710fbb83e8068109a35b34910ab3d5776f9be2d29bc995bbd45",
"",
"root"
],
[
"e",
"82b2bf073053a3cd8b943f95aab14602268b855c6990ceebba02fca2de68a3c3",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2021-04-06\n📝 Original message:I'm pretty sure that the question of \"is signalling still possible by the\ntime enough miners have upgraded and are ready to start signalling?\"\nStrongly benefits from a guaranteed number of signaling periods that height\nbased activation offers. Especially for the short activation period of\nSpeedy Trial.\n\nThe other relevant value of giving enough time for users to upgrade is not\nvery sensitive. It's not like 180 days is magic number that going over is\nsafe and going below is unsafe.\n\nThat said, as Jeremy has pointed out before (maybe it was on IRC), we can\nalmost ensure a minimum of 7 retargeting periods by carefully selecting\nsignaling start and end dates to line up in the middle of expected\nretargeting periods that we would otherwise chose with height based\nactivation. Why we would rather use MTP to fake a height based activation,\nI will never understand. But if this is what it takes to activate taproot,\nthat is fine by me.\n\nThe differences between height and MTP activation are too small to matter\nthat much for what is ultimately transient code. As long as MTP activation\ncan pass code review it is okay with me.\n\n\nOn Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:\n\u003e \u003e As such, the main conversation in this agenda item is\n\u003e \u003e around the pros/cons of height or MTP and determining if we can reach\n\u003e consensus\n\u003e \u003e on either approach.\n\u003e\n\u003e Here's some numbers.\n\u003e\n\u003e Given a desired signalling period of xxx days, where signaling begins\n\u003e on the first retarget boundary after the starttime and ends on the last\n\u003e retarget boundary before the endtime, this is how many retarget periods\n\u003e you get (based on blocks since 2015-01-01):\n\u003e\n\u003e 90 days: mainnet 5-7 full 2016-block retarget periods\n\u003e 180 days: mainnet 11-14\n\u003e 365 days: mainnet 25-27\n\u003e 730 days: mainnet 51-55\n\u003e\n\u003e (This applies to non-signalling periods like the activation/lock in delay\n\u003e too of course. If you change it so that it ends at the first retarget\n\u003e period after endtime, all the values just get incremented -- ie, 6-8,\n\u003e 12-15 etc)\n\u003e\n\u003e If I've got the maths right, then requiring 1814 of 2016 blocks to signal,\n\u003e means that having 7 periods instead of 5 lets you get a 50% chance of\n\u003e successful activation by maintaining 89.04% of hashpower over the entire\n\u003e period instead of 89.17%, while 55 periods instead of 51 gives you a 50%\n\u003e chance of success with 88.38% hashpower instead of 88.40% hashpower.\n\u003e So the \"repeated trials\" part doesn't look like it has any significant\n\u003e effect on mainnet.\n\u003e\n\u003e If you target yy periods instead of xxx days, starting and ending on a\n\u003e retarget boundary, you get the following stats from the last few years\n\u003e of mainnet (again starting at 2015-01-01):\n\u003e\n\u003e 1 period: mainnet 11-17 days (range 5.2 days)\n\u003e 7 periods: mainnet 87-103 days (range 15.4 days)\n\u003e 13 periods: mainnet 166-185 days (range 17.9 days)\n\u003e 27 periods: mainnet 352-377 days (range 24.4 days)\n\u003e 54 periods: mainnet 711-747 days (range 35.0 days)\n\u003e\n\u003e As far as I can see the questions that matter are:\n\u003e\n\u003e * is signalling still possible by the time enough miners have upgraded\n\u003e and are ready to start signalling?\n\u003e\n\u003e * have nodes upgraded to enforce the new rules by the time activation\n\u003e occurs, if it occurs?\n\u003e\n\u003e But both those benefit from less real time variance, rather than less\n\u003e variance in the numbers of signalling periods, at least in every way\n\u003e that I can think of.\n\u003e\n\u003e Corresponding numbers for testnet:\n\u003e\n\u003e 90 days: testnet 5-85\n\u003e 180 days: testnet 23-131\n\u003e 365 days: testnet 70-224\n\u003e 730 days: testnet 176-390\n\u003e\n\u003e (A 50% chance of activating within 5 periods requires sustaining 89.18%\n\u003e hashpower; within 85 periods, 88.26% hashpower; far smaller differences\n\u003e with all the other ranges -- of course, presumably the only way the\n\u003e higher block rates ever actually happen is by someone pointing an ASIC at\n\u003e testnet, and thus controlling 100% of blocks for multiple periods anyway)\n\u003e\n\u003e 1 period: testnet 5.6minutes-26 days (range 26.5 days)\n\u003e 13 periods: testnet 1-135 days (range 133.5 days)\n\u003e 27 periods: testnet 13-192 days (range 178.3 days)\n\u003e 54 periods: testnet 39-283 days (range 243.1 days)\n\u003e 100 periods: testnet 114-476 days (range 360.9 days)\n\u003e (this is the value used in [0] in order to ensure 3 months'\n\u003e worth of signalling is available)\n\u003e 132 periods: testnet 184-583 days (range 398.1 days)\n\u003e 225 periods: testnet 365-877 days (range 510.7 days)\n\u003e 390 periods: testnet 725-1403 days (range 677.1 days)\n\u003e\n\u003e [0] https://github.com/bitcoin/bips/pull/1081#pullrequestreview-621934640\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/1049635d/attachment.html\u003e",
"sig": "703113047503d87c8f9845e33102193febee3e8be63117a06c9efc0cc4d51747cfa66a85f1a225d560da32f95ca77b44a382d4b5a63fed18425d62a63bf4bf05"
}