BIP 8 revisions: use height, secure locked-in signalling, and enable setting lockinontimeout later #550
Conversation
This partially reverts 7f6a0f8
|
Would also appreciate input from others, especially BIP 9 authors @sipa @petertodd @gmaxwell and @rustyrussell |
bip-0008.mediawiki
Outdated
| Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on | ||
| consensus rules. | ||
| Miners must continue setting the bit in LOCKED_IN phase so uptake is visible and acknowledged. | ||
| Blocks without the applicable bit set are invalid during this period. |
There was a problem hiding this comment.
No. This requires instant changes upon LOCKED_IN, which was never the intent. Miners with BIP9 didn't have to change anything for 2 weeks.
bip-0008.mediawiki
Outdated
| # '''starttime''' should be set to some date in the future, approximately one month after a software release date including the soft fork. This allows for some release delays, while preventing triggers as a result of parties running pre-release software. | ||
| # '''timeout''' should be 1 year (31536000 seconds) after starttime. | ||
| # '''start''' should be set to some block height in the future, approximately one month after a software release date including the soft fork. This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period. | ||
| # '''timeout''' should be approximately 1 year after start, and on a block which begins a retarget period. Therefore, '''start''' plus 52416. |
There was a problem hiding this comment.
I like the simplification, though we had this debate before with BIP9 and the conclusion went the other way. Historically, we create blocks 6% faster than the idealized number here, but that doesn't greatly interfere with either calculation.
bip-0008.mediawiki
Outdated
| @@ -180,6 +194,7 @@ https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits | |||
|
|
|||
| * The '''lockinontimeout''' flag is added. BIP 9 would only transition to the FAILED state when timeout was reached. | |||
| * Block heights are used for the deployment monotonic clock, rather than median-time-past. | |||
| * The last-ditch effort during a new FAILING state is added to allow '''lockinontimeout''' to be safely set after the initial deployment. | |||
There was a problem hiding this comment.
Clever, but too clever.
I would prefer to eliminate the lockinontimeout, as if it were always true. That avoids debate and horse-trading.
There was a problem hiding this comment.
lockinontimeout was always just an implementation detail, BIP8 is a separate specification but reusing BIP9 code for simplicity. I have written a height based version that doesnt require this implementation detail
| bits are 0 for the purposes of deployments. | ||
|
|
||
| Miners must continue setting the bit in LOCKED_IN phase so uptake is visible and acknowledged. | ||
| Blocks without the applicable bit set are invalid during this period. |
There was a problem hiding this comment.
In my understanding the LOCKED_IN phase is a grace period to allow for laggard miners to upgrade without immediately losing profits. This change is a regression in that regard.
|
ACK |
@shaolinfry