Mining for nil-transaction blocks only - gaming the incentive scheme by rogue miners / consortium?

3

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) 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?

Tom Hale

Posted 2015-11-16T15:58:29.703

Reputation: 171

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 – 2015-11-16T18:15:46.843

I'm accepting Nick's as the answer as it addresses my question as a whole, but any ideas on Question 3? – Tom Hale – 2015-11-17T11:39:13.407

Answers

3

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

Nick ODell

Posted 2015-11-16T15:58:29.703

Reputation: 27 521