bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

BIP 8: Avoid speculating precisely on how soon the economic majority might be upgraded

Browse Source
This commit is contained in:
Luke Dashjr 2021-02-17 21:07:56 +00:00
parent 1e25eb98f6
commit 72bf969a17
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
bip-0008.mediawiki
View File

@ -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. # '''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. # '''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. # '''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 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''. # '''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.) # '''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 A later deployment using the same bit is possible as long as the startheight is after the previous one's