mirror of
https://github.com/bitcoin/bips.git
synced 2025-01-18 13:26:08 +01:00
BIP 009: Minor revision to extend bit into lockin period.
As discussed here: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011275.html Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
parent
602e721256
commit
fd189fdccd
@ -37,14 +37,15 @@ retarget period.
|
||||
Software which supports the change should begin by setting B in all blocks
|
||||
mined until it is resolved.
|
||||
|
||||
if (BState == defined) {
|
||||
if (BState != activated && BState != failed) {
|
||||
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.
|
||||
''locked-in''. Miners should continue setting bit B, so uptake is
|
||||
visible.
|
||||
|
||||
if (NextBlockHeight % 2016 == 0) {
|
||||
if (BState == defined && Previous2016BlocksCountB() >= 1916) {
|
||||
@ -57,7 +58,7 @@ more of the 2016 blocks within a retarget period, it is considered
|
||||
The consensus rules related to ''locked-in'' soft fork will be enforced in
|
||||
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.
|
||||
after, miners should stop setting bit B, which may be reused for a different soft fork.
|
||||
|
||||
if (BState == locked-in && NextBlockHeight == BActiveHeight) {
|
||||
BState = activated;
|
||||
|
Loading…
Reference in New Issue
Block a user