BIP 8: Add minimum activation height #1080
Conversation
achow101
changed the title
There was a problem hiding this comment.
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.
bip-0008.mediawiki
Outdated
| @@ -50,12 +51,13 @@ The following guidelines are suggested for selecting these parameters for a soft | |||
| # '''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. | |||
| # '''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'''. | |||
| # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet. | |||
| # '''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. | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
achow101
force-pushed
the
bip8-more-params
branch
from
6bbe2eb
to
58d629b
Compare
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. |
achow101
force-pushed
the
bip8-more-params
branch
from
58d629b
to
4ff7f95
Compare
bip-0008.mediawiki
Outdated
| 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'''. | ||
| Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''. | ||
| Regardless of value of '''lockinontimeout''', ACTIVE will be reached no earlier than at a height of '''minimum_activation_height'''. | ||
| When '''minimum_activation_height''' is less than or equal to '''timeoutheight + 2016''', ACTIVE will be reached no later than '''timeoutheight + 2016'''. |
There was a problem hiding this comment.
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."
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
minimum_activation_height can't be at least timeoutheight + 2016 as otherwise the normal deployment won't activate one retarget period after LOCKED_IN.
There was a problem hiding this comment.
Of course, nevermind. In that case the diagram isn't made worse by this PR.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
achow101
force-pushed
the
bip8-more-params
branch
from
4ff7f95
to
34a4be1
Compare
|
ACK |
bip-0008.mediawiki
Outdated
| 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'''. | ||
| Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''. | ||
| Regardless of value of '''lockinontimeout''', ACTIVE will be reached no earlier than at a height of '''minimum_activation_height'''. | ||
| When '''minimum_activation_height''' is less than or equal to '''timeoutheight + 2016''', ACTIVE will be reached no later than '''timeoutheight + 2016'''. |
There was a problem hiding this comment.
@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.
achow101
force-pushed
the
bip8-more-params
branch
from
34a4be1
to
e86fd7c
Compare
|
ACK e86fd7c |
achow101
force-pushed
the
bip8-more-params
branch
from
e86fd7c
to
54fe116
Compare
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.