<p>(I'm certain this has been asked before, but I can't find the previous question.)</p>

<p>That would be true, except for the presence of the nonce and extraNonce fields. The point of these fields is that you can rehash the block without actually hashing the whole thing. On 2^32-1 out of 2^32 times, that just means hashing the last 16 bytes of block header, which can be done in 3 compressions. (That's one for the block header, and two for the following SHA256 hash. Remember, Bitcoin uses SHA256d.)</p>

<p>A single mining attempt takes (3 + ((log(2, number_of_transactions) + 1) * 2 / 2**32)) SHA256 compressions, on average. Having a thousand transactions in the block takes an extra 0.000000004 compressions per hash over having no transactions in the block.</p>

<p>The effect of all of that is that you mine at essentially the same speed no matter how many transactions you include.</p>

CC BY-SA 3.0
2015-11-16T16:25:05.393Z
2015-11-17T03:06:11.183Z
2015-11-17T03:06:11.183Z
Nick ODell
<p>I understand that there is incentive to include transactions where the output is less than the input so that the block creator can pocket the difference. But I'm wondering if that is really worthwhile in terms of hashing rate?</p>

<p>I know that overall having transactions is a good thing for the currency, but what if a particular miner only cares about their block finder's reward?</p>

<p>This is my understanding of the hashing process:
<a href="https://i.sstatic.net/29Ts2.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/29Ts2.png" alt="SHA256 process (image from Coursera Bitcoin course)"></a>
SHA256 process (image from Coursera Bitcoin course)</p>

<p>The hash input is split into 512-bit input-blocks, and then the compression function (in yellow) is run once for each input-block (including the output of the previous result).</p>

<p>Assuming that the smallest possible bitcoin-block is &lt; 1024 bits (please correct me if I'm off), then hashing for no transactions will take 4 compressions.</p>

<p>AFAIK, the largest block size is 1MiB, or 8,000,000 bits, requiring 15,625 compression functions, more than 3,900 times longer than for a nil-transactions block.</p>

<ol>
<li><p>Will it will take about 3,900 times as long to hash a 1MiB block as to hash a nil-transaction block?</p></li>
<li><p>If this is correct within an order of magnitude, then wouldn't it be better to increase the probability of finding a block approx. 3,000 times rather than collecting one block's worth of transaction processing reward?</p></li>
<li><p>What is the average transaction fee collection per block?</p></li>
<li><p>What if a small consortium of miners took up this strategy for personal profit, riding on the backs of the miners who cared about the ecosystem as a whole and kept it afloat?</p></li>
</ol>

CC BY-SA 3.0
2015-11-16T18:15:46.843Z
If 1. were true, Bitcoin probably wouldn't work. Besides Nick's answer below, note that all the pre-work can be done in parallel. In fact, that's usually done by CPU, so only a small piece of data needs to be loaded into the ASICs.
Jannes
CC BY-SA 3.0
2015-11-17T11:39:13.407Z
I'm accepting Nick's as the answer as it addresses my question as a whole, but any ideas on Question 3?
Tom Hale
<transactions><block><mining-reward><mining-profitability><sha256>
Mining for nil-transaction blocks only - gaming the incentive scheme by rogue miners / consortium?
Tom Hale
# Mining for nil-transaction blocks only - gaming the incentive scheme by rogue miners / consortium?

(Asked by: username_0 on 2015-11-16)

I understand that there is incentive to include transactions where the output is less than the input so that the block creator can pocket the difference. But I'm wondering if that is really worthwhile in terms of hashing rate?

I know that overall having transactions is a good thing for the currency, but what if a particular miner only cares about their block finder's reward?

This is my understanding of the hashing process:
[![SHA256 process (image from Coursera Bitcoin course)](https://i.sstatic.net/29Ts2.png)](https://i.sstatic.net/29Ts2.png)
SHA256 process (image from Coursera Bitcoin course)

The hash input is split into 512-bit input-blocks, and then the compression function (in yellow) is run once for each input-block (including the output of the previous result).

Assuming that the smallest possible bitcoin-block is < 1024 bits (please correct me if I'm off), then hashing for no transactions will take 4 compressions.

AFAIK, the largest block size is 1MiB, or 8,000,000 bits, requiring 15,625 compression functions, more than 3,900 times longer than for a nil-transactions block.

1. Will it will take about 3,900 times as long to hash a 1MiB block as to hash a nil-transaction block?
2. If this is correct within an order of magnitude, then wouldn't it be better to increase the probability of finding a block approx. 3,000 times rather than collecting one block's worth of transaction processing reward?
3. What is the average transaction fee collection per block?
4. What if a small consortium of miners took up this strategy for personal profit, riding on the backs of the miners who cared about the ecosystem as a whole and kept it afloat?

**Tags:** transactions, block, mining-reward, mining-profitability, sha256

> **Comments:**
> **username_1**: If 1. were true, Bitcoin probably wouldn't work. Besides username_2's answer below, note that all the pre-work can be done in parallel. In fact, that's usually done by CPU, so only a small piece of data needs to be loaded into the ASICs.  
> **username_0**: I'm accepting username_2's as the answer as it addresses my question as a whole, but any ideas on Question 3?  

---

## 1 answers

### Answer by username_2 on 2015-11-16. Score: 4 | Accepted answer

(I'm certain this has been asked before, but I can't find the previous question.)

That would be true, except for the presence of the nonce and extraNonce fields. The point of these fields is that you can rehash the block without actually hashing the whole thing. On 2^32-1 out of 2^32 times, that just means hashing the last 16 bytes of block header, which can be done in 3 compressions. (That's one for the block header, and two for the following SHA256 hash. Remember, Bitcoin uses SHA256d.)

A single mining attempt takes (3 + ((log(2, number\_of\_transactions) + 1) \* 2 / 2\*\*32)) SHA256 compressions, on average. Having a thousand transactions in the block takes an extra 0.000000004 compressions per hash over having no transactions in the block.

The effect of all of that is that you mine at essentially the same speed no matter how many transactions you include.


---

