BIP 101 : maximum block size increase #163

Proposal to increase maximum possible block size, starting at 8MB in January 2016 and increasing on-pace with technological growth to 8,192MB in twenty years.

If Bitcoin goes viral in 2017 8 MB blocks will still not be enough. We need a permanent solution.

This is what Vitalik Buterin has proposed: "Initialize at 1 MB, target 2x exponential moving average of the last 1000 blocks."

I would very much like to know Gavin's opinion on dynamic block-size limits. The mechanism for adjusting network difficulty seems to work well despite being something that impacts miner incentives very directly and there is a strong temptation to attempt to game it.

@flix1, you're talking about a completely different solution. I suggest you do a full write up and code like BIPS 100 and 101.

ACK

Looks good to me. Can't wait.

Fixed typos / broken links found by @C-Otto (thanks!).

@flix1 : dynamic limits are harder to implement-- I volunteered to help @jgarzik implement BIP100, and when diving into actually coding it up, the combination of headers-first and out-of-order block fetching makes any dynamic limit based on previous block sizes or votes in coinbase transactions non-trivial because the max block size may not be known when the block data is received.

That's not a show-stopper problem: a 'maximum feasible block size' could be used for initial denial-of-service checks on 'block' message size based on the block height, with a tighter check on size done when all previous blocks have been downloaded and validated and the block is added to the chain.

But it is much simpler if the max size is a pure function based on data in the block header.

On Wed, Jul 15, 2015 at 11:30 AM, Gavin Andresen notifications@github.com wrote:

@flix1 https://github.com/flix1 : dynamic limits are harder to implement-- I volunteered to help @jgarzik https://github.com/jgarzik implement BIP100, and when diving into actually coding it up, the combination of headers-first and out-of-order block fetching makes any dynamic limit based on previous block sizes or votes in coinbase transactions non-trivial because the max block size may not be known when the block data is received.

That's surprising to me. In headers-first we never receive/process full block data before all headers leading up to it are known, so you can just check the block size in AcceptBlock, before it is stored on disk.

If you're talking about doing an early check while receiving the block data... I'm not sure why that matters. If an attack exists for receiving large blocks, an attacker can just wait until you've caught up and are willing to receive them. So I think the "early check" should just tolerate whatever the limit is the software can deal with, independent of time. The accurate consensus check can be in AcceptBlock.

@gavinandresen Actually over the past weeks I've given this a lot of thought and I've come around to see your solution as the best. A purely mathematical rule keeps it simple. Targeting Moore's law is reasonable.

It will also be easier to reach a very broad consensus for something straightforward.

On Wed, Jul 15, 2015 at 12:12 PM, flix1 notifications@github.com wrote:

@gavinandresen https://github.com/gavinandresen Actually over the past weeks I've given this a lot of thought and I've come around to see your solution as the best. A purely mathematical rule keeps it simple. Targeting Moore's law is reasonable.

Moore's law only talks about number of components on integrated circuits. If you want to target the lowest common denominator of all technologies involved, it would not be more than 17% per year, according to this: http://rusty.ozlabs.org/?p=493.