1
0
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:
Tobin Harding 2021-06-09 10:33:59 +10:00
parent 9ee9717310
commit f59b209b91
No known key found for this signature in database
GPG Key ID: 40BF9E4C269D6607

View File

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