- snip -
is there any general disadvantage to mining (or setting up your miners/pool to mine) small blocks?
- snip -
The block header is 80 bytes, and at a minimum a block MUST also have the generation transaction (also called a "coinbase transaction" or a "block reward transaction"). I think the smallest generation transaction is right around 120 bytes (124?), so the smallest blocks will be approximately 200 bytes.
As may already be clear from the multitude of threads discussing max block size, there is currently a protocol limit of 1 megabyte on the maximum size of a block.
A solo miner (or mining pool) is free to choose any size they like between those limits, and they can base their decision on any thing they like.
Realistically, any solo miner (or mining pool) that wants to maximize profits will be weighing a few variables in their decision about the size of the block that they will create.
Since the mining operation receives the transaction fees of every transaction that they include in their block, there is a financial incentive to include as many of the highest fee transactions as possible in the block.
However, if a block takes too long to propagate through the network to all the other solo miners and mining pools, there is a risk that some other miner may have solved a smaller block (which will propagate faster) at nearly the same time. This increases the risk that the larger block will be orphaned and that the miner (or pool) will lose out on the entire reward (block subsidy + fees).
So, a mining operation can increase their potential revenue by collecting fees from more transactions, but only by increasing their risk of losing the entire reward. Each operation makes their own decisions about how what fees are large enough to compensate for the increased orphan risk.
Additionally very large blocks mean that the mining operations with the most hash power and the fastest internet connections can create a burden on smaller operations with slower internet. This burden means that the smaller operation must choose between three unpleasant options that put them at a disadvantage and can reduce their revenue to unprofitable levels:
- They can download and validate the entire huge block (while the larger operation is already working to solve the next block)
- They can ignore the large block and hope that they (or some other small miner) can solve and propagate a pair of smaller blocks before a new block is solved on top of the huge block
- They can assume that the huge block is valid and immediately begin mining on top of that block's hash
Clearly the first option means that the larger operation will solve more blocks and will increase their revenue, while the smaller operation may need to shut down due to costs exceeding revenue. Over time this would seem to result in just 1 or 2 extremely large mining pools forcing all other pools and solo miners out of business.
The second option results in a very large number of blocks from the smaller operations being orphaned. As such they will frequently spend a lot of resources on solving a block that never makes it into the blockhcain and for which they will not receive a block reward. Again the larger operation will solve more blocks and will increase their revenue, while the smaller operation may need to shut down due to costs exceeding revenue. Over time this would seem to result in just 1 or 2 extremely large mining pools forcing all other pools and solo miners out of business.
The third option leaves the smaller operation open to an attack whereby a peer relays a fake huge block with an invalid hash. Since the smaller operation is not verifying the block and hash, they waste resources attempting to mine a block that won't be valid. Again the larger operation will solve more blocks and will increase their revenue, while the smaller operation may need to shut down due to costs exceeding revenue. Over time this would seem to result in just 1 or 2 extremely large mining pools forcing all other pools and solo miners out of business.
So, while larger blocks mean that there is room for more transactions in any given amount of time, it also increases the risk that mining operations will be consolidated into just a couple of extremely large pools that will have significant control over the confirmation process and that will have very little competition.
The question is: what is the "correct" limit on maximum block size? I suspect that we could get a strong super-majority of knowledgeable people to agree that 400 bytes is
TOO SMALL as a maximum allowed size. I also suspect that we could get a strong super-majority of knowledgeable people to agree that 1 tera-byte is
TOO LARGE as a maximum allowed size. I would hope that somewhere between those extremes is a range that would work well (a reasonable amount of transactions handled, while not creating an unreasonable burden on smaller nodes and mining operations). Is there any reason to believe that 1 megabyte is the EXACT and ONLY acceptable value for that limit? If some other limit would be better, how can that value (or range) be reliably determined?