BIP 8: Add minimum activation height #1080

achow101 commented at 10:21 PM on March 8, 2021: member

The Speedy Trial activation proposal introduces a new parameter named minimum_activation_height. This PR adds that to BIP 8 so that such Speedy Trials can be implemented using entirely BIP 8.

achow101 cross-referenced this on Mar 8, 2021 from issue BIP 341: Specify Speedy Trial activation parameters by achow101

achow101 renamed this:
~~Add minimum activation height to BIP 8~~
BIP 8: Add minimum activation height
on Mar 8, 2021

in bip-0008.mediawiki:54 in 6bbe2ebf98 outdated

  50 | @@ -50,12 +51,13 @@ The following guidelines are suggested for selecting these parameters for a soft
  51 |  # '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity.
  52 |  # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
  53 |  # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
  54 | +# '''minimum_activation_height''' should be set to several retarget periods in the future if the startheight is to be very soon after a release. This allows more time to be spent in the locked in state so that nodes can upgrade. For a typical soft fork, this may be set to 0 to have the locked in state be the traditional single retarget period.

michaelfolkson commented at 12:14 PM on March 14, 2021:

The minimum_activation_height is added primarily (imo) because the timeoutheight is short for Speedy Trial rather than because the startheight is soon after a release (though this is also true in Speedy Trial and also a factor). We would still want minimum_activation_height even if the startheight wasn't soon after a release.

michaelfolkson commented at 12:16 PM on March 14, 2021:

nit: Prefer consistency across the BIP so that "LOCKED_IN" is used instead of "locked in". Two examples of "locked in" here.

achow101 commented at 5:59 PM on March 14, 2021:

My understanding is that having a longer locked in period is so that the startheight can be sooner. It allows for the upgrade time to be moved from before the start height to after locked in. Perhaps @roconnor-blockstream or @harding could comment on this.

achow101 commented at 6:04 PM on March 14, 2021:

Done

achow101 commented at 6:05 PM on March 14, 2021:

Done

roconnor-blockstream commented at 5:06 PM on March 15, 2021:

acho101 is correct. I think under previous considerations a short activation would have it's start date delayed to give time for nodes to update. Instead ST uses a miniumum_activation_height to allow for a start date soon after release while still giving time for nodes up to update.

michaelfolkson commented at 12:18 PM on March 14, 2021: contributor

A couple of nits but generally this looks good. Additional mega nit (!) that the font looks different (weird because it is still Arial) on the state transition diagram but its fine.

Directly below the state transition diagram it still says "Note that when lockinontimeout is true, the LOCKED_IN state will be reached no later than at a height of timeoutheight, and ACTIVE will be reached no later than at a height of timeoutheight + 2016."

This needs to be changed so that it says "ACTIVE will be reached no later than at the minimum_activation_height".

minimum_activation_height still applies even when lockinontimeout is true.

achow101 force-pushed on Mar 14, 2021

achow101 commented at 6:05 PM on March 14, 2021: member

Directly below the state transition diagram it still says "Note that when lockinontimeout is true, the LOCKED_IN state will be reached no later than at a height of timeoutheight, and ACTIVE will be reached no later than at a height of timeoutheight + 2016."

This needs to be changed so that it says "ACTIVE will be reached no later than at the minimum_activation_height".

minimum_activation_height still applies even when lockinontimeout is true.

Changed to "no earlier than minimum_activation_height". Also added a sentence to discuss the situation where the minimum activation height is less than the timeoutheight + 2016.

in bip-0008.mediawiki:54 in 58d629b256 outdated

  50 | @@ -50,12 +51,13 @@ The following guidelines are suggested for selecting these parameters for a soft
  51 |  # '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity.
  52 |  # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
  53 |  # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
  54 | +# '''minimum_activation_height''' should be set to several retarget periods in the future if the startheight is to be very soon after a release. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. For a typical soft fork, this may be set to 0 to have the LOCKED_IN state be the traditional single retarget period.

luke-jr commented at 8:06 PM on March 15, 2021:

The recommendation for startheight should probably also be updated.

achow101 commented at 10:51 PM on March 15, 2021:

Done.

in bip-0008.mediawiki:100 in 58d629b256 outdated

  94 | @@ -93,7 +95,8 @@ During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget
  95 |  
  96 |  <img src="bip-0008/states.png" align="middle"></img>
  97 |  
  98 | -Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''.
  99 | +Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no earlier than at a height of '''minimum_activation_height'''.
 100 | +When '''minimum_activation_height''' is less than or equal to '''timeoutheight + 2016''', ACTIVE will be reached no later than '''timeoutheight + 2016'''.

luke-jr commented at 8:08 PM on March 15, 2021:

The changes here aren't specific to LOT=True, but the phrasing suggests they could be.

achow101 commented at 10:51 PM on March 15, 2021:

Done.

luke-jr changes_requested

luke-jr added the label Proposed BIP modification on Mar 15, 2021

luke-jr assigned luke-jr on Mar 15, 2021

achow101 force-pushed on Mar 15, 2021

in bip-0008.mediawiki:100 in 4ff7f95831 outdated

  94 | @@ -93,7 +95,9 @@ During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget
  95 |  
  96 |  <img src="bip-0008/states.png" align="middle"></img>
  97 |  
  98 | -Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''.
  99 | +Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''.
 100 | +Regardless of value of '''lockinontimeout''', ACTIVE will be reached no earlier than at a height of '''minimum_activation_height'''.
 101 | +When '''minimum_activation_height''' is less than or equal to '''timeoutheight + 2016''', ACTIVE will be reached no later than '''timeoutheight + 2016'''.

jonasnick commented at 3:45 PM on March 16, 2021:

nit: probably (slightly) easier to understand if this wasn't special cased and instead a note would be added to the parameter selection guidelines that minimum_activation _height must be at least timeoutheight + 2016. Then you could also remove the After at least one retarget period of LOCKED_IN [...] and change the sentence to something like "From the LOCKED_IN state we transition to ACTIVE if the minimum activation height is reached."

jonasnick commented at 3:51 PM on March 16, 2021:

Afaics right now the diagram isn't correct, because if minimum_activation_height = 0 then it looks like LOCKED_IN -> ACTIVE happens without a retarget period. So should either make minimum_activation_height >= timeoutheight + 2016 or change arrow in diagram to height >= max(timeoutheight + 2016, minimum_activation_height).

achow101 commented at 4:00 PM on March 16, 2021:

minimum_activation_height can't be at least timeoutheight + 2016 as otherwise the normal deployment won't activate one retarget period after LOCKED_IN.

jonasnick commented at 4:08 PM on March 16, 2021:

Of course, nevermind. In that case the diagram isn't made worse by this PR.

roconnor-blockstream commented at 4:09 PM on March 16, 2021:

FWIW, I personally intended that a min-activation-height that is less than timeoutheight + 2016 would be allowed in general. That said, my personal intentions may not be all that relevant.

luke-jr commented at 6:08 PM on March 16, 2021:

I don't understand what this is trying to say. With LOT=False, ACTIVE might never be reached at all...

achow101 commented at 6:38 PM on March 16, 2021:

Clarified that this is after LOCKED_IN is reached.

ajtowns commented at 7:59 AM on March 19, 2021:

@jonasnick "it looks like LOCKED_IN -> ACTIVE happens without a retarget period" -- if that were going to happen, there'd be an arrow from "STARTED -> ACTIVE" without going through "LOCKED_IN" -- if you enter a state you're there for a retarget period, and you get to follow one of the arrows (maybe just the loop back and stay in the same state) when you hit the next retarget period.

jonasnick commented at 3:52 PM on March 16, 2021: contributor

Concept ACK

jonasnick commented at 4:09 PM on March 16, 2021: contributor

ACK

achow101 force-pushed on Mar 16, 2021

michaelfolkson commented at 4:28 PM on March 17, 2021: contributor

ACK

in bip-0008.mediawiki:54 in 34a4be1832 outdated

47 | @@ -47,15 +48,16 @@ The following guidelines are suggested for selecting these parameters for a soft
48 |
49 | # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
50 | # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
51 | -# '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity.
52 | +# '''startheight''' should be set to some block height in the future. It should be rounded up to the next height which begins a retarget period for simplicity. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after the expected software release. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.
53 | # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
54 | # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
55 | +# '''minimum_activation_height''' should be set to several retarget periods in the future if the startheight is to be very soon after a release. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. For a typical soft fork, this may be set to 0 to have the LOCKED_IN state be the traditional single retarget period.

ajtowns commented at 7:42 AM on March 19, 2021:

Add triple-quotes around "startheight" for consistency?

achow101 commented at 3:51 PM on March 19, 2021:

Done

in bip-0008.mediawiki:100 in 34a4be1832 outdated

  94 | @@ -93,7 +95,9 @@ During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget
  95 |  
  96 |  <img src="bip-0008/states.png" align="middle"></img>
  97 |  
  98 | -Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''.
  99 | +Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''.
 100 | +Regardless of value of '''lockinontimeout''', once LOCKED_IN, ACTIVE will be reached no earlier than at a height of '''minimum_activation_height'''.
 101 | +When '''minimum_activation_height''' is less than or equal to '''timeoutheight + 2016''', once LOCKED_IN, ACTIVE will be reached no later than '''timeoutheight + 2016'''.

ajtowns commented at 7:47 AM on March 19, 2021:

"If LOCKED_IN is reached, the ACTIVE state will be reached either precisely 2016 blocks (one retarget period) later or at minimum_activation_height, whichever comes later." ?

achow101 commented at 3:51 PM on March 19, 2021:

Done

in bip-0008/states.dot:10 in 34a4be1832 outdated

   6 | @@ -7,7 +7,7 @@ digraph {
   7 |    "DEFINED" -> "STARTED" [label="height >= start_height"];
   8 |    "STARTED" -> "MUST_SIGNAL" [label="height + 2016 >= timeoutheight AND lockinontimeout"];
   9 |    "STARTED" -> "FAILED" [label="height >= timeoutheight\nAND\nNOT lockinontimeout"];
  10 | -  "LOCKED_IN" -> "ACTIVE" [label="always"];
  11 | +  "LOCKED_IN" -> "ACTIVE" [label="height >= minimum_activation_height"];

ajtowns commented at 7:52 AM on March 19, 2021:

Should be a "LOCKED_IN":se -> "LOCKED_IN":ne; loop edge since it can stay in LOCKED_IN for multiple periods now.

achow101 commented at 3:52 PM on March 19, 2021:

I've added the loop edge

achow101 force-pushed on Mar 19, 2021

Sjors commented at 2:50 PM on March 20, 2021: member

ACK e86fd7c

in bip-0008.mediawiki:51 in e86fd7c3d7 outdated

47 | @@ -47,15 +48,16 @@ The following guidelines are suggested for selecting these parameters for a soft
48 |
49 | # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
50 | # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
51 | -# '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity.
52 | +# '''startheight''' should be set to some block height in the future. It should be rounded up to the next height which begins a retarget period for simplicity. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after the expected software release. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.

luke-jr commented at 6:33 PM on March 20, 2021:

"expected software release" assumes there is only one software that needs to support softforks...

achow101 commented at 7:04 PM on March 20, 2021:

Changed to be more generic.

in bip-0008.mediawiki:54 in e86fd7c3d7 outdated

47 | @@ -47,15 +48,16 @@ The following guidelines are suggested for selecting these parameters for a soft
48 |
49 | # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
50 | # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
51 | -# '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity.
52 | +# '''startheight''' should be set to some block height in the future. It should be rounded up to the next height which begins a retarget period for simplicity. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after the expected software release. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.
53 | # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
54 | # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
55 | +# '''minimum_activation_height''' should be set to several retarget periods in the future if the '''startheight''' is to be very soon after a release. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. For a typical soft fork, this may be set to 0 to have the LOCKED_IN state be the traditional single retarget period.

luke-jr commented at 6:34 PM on March 20, 2021:

I'm not sure it makes sense to talk about a "typical" or "traditional" style here. With this new param added, it may become more common to always startheight early and simply use min activation as the norm, even if it occurs before timeoutheight.

luke-jr commented at 6:34 PM on March 20, 2021:

Probably should repeat the expectation of economic majority having upgraded here.

achow101 commented at 7:04 PM on March 20, 2021:

Removed that wording.

achow101 commented at 7:04 PM on March 20, 2021:

Done

luke-jr changes_requested

Add minimum activation height to BIP 8 54fe11608c

achow101 force-pushed on Mar 20, 2021

luke-jr merged this on Mar 20, 2021

luke-jr closed this on Mar 20, 2021