From 750f5e59f6fe57f4b3c40c18df92d87aded4b9db Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Sat, 24 Jun 2017 18:35:25 +0000 Subject: BIP 8: Refactor back to wholly-contained spec This partially reverts 7f6a0f811cf27ab6d77e499afc81b97d6d11ced2 --- bip-0008.mediawiki | 132 +++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 124 insertions(+), 8 deletions(-) (limited to 'bip-0008.mediawiki') diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 3a1f207..1409c63 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -1,6 +1,6 @@ 
   BIP: 8
-  Title: Version bits with guaranteed lock-in
+  Title: Version bits 2017
   Author: Shaolin Fry 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0008
@@ -13,7 +13,7 @@
 
 ==Abstract==
 
-This document specifies an extension to [[bip-0009.mediawiki|BIP9]] that introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").
+This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").
 
 ==Motivation==
 
@@ -23,21 +23,105 @@ This specification provides a way to optionally guarantee lock-in at the end of
 
 ==Specification==
 
-This specification is the same as [[bip-0009.mediawiki|BIP9]] except from the STARTED state, there is no FAILED condition. The state transition from '''STARTED''' to '''LOCKED_IN''' will occur under two condition:
+Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
 
-The first is when the threshold  of blocks signalling is reached as per BIP9. The second is if the timeout is still '''STARTED'''.
+# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
+# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
+# The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
+# The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
+# The '''lockinontimeout''' boolean if set to true, will transition state to '''LOCKED_IN''' at timeout if not already '''LOCKED_IN''' or '''ACTIVE'''.
+
+===Selection guidelines===
+
+The following guidelines are suggested for selecting these parameters for a soft fork:
+
+# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name.
+# '''bit''' should be selected such that no two concurrent softforks use the same bit.
+# '''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.
+# '''lockinontimeout''' should be set to true for any softfork that isn't exclusively for miner benefit.
+
+A later deployment using the same bit is possible as long as the starttime is after the previous one's
+timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
+
+===States===
+
+With each block and soft fork, we associate a deployment state. The possible states are:
+
+# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
+# '''STARTED''' for blocks past the starttime.
+# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion, or for one retarget period after the timeout when '''lockinontimeout''' is true.
+# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
+# '''FAILED''' for all blocks after the timeout time, if LOCKED_IN was not reached and '''lockinontimeout''' is false.
+
+===Bit flags===
+
+The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number.
+
+Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
+001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
+
+Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available.
+This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those
+for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011).
+When a block nVersion does not have top bits 001, it is treated as if all
+bits are 0 for the purposes of deployments.
+
+Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on
+consensus rules.
+
+===New consensus rules===
+
+The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
 
 ===State transitions===
 
 
 
-During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeout''' is reached.
+The genesis block has state DEFINED for each deployment, by definition.
+
+    State GetStateForBlock(block) {
+        if (block.height == 0) {
+            return DEFINED;
+        }
+
+All blocks within a retarget period have the same state. This means that if
+floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every
+deployment.
+
+        if ((block.height % 2016) != 0) {
+            return GetStateForBlock(block.parent);
+        }
+
+Otherwise, the next state depends on the previous state:
+
+        switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
+
+We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below
+refers to the median nTime of a block and its 10 predecessors. The expression GetMedianTimePast(block.parent) is
+referred to as MTP in the diagram above, and is treated as a monotonic clock defined by the chain.
+
+        case DEFINED:
+            if (GetMedianTimePast(block.parent) >= timeout) {
+                return (lockinontimeout == true) ? LOCKED_IN : FAILED;
+            }
+            if (GetMedianTimePast(block.parent) >= starttime) {
+                return STARTED;
+            }
+            return DEFINED;
+
+After a period in the STARTED state, if we're past the timeout, we switch to LOCKED_IN or FAILED. If not, we tally the bits set,
+and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
+version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
+The transition to FAILED takes precendence, as otherwise an ambiguity can arise.
+There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
+other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
+
+Note that a block's state never depends on its own nVersion; only on that of its ancestors.
 
         case STARTED:
-            // BIP8/9 specification follows
             if (GetMedianTimePast(block.parent) >= timeout) {
-                // implementation detail: if flag set, BIP8 workflow, else BIP9 workflow.
-                return (fLockInOnTimeout == true) ? THRESHOLD_LOCKED_IN : THRESHOLD_FAILED
+                return (lockinontimeout == true) ? LOCKED_IN : FAILED;
             }
             int count = 0;
             walk = block;
@@ -52,6 +136,38 @@ During the STARTED state if the '''lockinontimeout''' is set to true, the state
             }
             return STARTED;
 
+After a retarget period of LOCKED_IN, we automatically transition to ACTIVE.
+
+        case LOCKED_IN:
+            return ACTIVE;
+
+And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached.
+
+        case ACTIVE:
+            return ACTIVE;
+
+        case FAILED:
+            return FAILED;
+        }
+    }
+
+'''Implementation'''
+It should be noted that the states are maintained along block chain
+branches, but may need recomputation when a reorganization happens.
+
+Given that the state for a specific block/deployment combination is completely determined by its ancestry before the
+current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)),
+it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
+block, indexed by its parent.
+
+===Warning mechanism===
+
+To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion.  Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).
+
+===getblocktemplate changes===
+
+BIP 8 is compatible with and reuses the GBT changes from BIP 9.
+
 === Reference implementation ===
 
 https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits
-- 
cgit v1.2.3


From 17e158b3c3ccf05505cec60c7408a9968774d15f Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sat, 24 Jun 2017 18:58:12 +0000
Subject: BIP 8: Add a contrast section

---
 bip-0008.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

(limited to 'bip-0008.mediawiki')

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 1409c63..7be8bac 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -172,6 +172,10 @@ BIP 8 is compatible with and reuses the GBT changes from BIP 9.
 
 https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits
 
+==Contrasted with BIP 9==
+
+* The '''lockinontimeout''' flag is added. BIP 9 would only transition to the FAILED state when timeout was reached.
+
 ==Backwards compatibility==
 
 BIP8 and BIP9 deployments should not share concurrent active deployment bits. Nodes that only implement BIP9 will not activate a BIP8 soft fork if hashpower threshold is not reached by '''timeout''', however, those nodes will still accept the blocks generated by activated nodes.
-- 
cgit v1.2.3


From ca8e9b87a7e1a51952d4f68dcfc3280758a0a47e Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sun, 25 Jun 2017 05:39:50 +0000
Subject: BIP 8: Use block heights rather than MTP

---
 bip-0008.mediawiki | 32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

(limited to 'bip-0008.mediawiki')

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 7be8bac..b00e447 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -2,6 +2,7 @@
   BIP: 8
   Title: Version bits 2017
   Author: Shaolin Fry 
+          Luke Dashjr 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0008
   Status: Draft
@@ -13,12 +14,16 @@
 
 ==Abstract==
 
-This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").
+This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that corrects for a number of perceived mistakes.
+Block heights are used for start and timeout rather than POSIX timestamps.
+It additionally introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").
 
 ==Motivation==
 
 BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate.
 
+Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of siginificant hashrate could interfere with a late activation.
+
 This specification provides a way to optionally guarantee lock-in at the end of the [[bip-0009.mediawiki|BIP9]] timeout, and therefore activation, while still allowing a hashrate super majority to trigger activation earlier.
 
 ==Specification==
@@ -27,8 +32,8 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 
 # The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
-# The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
-# The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
+# The '''start''' specifies the height of the first block at which the bit gains its meaning.
+# The '''timeout''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is either considered failed on all descendants of the block, or, if '''lockinontimeout'' is true, transitions to the '''LOCKED_IN''' state.
 # The '''lockinontimeout''' boolean if set to true, will transition state to '''LOCKED_IN''' at timeout if not already '''LOCKED_IN''' or '''ACTIVE'''.
 
 ===Selection guidelines===
@@ -37,11 +42,11 @@ The following guidelines are suggested for selecting these parameters for a soft
 
 # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name.
 # '''bit''' should be selected such that no two concurrent softforks use the same bit.
-# '''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.
 # '''lockinontimeout''' should be set to true for any softfork that isn't exclusively for miner benefit.
 
-A later deployment using the same bit is possible as long as the starttime is after the previous one's
+A later deployment using the same bit is possible as long as the start is after the previous one's
 timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
 
 ===States===
@@ -49,10 +54,10 @@ timeout or activation, but it is discouraged until necessary, and even then reco
 With each block and soft fork, we associate a deployment state. The possible states are:
 
 # '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
-# '''STARTED''' for blocks past the starttime.
+# '''STARTED''' for blocks at or beyond the start height.
 # '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion, or for one retarget period after the timeout when '''lockinontimeout''' is true.
 # '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
-# '''FAILED''' for all blocks after the timeout time, if LOCKED_IN was not reached and '''lockinontimeout''' is false.
+# '''FAILED''' for all blocks after the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is false.
 
 ===Bit flags===
 
@@ -97,15 +102,13 @@ Otherwise, the next state depends on the previous state:
 
         switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
 
-We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below
-refers to the median nTime of a block and its 10 predecessors. The expression GetMedianTimePast(block.parent) is
-referred to as MTP in the diagram above, and is treated as a monotonic clock defined by the chain.
+We remain in the initial state until either we pass the start height or the timeout.
 
         case DEFINED:
-            if (GetMedianTimePast(block.parent) >= timeout) {
+            if (block.height >= timeout) {
                 return (lockinontimeout == true) ? LOCKED_IN : FAILED;
             }
-            if (GetMedianTimePast(block.parent) >= starttime) {
+            if (block.height >= start) {
                 return STARTED;
             }
             return DEFINED;
@@ -120,7 +123,7 @@ other one simultaneously transitions to STARTED, which would mean both would dem
 Note that a block's state never depends on its own nVersion; only on that of its ancestors.
 
         case STARTED:
-            if (GetMedianTimePast(block.parent) >= timeout) {
+            if (block.height >= timeout) {
                 return (lockinontimeout == true) ? LOCKED_IN : FAILED;
             }
             int count = 0;
@@ -175,6 +178,7 @@ https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits
 ==Contrasted with BIP 9==
 
 * 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.
 
 ==Backwards compatibility==
 
-- 
cgit v1.2.3


From d7662ab88c86551a384be0888f3566181403a5ee Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sun, 25 Jun 2017 05:44:39 +0000
Subject: BIP 8: Require the bit to be set during LOCKED_IN

---
 bip-0008.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

(limited to 'bip-0008.mediawiki')

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index b00e447..feb9327 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -72,8 +72,9 @@ for the purposes of this proposal, and support two future upgrades for different
 When a block nVersion does not have top bits 001, it is treated as if all
 bits are 0 for the purposes of deployments.
 
-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.
+For flexibility, this rule does NOT require the top 3 bits to be set any particular way.
 
 ===New consensus rules===
 
-- 
cgit v1.2.3


From 155ce23c2f78158c92dcde56620e20797c3a3b91 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Sun, 25 Jun 2017 06:29:23 +0000
Subject: BIP 8: Add FAILING state to allow lockinontimeout upgrades

---
 bip-0008.mediawiki | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

(limited to 'bip-0008.mediawiki')

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index feb9327..26e8572 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -33,7 +33,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 # The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
 # The '''start''' specifies the height of the first block at which the bit gains its meaning.
-# The '''timeout''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is either considered failed on all descendants of the block, or, if '''lockinontimeout'' is true, transitions to the '''LOCKED_IN''' state.
+# The '''timeout''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is either considered failed on all descendants of the block (but see the exception during '''FAILING''' state), or, if '''lockinontimeout'' is true, transitions to the '''LOCKED_IN''' state.
 # The '''lockinontimeout''' boolean if set to true, will transition state to '''LOCKED_IN''' at timeout if not already '''LOCKED_IN''' or '''ACTIVE'''.
 
 ===Selection guidelines===
@@ -44,7 +44,7 @@ The following guidelines are suggested for selecting these parameters for a soft
 # '''bit''' should be selected such that no two concurrent softforks use the same bit.
 # '''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.
-# '''lockinontimeout''' should be set to true for any softfork that isn't exclusively for miner benefit.
+# '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligable percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
 
 A later deployment using the same bit is possible as long as the start is after the previous one's
 timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
@@ -57,7 +57,8 @@ With each block and soft fork, we associate a deployment state. The possible sta
 # '''STARTED''' for blocks at or beyond the start height.
 # '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion, or for one retarget period after the timeout when '''lockinontimeout''' is true.
 # '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
-# '''FAILED''' for all blocks after the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is false.
+# '''FAILING''' for one retarget period after the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is false.
+# '''FAILED''' for all blocks after the FAILING retarget period.
 
 ===Bit flags===
 
@@ -107,17 +108,17 @@ We remain in the initial state until either we pass the start height or the time
 
         case DEFINED:
             if (block.height >= timeout) {
-                return (lockinontimeout == true) ? LOCKED_IN : FAILED;
+                return (lockinontimeout == true) ? LOCKED_IN : FAILING;
             }
             if (block.height >= start) {
                 return STARTED;
             }
             return DEFINED;
 
-After a period in the STARTED state, if we're past the timeout, we switch to LOCKED_IN or FAILED. If not, we tally the bits set,
+After a period in the STARTED state, if we're past the timeout, we switch to LOCKED_IN or FAILING. If not, we tally the bits set,
 and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
 version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
-The transition to FAILED takes precendence, as otherwise an ambiguity can arise.
+The transition to FAILING takes precendence, as otherwise an ambiguity can arise.
 There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
 other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
 
@@ -125,7 +126,7 @@ Note that a block's state never depends on its own nVersion; only on that of its
 
         case STARTED:
             if (block.height >= timeout) {
-                return (lockinontimeout == true) ? LOCKED_IN : FAILED;
+                return (lockinontimeout == true) ? LOCKED_IN : FAILING;
             }
             int count = 0;
             walk = block;
@@ -140,6 +141,19 @@ Note that a block's state never depends on its own nVersion; only on that of its
             }
             return STARTED;
 
+If the deployment is not LOCKED_IN by the timeout (or '''lockinontimeout'''), it has a single retarget period during which it may still become active, only by unanimous signalling in every block.
+This state exists such that if '''lockinontimeout''' is set to true later, it remains compatible with the original deployment.
+
+        case FAILING:
+            walk = block;
+            for (i = 0; i < 2016; i++) {
+                walk = walk.parent;
+                if (walk.nVersion & 0xE0000000 == 0x20000000 && ((walk.nVersion >> bit) & 1) != 1) {
+                    return FAILED;
+                }
+            }
+            return ACTIVE;
+
 After a retarget period of LOCKED_IN, we automatically transition to ACTIVE.
 
         case LOCKED_IN:
@@ -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.
 
 ==Backwards compatibility==
 
-- 
cgit v1.2.3