1
A 2015 draft BIP suggested using a "hard fork bit":
The most significant bit in nVersion is defined as the hardfork bit. Currently, blocks with this header bit setting to 1 are invalid, since BIP34 interprets nVersion as a signed number and requires it to be >=2 (with BIP66, >=3). Among the 640 bits in the block header, this is the only one which is fixed and serves no purpose, and therefore the best way to indicate the deployment of a hardfork.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
If bit indexes increase from left to right, then I imagine the hard fork bit occupying index 31, marked as * below (nVersion is a 32-bit value).
0 1 2 3
0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1
*
According to the proposal, setting bit 31 of nVersion should cause a block to be rejected as invalid.
BIP-9 places further constraints on the available bits, specifically, bits 0-2 must be set as [0, 0, 1]:
Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
In addition, BIP-9 arranges version bits in increasing order from right to left. That is, version bit 0 is nVersion bit 31, version bit 1 is nVersion bit 30, and so on.
But if this were the case, then version bit 0 would be off-limits. BIP-9 says nothing about this, and in fact BIP-68 was signaled using version bit 0:
This BIP is to be deployed by "versionbits" BIP9 using bit 0.
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
My questions are simple:
- Given my diagram above, which
nVersionbit index is the "hard fork bit?" - If I'm correct in my interpretation (I don't believe I am), then how could BIP-68 have been signaled without causing the blocks doing so to be rejected as invalid?
Update: the source of my confusion was thinking that nVersion bit indexing and version bit indexing ran in opposite directions. The don't. To signal readiness for a proposal using version bit 1, for example, nVersion bit 1 is set. BIP-9's rules activate when an nVersion signature is detected. This signature is bits 29-31 set as 1, 0, and 0, respectively. This leaves bit 31 unset.
Peter's answer addresses question (1) above.
As for question (2) BIP-68 signaling didn't cause block rejection because bit 0 was being set, not bit 31.
That seems to match my interpretation. If so, how could BIP-68 signaling call for setting bit-31 and not result in those blocks being rejected? – Rich Apodaca – 2017-08-09T20:59:33.273
BIP68 gives meaning to bit 31 of the nSequence field of a transaction. The hardfork bit is bit 31 of the nVersion field of a block. – Pieter Wuille – 2017-08-09T21:04:41.607
Oh, I see, you're confused by bit order. Don't think of bits as having an order - it's not well defined, depends on the hardware, and is generally irrelevant. nVersion is an integer, and bit X of it is the value of
(nVersion >> X) & 1. – Pieter Wuille – 2017-08-09T21:07:37.143BIP-68's deployment plan calls for setting version bit 0 (
nVersionbit 31) as a signal. I understand the functionality of BIP-68 was to assign meaning to thenSequencefield. My question comes from the deployment mechanism for BIP-68, which requires signaling nodes to setnVersionbit 31. At least that's what it looks like. – Rich Apodaca – 2017-08-09T21:08:01.433I don't understand where you read that. BIP68 was signalled for using nVersion bit 0, not bit 31. – Pieter Wuille – 2017-08-09T21:08:41.013
"This BIP is to be deployed by "versionbits" BIP9 using bit 0." (from BIP-68) AFAICT, versionbits bit 0 is bit 31 in my diagram. – Rich Apodaca – 2017-08-09T21:11:29.297
Bit 0 is bit 0, bit 31 is bit 31. I don't understand why you think there is a swap? – Pieter Wuille – 2017-08-09T21:12:14.210
Let us continue this discussion in chat.
– Pieter Wuille – 2017-08-09T21:12:55.333