BIP 8 revisions: use height, secure locked-in signalling, and enable setting lockinontimeout later #550

pull luke-jr wants to merge 5 commits into bitcoin:master from luke-jr:bip8_v3 changing 4 files +208 −11

luke-jr commented at 6:34 AM on June 25, 2017: member

@shaolinfry

BIP 8: Refactor back to wholly-contained spec

This partially reverts 7f6a0f811cf27ab6d77e499afc81b97d6d11ced2

750f5e59f6

BIP 8: Add a contrast section 17e158b3c3
luke-jr added the label Proposed BIP modification on Jun 25, 2017
luke-jr commented at 6:35 AM on June 25, 2017: member

Would also appreciate input from others, especially BIP 9 authors @sipa @petertodd @gmaxwell and @rustyrussell
BIP 8: Use block heights rather than MTP ca8e9b87a7
BIP 8: Require the bit to be set during LOCKED_IN d7662ab88c
BIP 8: Add FAILING state to allow lockinontimeout upgrades 155ce23c2f
luke-jr force-pushed on Jun 25, 2017
luke-jr cross-referenced this on Jul 6, 2017 from issue BIP 8 revisions: use height, and last-ditch FAILING status by luke-jr

in bip-0008.mediawiki:76 in d7662ab88c outdated

  71 | @@ -72,8 +72,9 @@ for the purposes of this proposal, and support two future upgrades for different
  72 |  When a block nVersion does not have top bits 001, it is treated as if all
  73 |  bits are 0 for the purposes of deployments.
  74 |  
  75 | -Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on
  76 | -consensus rules.
  77 | +Miners must continue setting the bit in LOCKED_IN phase so uptake is visible and acknowledged.
  78 | +Blocks without the applicable bit set are invalid during this period.

rustyrussell commented at 1:12 AM on July 7, 2017:

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.

in bip-0008.mediawiki:46 in ca8e9b87a7 outdated

  41 | @@ -37,22 +42,22 @@ The following guidelines are suggested for selecting these parameters for a soft
  42 |  
  43 |  # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name.
  44 |  # '''bit''' should be selected such that no two concurrent softforks use the same bit.
  45 | -# '''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.
  46 | -# '''timeout''' should be 1 year (31536000 seconds) after starttime.
  47 | +# '''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.
  48 | +# '''timeout''' should be approximately 1 year after start, and on a block which begins a retarget period. Therefore, '''start''' plus 52416.

rustyrussell commented at 1:22 AM on July 7, 2017:

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.

in bip-0008.mediawiki:197 in 155ce23c2f
```
 193 | @@ -180,6 +194,7 @@ https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits
 194 |  
 195 |  * The '''lockinontimeout''' flag is added. BIP 9 would only transition to the FAILED state when timeout was reached.
 196 |  * Block heights are used for the deployment monotonic clock, rather than median-time-past.
 197 | +* The last-ditch effort during a new FAILING state is added to allow '''lockinontimeout''' to be safely set after the initial deployment.
```
rustyrussell commented at 1:26 AM on July 7, 2017:

Clever, but too clever.

I would prefer to eliminate the lockinontimeout, as if it were always true. That avoids debate and horse-trading.

shaolinfry commented at 4:06 AM on July 7, 2017:

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

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-height

in bip-0008.mediawiki:77 in 155ce23c2f

  75 | +for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011).
  76 | +When a block nVersion does not have top bits 001, it is treated as if all
  77 | +bits are 0 for the purposes of deployments.
  78 | +
  79 | +Miners must continue setting the bit in LOCKED_IN phase so uptake is visible and acknowledged.
  80 | +Blocks without the applicable bit set are invalid during this period.

kek-coin commented at 7:41 PM on September 27, 2017:

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.

shaolinfry commented at 3:00 PM on June 24, 2020: contributor

ACK
luke-jr merged this on Jun 25, 2020
luke-jr closed this on Jun 25, 2020

Contributors

Labels

Proposed BIP modification

Linked (view graph)

#551 BIP 8 revisions: use height, and last-ditch FAILING status