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

Formatting feedback & copyright from btcdrak.

Browse Source 
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2015-09-25 10:57:56 +09:30
parent be86444b88
commit fecfe5bfac
1 changed files with 22 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
bip-wuille-todd-maxwell-russell.mediawiki
View File

@ -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.