Author

Topic: 1 Mbyte block limit? Apparently not in practice! (Read 902 times)

full member
Activity: 136
Merit: 100
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).
legendary
Activity: 3583
Merit: 1094
Think for yourself
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
full member
Activity: 136
Merit: 100
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.
Jump to: