From my last question: Bitcoin Block Size - What are the rules?

I learned that the block size can vary from a few kB up to a MB. This leads to my next question:

Does the block size effect a miner's hashing speed? (i.e does a very large block decrease hashing speed?) If so, what are the details of that relationship?


Only block header gets hashed, and it has fixed size, so the total block size doesn't matter.

From Wiki:Block hashing algorithm

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

| improve this answer | |
  • 1
    That is not correct. The transactions of the block have to be hashed to create the merkle tree. More transactions means a larger merkle tree consisting of more hashes. – DeathAndTaxes Oct 28 '11 at 1:22
  • 1
    @theUnhandledException That's a small one-time cost on adding transactions, though. Bitcoin will start requiring fees before the cost of these hashes becomes substantial. – theymos Oct 28 '11 at 1:48

While the block header is always the same size, one component of the block header is the Merkle Root which changes with each included transaction. The Merkle Root is a hash based on a Merkle Tree of all the transactions of the block. Creating the Merkle Tree requires 2(n-1)+1 hashes. The Merkle tree will need to be updated periodically to include new transactions as they occur.

To save computing power in pool mining the pool server computes the Merkle Root and then provides it to all miners in the pool. In solo mining each miner will need to compute and update the Merkle Root. Current transaction volume is relatively low so the amount of computing power required to update the Merkle tree isn't significant. However if Bitcoin ever reached VISA level transaction volume (~4000 transactions per second) computing the Merkle tree would require significant computing power, possibly even dedicated CPU/GPU acceleration just for Merkle tree calculation.

Information on scalability issues for high transaction volume:

Capabilities of Bitcoins and their place in the future

| improve this answer | |
  • To save computing power in pool mining the pool server computes the Merkle Root and then provides it to all miners in the pool. But each miner participating in the pool works on a unique share. Thus, a 4 TH/s miner exhausts the entire nonce range in about 1/1000th of a second, requiring 1000 shares (each with a unique extranonce) per second, correct? That's quite a lot of times the pool server would need to change the extranonce and update the Merkle root, just for shares intended for one pool participant. Multiply that by 1000 participants, and you need a lot of computing power, no? – Geremia May 28 '15 at 4:07
  • 2
    The answer was written in 2011 (although it would still work today if the nonce range was 64 bit). Today (2015) no pool uses this method. Instead the provide each miner with a partial merkle tree, the static elements of the coinbase txn, and the rest of the header. The miner adds the extra nonce to the coinbase txn, computes the merkle root hash, sets dynamic values in header (like timestamp) and passes that to the ASIC hardware as a binary blob. Most ASICs reduce the precomputaiton workload somewhat by cheating a bit on timestamps (get another 4 bill tries by incrementing timestamp). – DeathAndTaxes May 28 '15 at 15:46

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.