mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-03 18:57:18 +01:00
Code Issues Projects Releases Wiki Activity

Clarify things and make notation more consistent

Browse source
This commit is contained in:
Pieter Wuille 2016-03-02 19:42:41 +01:00
parent 760e2a15bf
commit 63d626668c
1 changed files with 15 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
bip-0009.mediawiki
View file

@ -74,7 +74,7 @@ floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed t
deployment.
if ((block.height % 2016) != 0) {
return GetStateForBlock(GetParent(block));
return GetStateForBlock(block.parent);
}
Otherwise, the next state depends on the previous state:
@ -82,27 +82,29 @@ Otherwise, the next state depends on the previous state:
switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) {
We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below
refers to the median nTime of the 11 blocks preceeding a given block (referred to as MTP in the diagram above).
refers to the median nTime of a block and its 10 predecessors. The expression GetMedianTimePast(block.parent) is
referred to as MTP in the diagram above, and is treated as a monotonic clock defined by the chain.
case DEFINED:
if (GetMedianTimePast(block) >= timeout) {
if (GetMedianTimePast(block.parent) >= timeout) {
return FAILED;
}
if (GetMedianTimePast(block) >= starttime) {
if (GetMedianTimePast(block.parent) >= starttime) {
return STARTED;
}
return DEFINED;
After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 on testnet (75% of 2016).
The transaction to FAILED takes precendence, as otherwise there
could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN and the other
to STARTED, which would mean both would demand setting the bit. Note that a block's state never depends on its own
nVersion; only on that of its ancestors.
version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 for testnet (75% of 2016).
The transition to FAILED takes precendence, as otherwise an ambiguity can arise.
There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
case STARTED: {
if (GetMedianTimePast(block) >= timeout) {
if (GetMedianTimePast(block.parent) >= timeout) {
return FAILED;
}
int count = 0;
@ -133,14 +135,13 @@ And ACTIVE and FAILED are terminal states, which a deployment stays in once they
}
}
'''Forks'''
'''Implementation'''
It should be noted that the states are maintained along block chain
branches, but may need recomputation when a reorganization happens.
'''Implementation'''
Given that the state for a specific block/deployment combination is completely determined by its ancestry before the
current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)),
it is possible to implement the mechanism above efficiently by caching the resulting state of every multiple-of-2016
it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
block, indexed by its parent.
====Warning mechanism====
@ -152,7 +153,7 @@ To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "i
The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
'''Modified thresholds'''
The 95% threshold (based on in BIP 34) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
The 1915 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
'''Conflicting soft forks'''
At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.