BIP 101 : maximum block size increase

[gavinandresen]

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.

[flix1]

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.

[aceat64]

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

[C-Otto]

mines -> miners

[dabura667]

ACK

Looks good to me. Can't wait.

[gavinandresen]

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

[gavinandresen]

@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.

[sipa]

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.

[flix1]

@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.

[sipa]

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.