Bitcoin Forum
May 05, 2024, 08:35:59 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: 1 Mbyte block limit? Apparently not in practice!  (Read 882 times)
davejh (OP)
Full Member
***
Offline Offline

Activity: 136
Merit: 100


View Profile
January 19, 2015, 03:13:46 AM
 #1

I've been wondering about all of those 731k blocks being mined so decided to do a little more analysis.

http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block

This looks back at the last 2 years based on the block sizes being mined by various pools. The results were somewhat surprising. In practice even though the protocol allows for 1M byte blocks the mining pools collective behaviour imposes much lower limits.
1714941359
Hero Member
*
Offline Offline

Posts: 1714941359

View Profile Personal Message (Offline)

Ignore
1714941359
Reply with quote  #2

1714941359
Report to moderator
1714941359
Hero Member
*
Offline Offline

Posts: 1714941359

View Profile Personal Message (Offline)

Ignore
1714941359
Reply with quote  #2

1714941359
Report to moderator
1714941359
Hero Member
*
Offline Offline

Posts: 1714941359

View Profile Personal Message (Offline)

Ignore
1714941359
Reply with quote  #2

1714941359
Report to moderator
The forum was founded in 2009 by Satoshi and Sirius. It replaced a SourceForge forum.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
-ck
Legendary
*
Offline Offline

Activity: 4102
Merit: 1632


Ruu \o/


View Profile WWW
January 19, 2015, 03:45:32 AM
 #2

Many pools customise their block sizes, some with bullshit optimisations of zero transaction blocks either intermittently or always, and some with selective censorship of entities they don't like. Even if they don't customise their block size, the default in bitcoind is 750kb. Both ckpools (solo and kano.is) are using larger max block sizes and have mined blocks larger than 900kb in size.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
os2sam
Legendary
*
Offline Offline

Activity: 3578
Merit: 1090


Think for yourself


View Profile
January 19, 2015, 04:03:33 AM
 #3

Many pools customise their block sizes, some with bullshit optimisations of zero transaction blocks either intermittently or always, and some with selective censorship of entities they don't like. Even if they don't customise their block size, the default in bitcoind is 750kb. Both ckpools (solo and kano.is) are using larger max block sizes and have mined blocks larger than 900kb in size.

How often is a block size that large needed?  I doubt that every block has 900Kb+ transactions waiting to be processed.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
davejh (OP)
Full Member
***
Offline Offline

Activity: 136
Merit: 100


View Profile
January 19, 2015, 04:31:39 AM
 #4

Many pools customise their block sizes, some with bullshit optimisations of zero transaction blocks either intermittently or always, and some with selective censorship of entities they don't like. Even if they don't customise their block size, the default in bitcoind is 750kb. Both ckpools (solo and kano.is) are using larger max block sizes and have mined blocks larger than 900kb in size.

How often is a block size that large needed?  I doubt that every block has 900Kb+ transactions waiting to be processed.

Not every block does. We're steadily moving towards a larger mean size though, which is why if you look at the first graph in the article you'll see that just before the end of last year we had a week that had a mean block size of 400k bytes. Given that the arrival of transactions is quite random and that block finding is also quite random, however, that means that we have more than 1M bytes of transactions pending quite a few times on most days; that's why the mean first confirmation time starts to drift out once we're above about 30% block utilisation.

As I noted, Discuss Fish (F2Pool) frequently mine blocks of just under 1M bytes, but in practice many pools will use lower limits because it's in their interest to do so. If you have very low latency to the rest of the network then larger blocks aren't so much of a problem; if you don't have insanely great latency though then larger blocks make it more likely that your blocks will be orphaned. Given that Block rewards per day are about 3600 BTC and fees are about 15 BTC then this means that even losing 1 in 240 orphan races makes choosing fees over block rewards a bad idea for pools (unless you're a pool where the operator keeps the fees :-)).

The problem (for pools and miners) is that if the block size were to become effectively unlimited then there would be no incentive for anyone to assign reasonable transaction fees (tragedy of the commons says that you'd have to take any fee, no matter how low, because someone else will take it in the next block if you don't - if block space is scarce though then low fee transactions will get delayed until there's space for them).
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!