diff options
author | Rusty Russell <rusty@rustcorp.com.au> | 2015-09-25 10:57:56 +0930 |
---|---|---|
committer | Rusty Russell <rusty@rustcorp.com.au> | 2015-09-25 10:57:56 +0930 |
commit | fecfe5bfac1d8a85b6ee9415201573f892b421e2 (patch) | |
tree | 1d5bbc15089908226fe0dedd26ee39037a4d7760 /bip-wuille-todd-maxwell-russell.mediawiki | |
parent | be86444b8826a6dcb44602e24ed1d1316204f2a6 (diff) | |
download | bips-fecfe5bfac1d8a85b6ee9415201573f892b421e2.tar.xz |
Formatting feedback & copyright from btcdrak.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Diffstat (limited to 'bip-wuille-todd-maxwell-russell.mediawiki')
-rw-r--r-- | bip-wuille-todd-maxwell-russell.mediawiki | 39 |
1 files changed, 22 insertions, 17 deletions
diff --git a/bip-wuille-todd-maxwell-russell.mediawiki b/bip-wuille-todd-maxwell-russell.mediawiki index d43157b..3bb2b9b 100644 --- a/bip-wuille-todd-maxwell-russell.mediawiki +++ b/bip-wuille-todd-maxwell-russell.mediawiki @@ -1,3 +1,4 @@ +<pre> BIP: ?? Title: Version bits with timeout and delay Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au> @@ -36,21 +37,21 @@ retarget period. Software which supports the change should begin by setting B in all blocks mined until it is resolved. - <nowiki>if (BState == defined) { - SetBInBlock(); - } + if (BState == defined) { + SetBInBlock(); + } '''Success: Lock-in Threshold''' If bit B is set in 1916 (1512 on testnet) or more of the 2016 blocks within a retarget period, it is considered ''locked-in''. Miners should stop setting bit B. - <nowiki>if (NextBlockHeight % 2016 == 0) { - if (BState == defined && Previous2016BlocksCountB() >= 1916) { - BState = locked-in; - BActiveHeight = NextBlockHeight + 2016; + if (NextBlockHeight % 2016 == 0) { + if (BState == defined && Previous2016BlocksCountB() >= 1916) { + BState = locked-in; + BActiveHeight = NextBlockHeight + 2016; + } } - } '''Success: Activation Delay''' The consensus rules related to ''locked-in'' soft fork will be enforced in @@ -58,11 +59,11 @@ the second retarget period; ie. there is a one retarget period in which the remaining 5% can upgrade. At the that activation block and after, the bit B may be reused for a different soft fork. - <nowiki>if (BState == locked-in && NextBlockHeight == BActiveHeight) { - BState = activated; - ApplyRulesForBFromNextBlock(); - /* B can be reused, immediately */ - } + if (BState == locked-in && NextBlockHeight == BActiveHeight) { + BState = activated; + ApplyRulesForBFromNextBlock(); + /* B can be reused, immediately */ + } '''Failure: Timeout''' A soft fork proposal should include a ''timeout''. This is measured @@ -120,11 +121,11 @@ If the soft fork still not ''locked-in'' and the GetMedianTimePast() of a block following a retarget period is at or past this timeout, miners should cease setting this bit. - <nowiki>if (NextBlockHeight % 2016 == 0) { - if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) { - BState = failed; + if (NextBlockHeight % 2016 == 0) { + if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) { + BState = failed; + } } - } After another retarget period (to allow detection of buggy miners), the bit may be reused. @@ -160,3 +161,7 @@ enough failed proposals to cause a bit shortage. The fallow period at the conclusion of a soft fork attempt allows some detection of buggy clients, and allows time for warnings and software upgrades for successful soft forks. + +==Copyright== + +This document is placed in the public domain. |