From 7314d13a08a72ded7d6cdaa32d1b4b88d8b76832 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Thu, 10 Mar 2016 13:27:09 +1030 Subject: [PATCH 1/3] bip9: fix heading levels. It goes from level 2 (specification) to 4; those headings should be level 3. Signed-off-by: Rusty Russell --- bip-0009.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 49e6adf2..6848c45e 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -35,7 +35,7 @@ timeout or activation, though it is recommended to have a pause in between to de Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year. -====States==== +===States=== With each block and soft fork, we associate a deployment state. The possible states are: @@ -45,7 +45,7 @@ With each block and soft fork, we associate a deployment state. The possible sta # '''ACTIVE''' for all blocks after the LOCKED_IN retarget period. # '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached. -====Bit flags==== +===Bit flags=== 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. @@ -59,11 +59,11 @@ 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==== +===New consensus rules=== The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. -====State transitions==== +===State transitions=== @@ -149,7 +149,7 @@ current retarget period (i.e. up to and including its ancestor with height block 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==== +===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). From 4c4009bfdb94d10d94908a144d768399cf40ea6f Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Thu, 10 Mar 2016 13:18:03 +1030 Subject: [PATCH 2/3] BIP9: More explicit recommendations on values. Basically the same thing reworded as a checklist, with 3 years turned into 1, and suggesting a 1 month delay after expected deployment date. Signed-off-by: Rusty Russell --- bip-0009.mediawiki | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 6848c45e..83ce7d00 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -28,12 +28,16 @@ Each soft fork deployment is specified by the following per-chain parameters (fu # 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 starttime should be set to some date in the future, coordinates with software release date. This is to prevent -triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the -starttime. A later deployment using the same bit is possible as long as the starttime is after the previous one's -timeout or activation, though it is recommended to have a pause in between to detect buggy software. +===Selection guidelines=== -Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year. +The following guidelines are suggested for selecting these parameters for a soft fork: + +# '''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 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. + +A later deployment using the same bit is possible as long as the starttime is after the previous one's +timeout or activation, though it is recommended to have a pause in between to detect buggy software. ===States=== From bce835d2ce0172bffa2858eaba21a6c6c3723110 Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Tue, 15 Mar 2016 16:29:24 +0100 Subject: [PATCH 3/3] Small improvements to BIP0009 --- bip-0009.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 83ce7d00..509a8a94 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -33,11 +33,11 @@ Each soft fork deployment is specified by the following per-chain parameters (fu The following guidelines are suggested for selecting these parameters for a soft fork: # '''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 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. +# '''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. A later deployment using the same bit is possible as long as the starttime is after the previous one's -timeout or activation, though it is recommended to have a pause in between to detect buggy software. +timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software. ===States===