Understanding the Hash Function

Question

Can someone please explain in detail the components of the final hash that determines the winner of the block?

My understanding is that the miners are taking

1. The Merkle Root,
2. The time stamp,
3. The prior block's hash,
4. Some other components??, along with
5. A nonce that the miner's have to guess in order for the hash of all these components, using Sha256, to have at least 18 leading zeros.

My questions are:

1. Am I right in my understanding so far?

2. Can someone explain what the other components are and what order they are input into the hash function?

3. Using the data available on blockchain.info about each block, can I recreate the winning hash by inputing the same data into a Sha256 calculator?

Thanks.

Answer 1

You are very close. As Mesh already laid out, miners are hashing the following data:

• nVersion (e.g. 02000000)
• HashPrevBlock (this hash gets reversed, and then every two bytes are flipped)
• HashMerkleRoot (this hash gets reversed, and then every two bytes are flipped)
• nTime (must be converted to hex e.g 358b0553)
• nBits (target difficulty e.g 535f0119)
• nNonce (the random data)

This info can be found in the Bitcoin Developer Reference, or the PDF.

Now, to your third question, yes you can! I actually just built a little program in C# to do this yesterday! There is a little trickery to it, because you cant just plug the data straight into a hashing calculator and verify it. First, you append all of the fields together into a single string (after the hash reversing and flipping is done for the previous block hash, and merkle root). Then, you convert that string to binary data. At this point, you run the double SHA256 hash to verify that you get a valid hash of the block.

A helpful resource for you to check out it is Mining Bitcoin with pencil and paper as well as Bitcoin Wiki. Both resources have code samples that show this process in action.

Answer 2

From the Bitcoin.org Developer Documentation, a block header consists of a:

• Version
• Previous block header hash
• merkle root
• timestamp
• nBits field
• nonce

In that order. So as you say, the only component missing from your list is the version and the nBits field. The version is self explanatory, but the nBits field is not. What the nBits field does is encode the current target for the difficulty algorithm:

to have at least 18 leading zeros.

Not always 18 zeroes. The number of leading zeros changes based on how quickly blocks have been found recently, in order to keep the block time at roughly 10 minutes average despite varying hashpower on the network. As more miners join, the hashrate increases, so the difficulty does too (i.e. more zeroes are required). Another way to think about the 0's, is that the output of the SHA256, as a number, must be less than some target number. That target is encoded in the nBits field. And yes, anyone can verify that the block header hashes to a number below the target, that is how other clients verify blocks are valid, because SHA256 always produces the same output from the same input - it is deterministic, a property of all useful hash functions.