user124926: 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)?

user13866: 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.

user24925: 
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.

124926: <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>
 13866: <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>
 24925: <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>
