<p><strong>nTime</strong>: blocks must have a higher timestamp than the median of the 11 previous blocks, and a lower timestamp than two hours in the future of the validating node's own clock. Assuming a regular block interval of ten minutes and a correctly set local time, the block can therefore be stamped between about one hour in the past and two hours in the future.</p>

<p><strong>nBits</strong>: This encodes the block target (the reciprocal of the difficulty) and cannot be changed.</p>

<p><strong>nVersion</strong>: The version field is 32 bits, and must be at least 2, 3 or 4 (i.e. the first three bits must be <code>010</code>, <code>011</code>, or <code>001</code> due to nVersion being encoded little endian). When using version 4 (<code>001…</code>) the remainder of the bits is defined by <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="nofollow noreferrer">BIP9</a> which has attached meaning to some of the last few bits that have been previously used to signal activation of soft forks. 
All remaining bits beside the above mentioned can be used to mutate the block header. They are for example used for "overt <a href="https://bitcoin.stackexchange.com/q/43579/5406">ASICBOOST</a>"-style mining.</p>

CC BY-SA 4.0
2019-09-15T22:54:38.380Z
Nit: BIP9 does not require the top bits to be 001; 011 and 010 are allowed as well, but no versionbits semantics are applied in that case (or in other words: using those prefix bits will be treated similar to 0010000...000).
Pieter Wuille
CC BY-SA 4.0
2019-09-21T04:07:38.437Z
@PieterWuille: Thanks, issuing a correction.
Murch
CC BY-SA 4.0
2019-09-15T22:10:52.053Z
2019-09-21T04:19:55.210Z
2019-09-21T04:19:55.210Z
Murch
<p>nBits cannot be changed at all. Its value must equal the (compact encoding of) the target value for that block, which is determined entirely by the predecessors of the block. In other words, if the prevblock hash is given, so is nBits.</p>

<p>nVersion: can be modified arbitrarily, though its value is subject to interpretation under BIP34 (requiring it to be at least 2), BIP66 (requiring it to be at least 3), BIP65 (requiring it to be at least 4), and BIP9 (assigning potential future meanings to certain bits if the value is within a specific range).</p>

<p>nTime: can be rolled within a window starting at the median of the past 11 blocks + 1 up to 7200 seconds in the future at the time the block is mined.</p>

CC BY-SA 4.0
2019-09-15T22:06:05.540Z
2019-09-15T22:06:05.540Z
Pieter Wuille
<p>In addition to the nonce and the Merkle Root, there are 4 other fields in the header - version, previous header hash, time and nbits.</p>

<p>Assuming a miner does not want to change the merkle root because of the additional computation involved, and obviously cannot change the previous header hash, to what extent are they able to change the version, time and/or nbits field to get additional nonce space? </p>

<mining-theory><block-header>
Which block header fields are miners able to change in an effort to avoid having to recalculate the Merkle Root?
Bradley Thomas
# Which block header fields are miners able to change in an effort to avoid having to recalculate the Merkle Root?

(Asked by: username_0 on 2019-09-15)

In addition to the nonce and the Merkle Root, there are 4 other fields in the header - version, previous header hash, time and nbits.

Assuming a miner does not want to change the merkle root because of the additional computation involved, and obviously cannot change the previous header hash, to what extent are they able to change the version, time and/or nbits field to get additional nonce space?

**Tags:** mining-theory, block-header


---

## 2 answers

### Answer by username_2 on 2019-09-15. Score: 7 | Accepted answer

nBits cannot be changed at all. Its value must equal the (compact encoding of) the target value for that block, which is determined entirely by the predecessors of the block. In other words, if the prevblock hash is given, so is nBits.

nVersion: can be modified arbitrarily, though its value is subject to interpretation under BIP34 (requiring it to be at least 2), BIP66 (requiring it to be at least 3), BIP65 (requiring it to be at least 4), and BIP9 (assigning potential future meanings to certain bits if the value is within a specific range).

nTime: can be rolled within a window starting at the median of the past 11 blocks + 1 up to 7200 seconds in the future at the time the block is mined.


---

### Answer by username_1 on 2019-09-15. Score: 6

**nTime**: blocks must have a higher timestamp than the median of the 11 previous blocks, and a lower timestamp than two hours in the future of the validating node's own clock. Assuming a regular block interval of ten minutes and a correctly set local time, the block can therefore be stamped between about one hour in the past and two hours in the future.

**nBits**: This encodes the block target (the reciprocal of the difficulty) and cannot be changed.

**nVersion**: The version field is 32 bits, and must be at least 2, 3 or 4 (i.e. the first three bits must be `010`, `011`, or `001` due to nVersion being encoded little endian). When using version 4 (`001…`) the remainder of the bits is defined by [BIP9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) which has attached meaning to some of the last few bits that have been previously used to signal activation of soft forks.
All remaining bits beside the above mentioned can be used to mutate the block header. They are for example used for "overt [ASICBOOST](https://bitcoin.stackexchange.com/q/43579/5406)"-style mining.

> **Comments:**
> **username_2**: Nit: BIP9 does not require the top bits to be 001; 011 and 010 are allowed as well, but no versionbits semantics are applied in that case (or in other words: using those prefix bits will be treated similar to 0010000...000).  
> **username_1**: @username_2: Thanks, issuing a correction.  

---

