From 663efa52d462b63cf15ba83ad7438e0f04702377 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 17 Feb 2021 21:01:03 +0000 Subject: [PATCH 1/4] BIP 8: Move recommendation for "name" to "Selection guidelines" --- bip-0008.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 8800b437..c09a179b 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -34,7 +34,7 @@ Block time is somewhat unreliable and may be intentionally or unintentionally in Each soft fork deployment is specified by the following per-chain parameters (further elaborated below): -# 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 '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. # 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 '''startheight''' specifies the height of the first block at which the bit gains its meaning. # The '''timeoutheight''' 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 considered failed on all descendants of the block. @@ -44,7 +44,7 @@ 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: -# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. +# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. # '''bit''' should be selected such that no two concurrent softforks use the same bit. # '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) 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 for simplicity. # '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''. From 1e25eb98f646f546dd1757eabecc016aceb1cbc3 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 17 Feb 2021 21:02:51 +0000 Subject: [PATCH 2/4] BIP 8: Advise not choosing a bit being used for other things --- bip-0008.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index c09a179b..ddf0890b 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -45,7 +45,7 @@ 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: # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. -# '''bit''' should be selected such that no two concurrent softforks use the same bit. +# '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes. # '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) 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 for simplicity. # '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''. # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.) From 72bf969a1719aefdbd1094378cfd0386e4e4e9bc Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 17 Feb 2021 21:07:56 +0000 Subject: [PATCH 3/4] BIP 8: Avoid speculating precisely on how soon the economic majority might be upgraded --- bip-0008.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index ddf0890b..01c963ca 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -46,8 +46,8 @@ 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. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes. -# '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) 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 for simplicity. -# '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''. +# '''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'''. # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible 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 startheight is after the previous one's From ca77342417f09148f00e8cc5c72f4e25920ac816 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Fri, 26 Feb 2021 13:33:36 +0100 Subject: [PATCH 4/4] bip8: remove recommendation to force activation after a year Signed-off-by: Antoine Poinsot --- bip-0008.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 01c963ca..669574a2 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -22,7 +22,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ==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 result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date. +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 result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time, as well as for accelerated activation by majority of hash rate before the flag date. Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of significant hashrate could interfere with a late activation.