-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Conversation
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: 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. |
|
||
===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/). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mines -> miners
ACK Looks good to me. Can't wait. |
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.
Fixed typos / broken links found by @C-Otto (thanks!). |
…ting version 1/2/3 blocks
@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
That's surprising to me. In headers-first we never receive/process full If you're talking about doing an early check while receiving the block |
@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:
Moore's law only talks about number of components on integrated circuits. |
BIP 101 : maximum block size increase
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.