0

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

Improve this question
1

I would start with

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.

Improve this answer
2
  • 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
    Aug 15 '21 at 16:50
  • The block needs to be valid, as well as meeting the proof of work requirements.
    – Claris
    Aug 15 '21 at 17:56
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.