https://en.bitcoin.it/wiki/Block_hashing_algorithm said this about the block header:

"Given just those fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win."

But isn't that exactly what we want?

So, they use the merkleRoot which makes the header nearly unique and "Every hash you calculate has the same chance of winning as every other hash calculated by the network."

I guess this change makes CPU speed less important, but not much less important. How much less important is CPU speed (or even network latency) with the addition of the merkleRoot to the block header?

2 Answers 2


I think you might have misinterpreted the article. The MerkelRoots is a representation of all the transaction in the block that you're currently trying to mine. They are unique because the first transaction in each block is unique to each miner. The uniqueness guarantees that the sequence of generated hashes will be different for each miner. And because of this uniqueness, the sequence of hashes generated by a low-powered CPU might occasionally lead to the desired result before a high-powered monster CPU does, whereas if everyone were following the same sequence, the high-powered monster CPU would always find the desired result first. So in essence, the first transaction introduces uniqueness that makes CPU speed less important and not the MerkelRoot.

Incidentally, I had almost finished answering the question in a completely different way when I realized the confusion. In case that answer is helpful, here it is ...

In mining, you're constantly changing a block (by updating the nonce) and trying to find a hash that meets the proper requirements. You're also changing the transactions in a block, (which also changes it's hash), but this happens much less frequently. Hashing the entire block is an expensive operation, but hashing only a small part is not as expensive. Since you're changing the transactions -- by far the largest part -- much less frequently than the nonce, it makes sense to "cache" the change so that the mining hash operation doesn't take so many resources.

The Merkle Root is this cache, that is, it [compactly] represents any changes in the list of transactions. Thus when you hash the header (which includes any change in the nonce or the transaction), you are still hashing the entire block.

Assuming that CPUs scale linearly, the answer to your question about how much less important CPU speed is disappointingly probably not at all. The benefit that you get is that any CPU will be able to calculate more hashes per second than with the alternative, and this should be proportional to the CPU's power/clock-speed.

You also mentioned network latency, but as all of the hashing takes place on individual computers and full transactions are sent throughout the network, whether or not a Merkel Root is used wouldn't affect network traffic.


Let's say there are three miners on the network, with hashrates of 4 GH/s, 3 GH/s and 3 GH/s.

With random behavior of blocks, 40% of blocks will be found by the first miner, 30% by the second, and 30% by the third.

Without random behavior, 100% of blocks will be found by the first miner. This is bad for several reasons:

  1. Synchronization power is solely at the hands of the first miner, so he can attack the network even without majority hashrate.

  2. Generated bitcoins will be given solely to the first miner, creating a perverse economic structure.

  3. Since small miners get nothing, there is a huge barrier of entry, so most people will not bother mining, making the problem even worse.

We want that what everyone gets is proportional to what he gives. Not that one party will get everything.

  • This of course assumes that all miners start with nonce 0x00000000 and increment from there, if they were to start hashing from random nonces and wrap around, the odds would likely even out again.
    – cdecker
    Commented Aug 29, 2013 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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