934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/edffe529056f6dfd/bip-0009.mediawiki

2021-12-15T15:42:04Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/edffe529056f6dfd/bip-0009.mediawiki

← Older revision		Revision as of 15:42, 15 December 2021
Line 23:		Line 23:
	==Motivation==		==Motivation==

	BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.		[[bip-0034.mediawiki\|BIP 34]] introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.

	In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.		In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in [[bip-0066.mediawiki\|BIP 66]] and [[bip-0065.mediawiki\|BIP 65]], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.

	==Specification==		==Specification==
Line 199:		Line 199:

	Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.		Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
	Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113.		Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [[bip-0016.mediawiki\|16]], [[bip-0065.mediawiki\|65]], [[bip-0066.mediawiki\|66]], [[bip-0068.mediawiki\|68]], [[bip-0112.mediawiki\|112]], and [[bip-0113.mediawiki\|113]].
	If a client does not understand a rule without the prefix, it may use it unmodified for mining.		If a client does not understand a rule without the prefix, it may use it unmodified for mining.
	On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction).		On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be [[bip-0034.mediawiki\|BIP 34]] (because it modifies coinbase construction) and [[bip-0141.mediawiki\|141]] (since it modifies the txid hashing and adds a commitment to the generation transaction).
	A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified.		A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified.

Line 209:		Line 209:

	'''Modified thresholds'''		'''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'''		'''Conflicting soft forks'''

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/cf0b529e78860fa2/bip-0009.mediawiki

2021-01-01T09:59:47Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/cf0b529e78860fa2/bip-0009.mediawiki

← Older revision		Revision as of 09:59, 1 January 2021
Line 221:		Line 221:
	The failure timeout allows eventual reuse of bits even if a soft fork was		The failure timeout allows eventual reuse of bits even if a soft fork was
	never activated, so it's clear that the new use of the bit refers to a		never activated, so it's clear that the new use of the bit refers to a
	new BIP. It's deliberately very ~~course~~ grained, to take into account		new BIP. It's deliberately very coarse-grained, to take into account
	reasonable development and deployment delays. There are unlikely to be		reasonable development and deployment delays. There are unlikely to be
	enough failed proposals to cause a bit shortage.		enough failed proposals to cause a bit shortage.

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0009.mediawiki

2019-09-24T17:58:37Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0009.mediawiki

Show changes

JonathanCross: Creating BIP 9

2017-05-14T17:36:36Z

Creating BIP 9

New page

{{bip}}

<pre>
BIP: 9
Title: Version bits with timeout and delay
Author: Pieter Wuille <pieter.wuille@gmail.com>
Peter Todd <pete@petertodd.org>
Greg Maxwell <greg@xiph.org>
Rusty Russell <rusty@rustcorp.com.au>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0009
Status: Final
Type: Informational
Created: 2015-10-04
License: PD
</pre>

{{BipMoved|bip-0009.mediawiki}}

BIP 0009 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/edffe529056f6dfd/bip-0009.mediawiki

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/cf0b529e78860fa2/bip-0009.mediawiki

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0009.mediawiki

JonathanCross: Creating BIP 9