Bitcoin Forum
October 20, 2018, 11:49:42 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: 1 Mbyte block limit? Apparently not in practice!  (Read 776 times)
davejh
Full Member
***
Offline Offline

Activity: 138
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.
1540036182
Hero Member
*
Offline Offline

Posts: 1540036182

View Profile Personal Message (Offline)

Ignore
1540036182
Reply with quote  #2

1540036182
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2674
Merit: 1144


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 and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
os2sam
Legendary
*
Offline Offline

Activity: 2478
Merit: 1001


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
Full Member
***
Offline Offline

Activity: 138
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:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!