<p>I would start with</p>
<ul>
<li><a href="https://developer.bitcoin.org/reference/block_chain.html" rel="nofollow noreferrer">https://developer.bitcoin.org/reference/block_chain.html</a> and</li>
<li><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> and</li>
<li><a href="https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/" rel="nofollow noreferrer">https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/</a></li>
</ul>
<p>The first reference above says</p>
<blockquote>
<p>As of this writing, a newer method called version bits is being designed to manage future soft forking changes, although it’s not known whether version 4 will be the last soft fork to use the IsSuperMajority() function. Draft BIP9 describes the version bits design as of this writing, although it is still being actively edited and may substantially change while in the draft state.</p>
</blockquote>
<p>The second reference starts</p>
<blockquote>
<p>This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called &quot;soft forks&quot;) to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a &quot;fallow&quot; pause after which the bit can be reused for later changes.</p>
</blockquote>
<p>The third reference explains this in a simpler way. AFAIK each bit signals miner readiness for a current soft-fork proposal.</p>
<p>You example decimal 545259524 is Hex 0x20800004 or binary 00100000100000000000000000000100</p>
<p>So there are extra two bits set (the first one in 0x20 is standard AIUI) and therefore readiness for two soft-forks being signalled.</p>
<p>I don't know of a web-page that tracks current bit meanings, linking a bit to relevant BIPs. <a href="https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki</a> seems out of date to me.</p>

CC BY-SA 4.0
2021-08-15T16:50:10.797Z
thank you. But I am unsure what all that means for a miner. I mean all that he/she is doing is creating a Block that passes the difficulty. So how is the future fork protocol etc. relevant to the current block being mined? Unless the structure of the Block depend on the Block Version? And is there a default value one can use so that the block structure is automatically correct?
J.Doe
CC BY-SA 4.0
2021-08-15T17:56:29.160Z
The block needs to be valid, as well as meeting the proof of work requirements.
Claris
CC BY-SA 4.0
2021-08-15T16:14:21.590Z
2021-08-15T16:43:30.630Z
2021-08-15T16:43:30.630Z
RedGrittyBrick
<blockquote>
<p>The Version, Time, Bits and Nonce fields don't seem to match in size. What am I interpreting wrong here.</p>
</blockquote>
<p>The quoted example is a numerical (base 10) representation, which is not the way that numbers are stored in the binary format.</p>

CC BY-SA 4.0
2021-08-15T16:29:03.907Z
2021-08-15T16:29:03.907Z
Claris
<p>I am new to Bitcoins and still learning thus please bear with me. As I read Bitcoin Block header (on which the Block Hash is computed) is supposed to be:</p>
<ul>
<li>hash - 32 Bytes</li>
<li>ver  - 4 Bytes</li>
<li>prev_block - 32 Bytes</li>
<li>mrkl_root  - 32 Bytes</li>
<li>time  - 4 Bytes</li>
<li>bits  - 4 Bytes</li>
<li>nonce - 4 Bytes</li>
</ul>
<p>(source: <a href="https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html" rel="nofollow noreferrer">https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html</a>)</p>
<p>Now when I check one of the latest Blocks the fields are:</p>
<ul>
<li><p>Hash   :
00000000000000000009ec0aa4de1488fa1ea7a5196447016b2fe1638df99e62</p>
</li>
<li><p>Version :  545259524</p>
</li>
<li><p>Previous Block : 000000000000000000073a6f31ebaeeaaf09e21331450e424426818699356c54</p>
</li>
<li><p>Merkel Root    : 09f73d4315fcff0f7ef126a321e8ea478a9bab26c6aa6d45c187a0fcb313fab8</p>
</li>
<li><p>Time  :  1629026224</p>
</li>
<li><p>Bits  :  387061771</p>
</li>
<li><p>Nonce :  1150639194</p>
</li>
</ul>
<p>(source: <a href="https://blockchain.info/rawblock/695877" rel="nofollow noreferrer">https://blockchain.info/rawblock/695877</a>)</p>
<p>The Version, Time, Bits and Nonce fields don't seem to match in size. What am I interpreting wrong here.</p>
<p>And I am unclear about the Version field. What are the various options. And hypothetically as a miner if one runs a tailor made self coded program what should be its value and how does it matter to a miner who will simply mine a new Block? Is there a default safe value for this field?</p>
<p>It would be helpful if someone can point to a explained for version (something that is easy and comprehensive enough for beginning miners)?</p>

CC BY-SA 4.0
2022-07-26T16:02:45.503Z
The number 545259524 for version is in base-10 (decimal) format, you need to convert it to base-16 (hexadecimal, ie 20800004) and then reverse the order of bytes (04008020) to compose the header.  You can use an online tool to convert decimal to hexadecimal numbers.
andrewz
<block-header>
A query regarding Bitcoin Header Format
J.Doe
# A query regarding Bitcoin Header Format

(Asked by: username_0 on 2021-08-15)

I am new to Bitcoins and still learning thus please bear with me. As I read Bitcoin Block header (on which the Block Hash is computed) is supposed to be:

* hash - 32 Bytes
* ver - 4 Bytes
* prev\_block - 32 Bytes
* mrkl\_root - 32 Bytes
* time - 4 Bytes
* bits - 4 Bytes
* nonce - 4 Bytes

(source: <https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html>)

Now when I check one of the latest Blocks the fields are:

* Hash :
  00000000000000000009ec0aa4de1488fa1ea7a5196447016b2fe1638df99e62
* Version : 545259524
* Previous Block : 000000000000000000073a6f31ebaeeaaf09e21331450e424426818699356c54
* Merkel Root : 09f73d4315fcff0f7ef126a321e8ea478a9bab26c6aa6d45c187a0fcb313fab8
* Time : 1629026224
* Bits : 387061771
* Nonce : 1150639194

(source: <https://blockchain.info/rawblock/695877>)

The Version, Time, Bits and Nonce fields don't seem to match in size. What am I interpreting wrong here.

And I am unclear about the Version field. What are the various options. And hypothetically as a miner if one runs a tailor made self coded program what should be its value and how does it matter to a miner who will simply mine a new Block? Is there a default safe value for this field?

It would be helpful if someone can point to a explained for version (something that is easy and comprehensive enough for beginning miners)?

**Tags:** block-header

> **Comments:**
> **username_1**: The number 545259524 for version is in base-10 (decimal) format, you need to convert it to base-16 (hexadecimal, ie 20800004) and then reverse the order of bytes (04008020) to compose the header.  You can use an online tool to convert decimal to hexadecimal numbers.  

---

## 2 answers

### Answer by username_2 on 2021-08-15. Score: 1 | Accepted answer

I would start with

* <https://developer.bitcoin.org/reference/block_chain.html> and
* <https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki> and
* <https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/>

The first reference above says

> As of this writing, a newer method called version bits is being designed to manage future soft forking changes, although it’s not known whether version 4 will be the last soft fork to use the IsSuperMajority() function. Draft BIP9 describes the version bits design as of this writing, although it is still being actively edited and may substantially change while in the draft state.

The second reference starts

> This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.

The third reference explains this in a simpler way. AFAIK each bit signals miner readiness for a current soft-fork proposal.

You example decimal 545259524 is Hex 0x20800004 or binary 00100000100000000000000000000100

So there are extra two bits set (the first one in 0x20 is standard AIUI) and therefore readiness for two soft-forks being signalled.

I don't know of a web-page that tracks current bit meanings, linking a bit to relevant BIPs. <https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki> seems out of date to me.

> **Comments:**
> **username_0**: thank you. But I am unsure what all that means for a miner. I mean all that he/she is doing is creating a Block that passes the difficulty. So how is the future fork protocol etc. relevant to the current block being mined? Unless the structure of the Block depend on the Block Version? And is there a default value one can use so that the block structure is automatically correct?  
> **username_3**: The block needs to be valid, as well as meeting the proof of work requirements.  

---

### Answer by username_3 on 2021-08-15. Score: 1

> The Version, Time, Bits and Nonce fields don't seem to match in size. What am I interpreting wrong here.

The quoted example is a numerical (base 10) representation, which is not the way that numbers are stored in the binary format.


---

