Skip to content

Commit 29963a8

Browse files
authored
Merge pull request bitcoin#408 from jl2012/patch-25
Clarify BIP9 threshold
2 parents 02d4086 + 5e6dc77 commit 29963a8

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

bip-0009.mediawiki

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -109,7 +109,7 @@ referred to as MTP in the diagram above, and is treated as a monotonic clock def
109109
110110
After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
111111
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
112-
version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 for testnet (75% of 2016).
112+
version numbers. The threshold is ≥1916 blocks (95% of 2016), or 1512 for testnet (75% of 2016).
113113
The transition to FAILED takes precendence, as otherwise an ambiguity can arise.
114114
There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
115115
other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
@@ -202,7 +202,7 @@ A client that does not understand a rule prefixed by '!' must not attempt to pro
202202
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.
203203

204204
'''Modified thresholds'''
205-
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.
205+
The 1916 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.
206206

207207
'''Conflicting soft forks'''
208208
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.

0 commit comments

Comments
 (0)