<p>Bit 31 is sometimes referred to as the hard fork bit.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-08-09T20:59:33.273Z
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
CC BY-SA 3.0
2017-08-09T21:04:41.607Z
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
CC BY-SA 3.0
2017-08-09T21:07:37.143Z
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
CC BY-SA 3.0
2017-08-09T21:08:01.433Z
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
CC BY-SA 3.0
2017-08-09T21:08:41.013Z
I don't understand where you read that. BIP68 was signalled for using nVersion bit 0, not bit 31.
Pieter Wuille
CC BY-SA 3.0
2017-08-09T21:11:29.297Z
"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
CC BY-SA 3.0
2017-08-09T21:12:14.210Z
Bit 0 is bit 0, bit 31 is bit 31. I don't understand why you think there is a swap?
Pieter Wuille
CC BY-SA 3.0
2017-08-09T21:12:55.333Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/63578/discussion-between-pieter-wuille-and-rich-apodaca).
Pieter Wuille
CC BY-SA 3.0
2017-08-09T20:57:50.073Z
2017-08-09T20:57:50.073Z
Pieter Wuille
<p>A 2015 draft BIP suggested using a "hard fork bit":</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html</a></p>

<p>If bit indexes increase from left to right, then I imagine the hard fork bit occupying index 31, marked as <code>*</code> below (<code>nVersion</code> is a 32-bit value).</p>

<pre><code>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
                                                              *
</code></pre>

<p>According to the proposal, setting bit 31 of <code>nVersion</code> should cause a block to be rejected as invalid.</p>

<p>BIP-9 places further constraints on the available bits, specifically, bits 0-2 must be set as [0, 0, 1]:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki</a></p>

<p>In addition, BIP-9 arranges version bits in increasing order from right to left. That is, version bit 0 is <code>nVersion</code> bit 31, version bit 1 is <code>nVersion</code> bit 30, and so on.</p>

<p>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:</p>

<blockquote>
  <p>This BIP is to be deployed by "versionbits" BIP9 using bit 0.</p>
</blockquote>

<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki</a></p>

<p>My questions are simple:</p>

<ol>
<li>Given my diagram above, which <code>nVersion</code> bit index is the "hard fork bit?"</li>
<li>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?</li>
</ol>

<p>Update: the source of my confusion was thinking that <code>nVersion</code> 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, <code>nVersion</code> bit 1 is set. BIP-9's rules activate when an <code>nVersion</code> signature is detected. This signature is bits 29-31 set as <code>1</code>, <code>0</code>, and <code>0</code>, respectively. This leaves bit 31 unset.</p>

<p>Peter's answer addresses question (1) above.</p>

<p>As for question (2) BIP-68 signaling didn't cause block rejection because bit 0 was being set, not bit 31.</p>

<bip9-version-bits><soft-fork><blockchain-fork>
Which nVersion bit is the "hard fork bit?"
Rich Apodaca
# Which nVersion bit is the "hard fork bit?"

(Asked by: username_0 on 2017-08-09)

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:

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.

**Tags:** bip9-version-bits, soft-fork, blockchain-fork


---

## 1 answers

### Answer by username_1 on 2017-08-09. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_0**: 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?  
> **username_1**: 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.  
> **username_1**: 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`.  
> **username_0**: 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.  
> **username_1**: I don't understand where you read that. BIP68 was signalled for using nVersion bit 0, not bit 31.  
> **username_0**: "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.  
> **username_1**: Bit 0 is bit 0, bit 31 is bit 31. I don't understand why you think there is a swap?  
> **username_1**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/63578/discussion-between-username_1-username_1-and-username_0).  

---

