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

<p>From <a href="http://webcache.googleusercontent.com/search?q=cache%3aFZ9pUxR3ldEJ%3ahttps://en.bitcoin.it/wiki/Block_hashing_algorithm&amp;hl=en&amp;strip=1">Wiki:Block hashing algorithm</a></p>

<blockquote>
  <p>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.</p>
</blockquote>

CC BY-SA 3.0
2011-10-28T01:22:20.953Z
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
CC BY-SA 3.0
2011-10-28T01:48:57.643Z
@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
CC BY-SA 3.0
2011-10-27T23:42:26.663Z
2011-10-27T23:48:14.487Z
2011-10-27T23:48:14.487Z
Serith
<p>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.</p>

<p>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. </p>

<p>Information on scalability issues for high transaction volume:</p>

<p><a href="https://bitcoin.stackexchange.com/questions/1708/capabilities-of-bitcoins-and-their-place-in-the-future">Capabilities of Bitcoins and their place in the future</a></p>

CC BY-SA 3.0
2015-05-28T04:07:31.713Z
_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
CC BY-SA 3.0
2015-05-28T15:46:09.527Z
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
CC BY-SA 3.0
2011-10-28T01:29:15.907Z
2011-10-28T13:23:52.037Z
2017-04-13T12:47:34.187Z
DeathAndTaxes
<p>From my last question:
<a href="https://bitcoin.stackexchange.com/questions/1747/bitcoin-block-size-what-are-the-rules">Bitcoin Block Size - What are the rules?</a></p>

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

<p>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?</p>

<block><blocksize>
Does block size effect Miner's Hashing speed?
Michael Pickens
# Does block size effect Miner's Hashing speed?

(Asked by: username_0 on 2011-10-27)

From my last question:
[Bitcoin Block Size - What are the rules?](https://bitcoin.stackexchange.com/questions/1747/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?

**Tags:** block, blocksize


---

## 2 answers

### Answer by username_1 on 2011-10-27. Score: 8

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

From [Wiki:Block hashing algorithm](http://webcache.googleusercontent.com/search?q=cache%3aFZ9pUxR3ldEJ%3ahttps://en.bitcoin.it/wiki/Block_hashing_algorithm&hl=en&strip=1)

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

> **Comments:**
> **username_2**: 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.  
> **username_3**: @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.  

---

### Answer by username_2 on 2011-10-28. Score: 5

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](https://bitcoin.stackexchange.com/questions/1708/capabilities-of-bitcoins-and-their-place-in-the-future)

> **Comments:**
> **username_4**: _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?  
> **username_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).  

---

