mirror of
https://github.com/bitcoin/bips.git
synced 2025-01-18 13:26:08 +01:00
Fix typo, remove 'in'
Phrase 'based on in BIP 43' should probably read 'based on BIP 34'.
This commit is contained in:
parent
9ee9717310
commit
f59b209b91
@ -205,7 +205,7 @@ A client that does not understand a rule prefixed by '!' must not attempt to pro
|
||||
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 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.
|
||||
The 1916 threshold (based on 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.
|
||||
|
Loading…
Reference in New Issue
Block a user