user24926: 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

user23123: 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. You can get a more user-friendly explanation of BIP0009 here. 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 otherwise known as OP_CHECKSEQUENCEVERIFY.

24926: <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>
 23123: <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>
