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.


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

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.


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.


My questions are simple:

  1. Given my diagram above, which nVersion bit index is the "hard fork bit?"
  2. 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.


Bit 31 is sometimes referred to as the hard fork bit.

BIP34 put a constraint on version numbers to be 2 or higher. As the block version is a 32-bit signed integer, setting its highest bit results in a negative number, which would violate BIP34.

As a result, any usage of that bit results in a backward incompatible change to the rules - a hard fork - that is obvious to all participants in the system.

  • 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 Aug 9 '17 at 20:59
  • 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 Aug 9 '17 at 21:04
  • 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 Aug 9 '17 at 21:07
  • BIP-68's deployment plan calls for setting version bit 0 (nVersion bit 31) as a signal. I understand the functionality of BIP-68 was to assign meaning to the nSequence field. My question comes from the deployment mechanism for BIP-68, which requires signaling nodes to set nVersion bit 31. At least that's what it looks like. – Rich Apodaca Aug 9 '17 at 21:08
  • I don't understand where you read that. BIP68 was signalled for using nVersion bit 0, not bit 31. – Pieter Wuille Aug 9 '17 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.