@ -901,7 +901,7 @@ Undoubtedly, a serious consensus attack would erode confidence in bitcoin in the
[[consensus_changes]]
=== Changing the Consensus Rules
((("mining and consensus", "changing consensus rules", id="MACrule10")))((("mining and consensus", "consensus rules", "changing", id="Crule10")))The rules of consensus determine the validity of transactions and blocks. These rules are the basis for collaboration between all bitcoin nodes and are responsible for the convergence of all local perspectives into a single consistent blockchain across the entire network.
((("mining and consensus", "consensus rules", "changing", id="Crule10")))The rules of consensus determine the validity of transactions and blocks. These rules are the basis for collaboration between all bitcoin nodes and are responsible for the convergence of all local perspectives into a single consistent blockchain across the entire network.
While the consensus rules are invariable in the short term and must be consistent across all nodes, they are not invariable in the long term. In order to evolve and develop the bitcoin system, the rules have to change from time to time to accommodate new features, improvements or bug fixes. Unlike traditional software development, however, upgrades to a consensus system are much more difficult and require coordination between all the participants.
@ -1072,7 +1072,7 @@ image::images/mbc2_1010.png[BIP-9 Proposal State Transition Diagram]
Proposals start in the +DEFINED+ state, once their parameters are known (defined) in the bitcoin software. For blocks with MTP after the start time, the proposal state transitions to +STARTED+. If the voting threshold is exceeded within a retarget period and the timeout has not been exceeded, the proposal state transitions to +LOCKED_IN+. One retarget period later, the proposal becomes +ACTIVE+. Proposals remain in the +ACTIVE+ state perpetually once they reach that state. If the timeout is elapsed before the voting threshold has been reached, the proposal state changes to +FAILED+, indicating a rejected proposal. +REJECTED+ proposals remain in that state perpetually.
BIP-9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+ and associated BIPs (68, 112, 113). The proposal named "csv" was activated successfully in July of 2016.((("", startref="MACrule10")))((("", startref="forks10a")))
BIP-9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+ and associated BIPs (68, 112, 113). The proposal named "csv" was activated successfully in July of 2016.((("", startref="forks10a")))
The standard is defined in https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki[BIP-9 (Version bits with timeout and delay)]
judymcconville@roadrunner.com
7 years ago