Bitcoin Forum
June 18, 2024, 12:48:56 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How are block sizes determined?  (Read 549 times)
AgentVenom (OP)
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
July 22, 2015, 06:27:23 AM
 #1

How do miners chose how big they want their blocks? What are the advantages and risks of big blocks? What are the advantages and risks of small blocks? Thanks in advance.
randy8777
Legendary
*
Offline Offline

Activity: 896
Merit: 1000


View Profile
July 22, 2015, 09:21:19 AM
 #2

i think it is purely based on the fee that is included in the transactions. transactions with the highest fees get included first, possibly causing "less important" transactions to wait for the next block.
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2965


Terminated.


View Profile WWW
July 22, 2015, 11:07:44 AM
 #3

It really depends on the configuration of the pool at they are mining on. As far as I know, they can change the max size of their blocks with software (i.e. include less transactions).
Short version: Bigger blocks simply give bigger miners an financial advantage. To understand this properly you have to understand how the network works. Let's say that Miner X finds a new block and sends it to their peers and starts working on finding another block (after that one). Now the peers have to receive and validate that block, then relay it to other peers and start mining. The original miner was already working during this whole process, which gives him a advantage.

You would have to do a lot of research and calculations to figure out exactly how much advantage this is.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
AgentVenom (OP)
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
July 23, 2015, 12:42:46 AM
 #4

It really depends on the configuration of the pool at they are mining on. As far as I know, they can change the max size of their blocks with software (i.e. include less transactions).
Short version: Bigger blocks simply give bigger miners an financial advantage. To understand this properly you have to understand how the network works. Let's say that Miner X finds a new block and sends it to their peers and starts working on finding another block (after that one). Now the peers have to receive and validate that block, then relay it to other peers and start mining. The original miner was already working during this whole process, which gives him a advantage.

You would have to do a lot of research and calculations to figure out exactly how much advantage this is.

Thanks, that's very informative. I was just asking in a general sense. I knew that the propagation of a block was to be considered in the block size debate, so that got me wondering. Also, is there any general disadvantage to mining (or setting up your miners/pool to mine) small blocks?
notlist3d
Legendary
*
Offline Offline

Activity: 1456
Merit: 1000



View Profile
July 23, 2015, 03:30:45 AM
 #5

Here is a good article that is still kinda recent as far as block size.  These pools are around 50-60 percent of the network and worked together as far as size.  So nice to see them work together.

http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
DannyHamilton
Legendary
*
Offline Offline

Activity: 3430
Merit: 4668



View Profile
July 23, 2015, 02:43:52 PM
 #6

- 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?
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!