Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BIP 101 : maximum block size increase #163

Merged
merged 2 commits into from Jul 30, 2015

Conversation

Projects
None yet
8 participants
@gavinandresen
Copy link
Contributor

commented Jun 24, 2015

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

This comment has been minimized.

Copy link

commented Jun 26, 2015

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

This comment has been minimized.

Copy link

commented Jun 26, 2015

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


===Centralization of mining: big-block attacks===

[https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08399 Simulations show] that with the current peer-to-peer protocol, miners behind high-latency or low-bandwidth links are at a disadvantage compared to miners connected to a majority of hashpower via low-latency, high-bandwidth links. Larger blocks increase the advantage of mines with high-bandwidth connections, although that advantage can be minimized with changes to the way new blocks are announced (e.g. http://bitcoinrelaynetwork.org/).

This comment has been minimized.

Copy link
@C-Otto

C-Otto Jun 26, 2015

mines -> miners


==Implementation==

https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork

This comment has been minimized.

Copy link
@C-Otto

C-Otto Jun 26, 2015

Reference your PR bitcoin/bitcoin#6341 instead?

@dabura667

This comment has been minimized.

Copy link

commented Jun 27, 2015

ACK

Looks good to me. Can't wait.

Increase maximum block size
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.
@gavinandresen

This comment has been minimized.

Copy link
Contributor Author

commented Jun 30, 2015

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

@gavinandresen

This comment has been minimized.

Copy link
Contributor Author

commented Jul 15, 2015

@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

This comment has been minimized.

Copy link
Member

commented Jul 15, 2015

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

This comment has been minimized.

Copy link

commented Jul 15, 2015

@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

This comment has been minimized.

Copy link
Member

commented Jul 15, 2015

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.

laanwj added a commit that referenced this pull request Jul 30, 2015

Merge pull request #163 from gavinandresen/blocksize
BIP 101 : maximum block size increase

@laanwj laanwj merged commit a409100 into bitcoin:master Jul 30, 2015

@petertodd

This comment has been minimized.

Copy link
Contributor

commented on 3248c9f Aug 18, 2015

Did you get any peer review prior to changing this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.