<p>Great question. I had to do some research to find out.</p>

<p>Currently version is actually 4 bytes. In the case of this block (and many other recent blocks, as it turns out) it's <code>01000020</code>. This is little endian, so when you reverse the bytes in hex it's:</p>

<pre><code>0x20000001 = 536870913
</code></pre>

<p>Which in binary is:</p>

<pre><code>00100000000000000000000000000001
</code></pre>

<p>It turns out that the bits here follow the <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="nofollow">BIP0009 spec</a>. You can get a more user-friendly explanation of <a href="https://rusty.ozlabs.org/?p=576" rel="nofollow">BIP0009 here</a>. Essentially, BIP0009 specifies that version bits are to be used to signal support for a soft-fork. In this particular case by using that that extra "1" at the end, the miner that mined this block is expressing support for <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="nofollow">BIP0112</a> otherwise known as OP_CHECKSEQUENCEVERIFY.</p>

CC BY-SA 3.0
2016-06-20T22:25:59.990Z
2016-06-20T22:25:59.990Z
Jimmy Song
<p>I've been looking at the version numbers of blocks, but I'm getting strange results from <strong>bitcoin-cli getblock</strong>.</p>

<pre><code>"version": 536870913
</code></pre>

<p>However, when I run the same command with the <code>false</code> option (to get the serialized block data), it shows a version number of <code>1</code>:</p>

<pre><code> "result": "010000 ...
</code></pre>

<p>Why is this happening?</p>

<hr>

<p>Example: <a href="https://chainquery.com/bitcoin-api/getblock/0000000000000000054AFA8DDFAE5908D9FE2DC157FD137C03F71C87439BCB6D/false" rel="nofollow">https://chainquery.com/bitcoin-api/getblock/0000000000000000054AFA8DDFAE5908D9FE2DC157FD137C03F71C87439BCB6D/false</a></p>

<block-header><bitcoin-cli>
Why does bitcoin-cli return strange version numbers for blocks?
inersha
# Why does bitcoin-cli return strange version numbers for blocks?

(Asked by: username_0 on 2016-06-15)

I've been looking at the version numbers of blocks, but I'm getting strange results from **bitcoin-cli getblock**.

```
"version": 536870913

```

However, when I run the same command with the `false` option (to get the serialized block data), it shows a version number of `1`:

```
 "result": "010000 ...

```

Why is this happening?

---

Example: <https://chainquery.com/bitcoin-api/getblock/0000000000000000054AFA8DDFAE5908D9FE2DC157FD137C03F71C87439BCB6D/false>

**Tags:** block-header, bitcoin-cli


---

## 1 answers

### Answer by username_1 on 2016-06-20. Score: 4 | Accepted answer

Great question. I had to do some research to find out.

Currently version is actually 4 bytes. In the case of this block (and many other recent blocks, as it turns out) it's `01000020`. This is little endian, so when you reverse the bytes in hex it's:

```
0x20000001 = 536870913

```

Which in binary is:

```
00100000000000000000000000000001

```

It turns out that the bits here follow the [BIP0009 spec](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki). You can get a more user-friendly explanation of [BIP0009 here](https://rusty.ozlabs.org/?p=576). Essentially, BIP0009 specifies that version bits are to be used to signal support for a soft-fork. In this particular case by using that that extra "1" at the end, the miner that mined this block is expressing support for [BIP0112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) otherwise known as OP\_CHECKSEQUENCEVERIFY.


---

