Draft BIP : fixed-schedule block size increase
62 messages, 22 Jun to 19 Aug 2015. Started by Gavin Andresen.
Gavin Andresen (10), Peter Todd (9), Tier Nolan (6), William Madden (4), Ross Nicoll (3), Roy Badami (3), Odinn Cyberguerrilla (3), Jorge Timón (3), +19 more
I promised to write a BIP after I'd implemented increase-the-maximum-block-size code, so here it is. It also lives at: https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
I don't expect any proposal to please everybody; there are unavoidable tradeoffs to increasing the maximum block size. I prioritize implementation simplicity -- it is hard to write consensus-critical code, so simpler is better.
BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen <gavinandresen@gmail•com> Status: Draft Type: Standards Track Created: 2015-06-22
==Abstract==
This BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate.
==Motivation==
Transaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. Increasing the maximum size reduces the impact of that limit on Bitcoin adoption and growth.
==Specification==
After deployment on the network (see the Deployment section for details), the maximum allowed size of a block on the main network shall be calculated based on the timestamp in the block header.
The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
Expressed in pseudo-code, using integer math:
function max_block_size(block_timestamp):
time_start = 1452470400
time_double = 60*60*24*365*2
size_start = 8000000
if block_timestamp >= time_start+time_double*10
return size_start * 2^10
// Piecewise-linear-between-doublings growth:
time_delta = block_timestamp - t_start
doublings = time_delta / time_double
remainder = time_delta % time_double
interpolate = (size_start * 2^doublings * remainder) / time_double
max_size = size_start * 2^doublings + interpolate
return max_size
==Deployment==
Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC.
Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 3 and 14 set (0x20000004 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC.
Block version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block.
==Rationale==
The initial size of 8,000,000 bytes was chosen after testing the current reference implementation code with larger block sizes and receiving feedback from miners stuck behind bandwidth-constrained networks (in particular, Chinese miners behind the Great Firewall of China).
The doubling interval was chosen based on long-term growth trends for CPU power, storage, and Internet bandwidth. The 20-year limit was chosen because exponential growth cannot continue forever.
Calculations are based on timestamps and not blockchain height because a timestamp is part of every block's header. This allows implementations to know a block's maximum size after they have downloaded it's header, but before downloading any transactions.
The deployment plan is taken from Jeff Garzik's proposed BIP100 block size increase, and is designed to give miners, merchants, and full-node-running-end-users sufficient time to upgrade to software that supports bigger blocks. A 75% supermajority was chosen so that one large mining pool does not have effective veto power over a blocksize increase. The version number scheme is designed to be compatible with Pieter's Wuille's proposed "Version bits" BIP.
TODO: summarize objections/arguments from http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
TODO: describe other proposals and their advantages/disadvantages over this proposal.
==Compatibility==
This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks.
Simplified Payment Verification software is not affected, unless it makes assumptions about the maximum depth of a transaction's merkle branch based on the minimum size of a transaction and the maximum block size.
==Implementation==
https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than the standard 1000. Given that the threshold is lower than is normal for hard-forks, noise on the measurement could cause an activation even if less than 75% of miners agree. It also means that the vote has to be sustained for longer and inherently gives a longer notice period.
Two weeks seems low for an upgrade warning. I guess there would be an alert on the network.
Do old nodes detect an upgrade by version numbers? If that was headers only, then they could detect that large blocks have activated.
Have you considered a "fail" condition? For example, if 750 of the last 1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the miners. Alternatively, if the rule doesn't activate by 11th Jan 2017, then it is disabled.
On Mon, Jun 22, 2015 at 2:33 PM, Tier Nolan <tier.nolan@gmail•com> wrote:
Quoted text (6 lines)
> The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than > the standard 1000. Given that the threshold is lower than is normal for > hard-forks, noise on the measurement could cause an activation even if less > than 75% of miners agree. It also means that the vote has to be sustained > for longer and inherently gives a longer notice period. >
9,000 of last 12,000 blocks is OK with me (I don't think scanning through the last 12,000 block headers every new block will cause performance problems, but I'd want to benchmark it to be absolutely sure).
Quoted text (3 lines)
> Two weeks seems low for an upgrade warning. I guess there would be an > alert on the network. >
Do old nodes detect an upgrade by version numbers? If that was headers
Quoted text (2 lines)
> only, then they could detect that large blocks have activated. >
Bitcoin Core will alert when automatically when 51% of blocks have a version it doesn't understand.
It will also alert automatically if it detects a chain with more work that it doesn't consider valid for some reason. And 0.11 contains code that alerts if you're on a chain that is being mined really slowly.
Have you considered a "fail" condition? For example, if 750 of the last
Quoted text (4 lines)
> 1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the > miners. Alternatively, if the rule doesn't activate by 11th Jan 2017, then > it is disabled. >
I like the fail-if-not-activated-by idea. Not so crazy about the vote idea (what if miners set bits 3 AND 4 ?).
Gavin,
in 2022 your proposal (BIP as well as code) crosses the 32MB maximum message size limit. In order to avoid deployment of code that deterministically fails fatally in 2022, I'd propose to stop the doublings at 32MB for now and fix the message size limit in the mean time. Since the message size fix requires a 2nd hard fork anyway, your current 8GB limit could be re-instateted in that 2nd fork as well. Even if you disagree, I'd suggest to address the topic in the BIP.
best regards, Martin
On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
Quoted text (3 lines)
> I promised to write a BIP after I'd implemented > increase-the-maximum-block-size code, so here it is. It also lives at: > https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
It's important that we see a wide range of realistic testing of what an 8MB limit could look in the near future. An important part of that testing is load testing.
As of writing the BIP above has no mention of what switchover rules will be used for testnet; code floating around has August 1st 2015 as that date. I propose we use August 1st 2013.
This switch over date should be set in the _past_ to allow for the creation (via reorg) of a realistic full-load blockchain on testnet to fully test the real-world behavior of the entire infrastructure ecosystem, including questions like the scalability of block explorers, SPV wallets, feasibility of initial syncronization, scalability of the UTXO set, etc. While this is of course inconvenient - 2 years of 8MB blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to make a change like this blindly.
I'm sure with a $3.5 billion market cap at stake we can scrape together the resources to voluntarily run a few hundred full-load full-nodes for testing a change with the potential to destroy that market cap.
On Mon, Jun 22, 2015 at 8:10 PM, Martin Schwarz <martin.schwarz@gmail•com> wrote:
Quoted text (8 lines)
> Gavin, > > in 2022 your proposal (BIP as well as code) crosses the 32MB maximum > message size limit. In order to avoid deployment of code that > deterministically > fails fatally in 2022, I'd propose to stop the doublings at 32MB for now > and fix > the message size limit in the mean time.
There is an exception in the code for "block" messages.
This means 2MB limit for all other messages. "block" messages are limited to the max block size for 2 hours into the future.
I think setting it to a week into the future might be better, since it is only a DOS protection. This would guarantee that message sizes are reasonable. The size check would still be done anyway.
On Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen@gmail•com> wrote:
The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
Since it's possible that block timestamps aren't chronological in order, what would happen if a block following a size increase trigger is back in the past before the size increase? Would that block have a lower size restriction again? Would using block height not be a more stable number to work with?
jp
As Tier says, the current network message limit is 2MB (reduced from 32MB in the... uhh, 0.10? release).
I think keeping the consensus rules distinct from limitations of the p2p network makes sense-- we are already seeing different protocols for announcing transactions and blocks (Matt's relay network is, essentially, a separate protocol). I could write a separate BIP describing the change to the p2p network protocol, but that feels like busy-work to me.
RE: setting the DoS size check farther than 2 hours into the future: the block, itself, will be rejected if it has a timestamp more than 2 hours in the future. That is already a consensus rule.
RE: what happens if block timestamps are not in chronological order: Nothing.
The activation counting happens in block-height-order, so timestamps on all but the "activating" block are all that matters.
Code that looks for the activation condition must properly handle re-orgs around the activation block, of course.
RE: testnet parameters: big blocks can be tested in -regtest mode with arbitrary timestamps in the past or future. Testing maximum-8MB-blocks mined "in the past" on testnet will just result in a testnet that is even more useless for ordinary testing of products or services being developed -- part of what makes testnet useful for things like testing transaction creation code is it syncs quickly.
That said, I have thought for a while now somebody should take a fresh look at the testnet, talk to people who might be customers for a reset testnet or testnets (we probably want separate testnets for people testing mining and people testing transaction creation, for example), and implement testnets designed to make it easy to test what people need testing.
RE: scraping together money to run a few hundred full-load full-nodes: hardware is cheap, people are expensive. You seem to expect that companies will be willing to invest the time of their people testing something that may never happen (8MB of transactions every ten minutes). Maybe they would, but most companies are very busy trying to stay in business by attracting customers to their products or services. Scaling up is a good problem to have, and, in my experience, the way to be successful scaling up is to tackle problems as they occur.
Because there's no use spending a bunch of person-hours hyper-optimizing for 8MB blocks stored in MySQL if a year from now you find out your customers don't actually want your product or MySQL 5.11 comes out and is 100 times faster....
On Mon, Jun 22, 2015 at 03:54:26PM -0400, Gavin Andresen wrote:
It would be useful if you replied directly to the emails in question as opposed to breaking the flow of conversation and taking replies out of context for other readers.
Quoted text (2 lines)
> As Tier says, the current network message limit is 2MB (reduced from 32MB > in the... uhh, 0.10? release).
Thank you!
A few questions/comments:
* In the specification, you refer to "t_start". I guess you mean "time_start"?
* Miners can, especially when close to a block doubling or shortly after activation, to some extent manipulate max block size by manipulating the time stamp in the block header within valid limits. According to the pseudo code in the specification, the first and a handful of subsequent blocks after activation could actually have negative max block sizes due to this (depending on how you define the % operator of the pseudo code). I haven't checked the reference implementation, but I do think that the specification section should explicitly handle this.
Regards, Kalle
2015-06-22 20:18 GMT+02:00 Gavin Andresen <gavinandresen@gmail•com>:
Quoted text (133 lines)
> I promised to write a BIP after I'd implemented > increase-the-maximum-block-size code, so here it is. It also lives at: > https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > > I don't expect any proposal to please everybody; there are unavoidable > tradeoffs to increasing the maximum block size. I prioritize implementation > simplicity -- it is hard to write consensus-critical code, so simpler is > better. > > > > > BIP: ?? > Title: Increase Maximum Block Size > Author: Gavin Andresen <gavinandresen@gmail•com> > Status: Draft > Type: Standards Track > Created: 2015-06-22 > > ==Abstract== > > This BIP proposes replacing the fixed one megabyte maximum block size with a > maximum size that grows over time at a predictable rate. > > ==Motivation== > > Transaction volume on the Bitcoin network has been growing, and will soon > reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte > maximum block size. Increasing the maximum size reduces the impact of that > limit on Bitcoin adoption and growth. > > ==Specification== > > After deployment on the network (see the Deployment section for details), > the maximum allowed size of a block on the main network shall be calculated > based on the timestamp in the block header. > > The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 > 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 > seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC > (timestamp 2083190400). The maximum size of blocks in between doublings will > increase linearly based on the block's timestamp. The maximum size of blocks > after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes. > > Expressed in pseudo-code, using integer math: > > function max_block_size(block_timestamp): > > time_start = 1452470400 > time_double = 60*60*24*365*2 > size_start = 8000000 > if block_timestamp >= time_start+time_double*10 > return size_start * 2^10 > > // Piecewise-linear-between-doublings growth: > time_delta = block_timestamp - t_start > doublings = time_delta / time_double > remainder = time_delta % time_double > interpolate = (size_start * 2^doublings * remainder) / time_double > max_size = size_start * 2^doublings + interpolate > > return max_size > > ==Deployment== > > Deployment shall be controlled by hash-power supermajority vote (similar to > the technique used in BIP34), but the earliest possible activation time is > 2016-01-11 00:00:00 UTC. > > Activation is achieved when 750 of 1,000 consecutive blocks in the best > chain have a version number with bits 3 and 14 set (0x20000004 in hex). The > activation time will be the timestamp of the 750'th block plus a two week > (1,209,600 second) grace period to give any remaining miners or services > time to upgrade to support larger blocks. If a supermajority is achieved > more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will > be 2016-01-11 00:00:00 UTC. > > Block version numbers are used only for activation; once activation is > achieved, the maximum block size shall be as described in the specification > section, regardless of the version number of the block. > > > ==Rationale== > > The initial size of 8,000,000 bytes was chosen after testing the current > reference implementation code with larger block sizes and receiving feedback > from miners stuck behind bandwidth-constrained networks (in particular, > Chinese miners behind the Great Firewall of China). > > The doubling interval was chosen based on long-term growth trends for CPU > power, storage, and Internet bandwidth. The 20-year limit was chosen because > exponential growth cannot continue forever. > > Calculations are based on timestamps and not blockchain height because a > timestamp is part of every block's header. This allows implementations to > know a block's maximum size after they have downloaded it's header, but > before downloading any transactions. > > The deployment plan is taken from Jeff Garzik's proposed BIP100 block size > increase, and is designed to give miners, merchants, and > full-node-running-end-users sufficient time to upgrade to software that > supports bigger blocks. A 75% supermajority was chosen so that one large > mining pool does not have effective veto power over a blocksize increase. > The version number scheme is designed to be compatible with Pieter's > Wuille's proposed "Version bits" BIP. > > TODO: summarize objections/arguments from > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. > > TODO: describe other proposals and their advantages/disadvantages over this > proposal. > > > ==Compatibility== > > This is a hard-forking change to the Bitcoin protocol; anybody running code > that fully validates blocks must upgrade before the activation time or they > will risk rejecting a chain containing larger-than-one-megabyte blocks. > > Simplified Payment Verification software is not affected, unless it makes > assumptions about the maximum depth of a transaction's merkle branch based > on the minimum size of a transaction and the maximum block size. > > ==Implementation== > > https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Mon, Jun 22, 2015 at 8:32 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com
Quoted text (8 lines)
> wrote: > > Since it's possible that block timestamps aren't chronological in order, > what would happen if a block following a size increase trigger is back in > the past before the size increase? Would that block have a lower size > restriction again? Would using block height not be a more stable number to > work with? >
The activation or not rule is purely timestamp based. Blocks with a timestamp less than 1452470400 have a limit of 1MB. There could be an 8MB block followed by a block that is limited to 1MB.
On Mon, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum <kalle@rosenbaum•se> wrote:
Quoted text (3 lines)
> * In the specification, you refer to "t_start". I guess you mean > "time_start"? >
Thanks, I'll fix.
Quoted text (10 lines)
> * Miners can, especially when close to a block doubling or shortly > after activation, to some extent manipulate max block size by > manipulating the time stamp in the block header within valid limits. > According to the pseudo code in the specification, the first and a > handful of subsequent blocks after activation could actually have > negative max block sizes due to this (depending on how you define the > % operator of the pseudo code). I haven't checked the reference > implementation, but I do think that the specification section should > explicitly handle this. >
Excellent point. That could only happen if activation happened on 11 Jan 2016; instead of complicating the code and spec with another condition, I think it would be better to specify that the activation date is the later of the miner supermajority and 11 Jan, with the first big block two weeks later.
On Mon, Jun 22, 2015 at 4:46 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (6 lines)
> Excellent point. That could only happen if activation happened on 11 Jan > 2016; instead of complicating the code and spec with another condition, I > think it would be better to specify that the activation date is the later > of the miner supermajority and 11 Jan, with the first big block two weeks > later. >
.... I take that back, I'm wrong and Tier is correct: if activation happened right at midnight 11 Jan 2016 and the next block's timestamp was before midnight, that next block would just be limited to 1MB in size.
On Mon, Jun 22, 2015 at 07:32:22PM +0000, Jean-Paul Kogelman wrote:
Quoted text (7 lines)
> > > On Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen@gmail•com> wrote: > > The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes. > > Since it's possible that block timestamps aren't chronological in order, what would happen if a block following a size increase trigger is back in the past before the size increase? Would that block have a lower size restriction again? Would using block height not be a more stable number to work with?
In the nVersion bits proposal that I co-authored we solved that issue by comparing the timestamp against the median time, which is guaranteed by the protocol rules to monotonically advance.
Quoted text (4 lines)
> In the nVersion bits proposal that I co-authored we solved that issue by > comparing the timestamp against the median time, which is guaranteed by > the protocol rules to monotonically advance. >
I'm also a fan of using the median time to ensure that there is a clear point where the protocol change starts. Something like "blocks only allow the larger block size if the associate pindex has pindex->GetMedianTimePast() after midnight 11 Jan 2016 and where a supermajority showing support for the fork has previously been reached".
On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (10 lines)
> > Since it's possible that block timestamps aren't chronological in order, > what would happen if a block following a size increase trigger is back in > the past before the size increase? Would that block have a lower size > restriction again? Would using block height not be a more stable number to > work with? > > In the nVersion bits proposal that I co-authored we solved that issue by > comparing the timestamp against the median time, which is guaranteed by > the protocol rules to monotonically advance. >
That complicates the implementation quite a bit.
I mostly implemented a variant that replaced the MAX_BLOCK_SIZE constant with a function that took both a timestamp and a block height, and there are several places in the current reference implementation where digging out the block height (or, worse, calculating the median timestamp for the block) would involve changing quite a few functions in the call-chain or acquiring the cs_main lock to consult the current best chain.
Potentially daft question, why not use a minimum height? Yes, it's imprecise, but over an extended period of time they're good enough IMHO.
I'd have to do more careful calculations to confirm, but block 388,000 should be about right as a minimum.
Ross
On 22/06/2015 22:04, Stephen Morse wrote:
Quoted text (19 lines)
> > In the nVersion bits proposal that I co-authored we solved that > issue by > comparing the timestamp against the median time, which is > guaranteed by > the protocol rules to monotonically advance. > > > I'm also a fan of using the median time to ensure that there is a > clear point where the protocol change starts. Something like "blocks > only allow the larger block size if the associate pindex has > pindex->GetMedianTimePast() after midnight 11 Jan 2016 and where a > supermajority showing support for the fork has previously been reached". > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
If you truly have a consensus then the rational behavior is to permanently change the nodes behavior after the trigger.
On 06/22/2015 02:21 PM, Gavin Andresen wrote:
Quoted text (35 lines)
> On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <pete@petertodd•org > <mailto:pete@petertodd.org>> wrote: > > > Since it's possible that block timestamps aren't chronological > in order, what would happen if a block following a size increase > trigger is back in the past before the size increase? Would that > block have a lower size restriction again? Would using block > height not be a more stable number to work with? > > In the nVersion bits proposal that I co-authored we solved that > issue by > comparing the timestamp against the median time, which is > guaranteed by > the protocol rules to monotonically advance. > > > That complicates the implementation quite a bit. > > I mostly implemented a variant that replaced the MAX_BLOCK_SIZE > constant with a function that took both a timestamp and a block > height, and there are several places in the current reference > implementation where digging out the block height (or, worse, > calculating the median timestamp for the block) would involve changing > quite a few functions in the call-chain or acquiring the cs_main lock > to consult the current best chain. > > -- > -- > Gavin Andresen > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Mon, Jun 22, 2015 at 10:21 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (2 lines)
> That complicates the implementation quite a bit. >
I think trying to keep the number of rules that require context to a minimum is a good idea. As pointed out in the BIP, using only the timestamp of the block means that the block limit can be determined purely from the block header.
I don't think there is much issue with having a 1MB block following an 8MB block during the activation.
This is inherent in using the timestamps. It occurs for every block that has a timestamp lower than its parent, but to a lesser degree.
When fees are the main source of income, it does create a slight incentive to use higher timestamps, but that is probably not massive, since it is 2 hours out of the 2 year doubling time.
Can you please add a discussion of the tradeoffs of decentralization vs block size?
On Mon, Jun 22, 2015 at 11:18 AM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (134 lines)
> I promised to write a BIP after I'd implemented > increase-the-maximum-block-size code, so here it is. It also lives at: > https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > > I don't expect any proposal to please everybody; there are unavoidable > tradeoffs to increasing the maximum block size. I prioritize implementation > simplicity -- it is hard to write consensus-critical code, so simpler is > better. > > > > > BIP: ?? > Title: Increase Maximum Block Size > Author: Gavin Andresen <gavinandresen@gmail•com> > Status: Draft > Type: Standards Track > Created: 2015-06-22 > > ==Abstract== > > This BIP proposes replacing the fixed one megabyte maximum block size with > a maximum size that grows over time at a predictable rate. > > ==Motivation== > > Transaction volume on the Bitcoin network has been growing, and will soon > reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte > maximum block size. Increasing the maximum size reduces the impact of that > limit on Bitcoin adoption and growth. > > ==Specification== > > After deployment on the network (see the Deployment section for details), > the maximum allowed size of a block on the main network shall be calculated > based on the timestamp in the block header. > > The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 > 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 > seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC > (timestamp 2083190400). The maximum size of blocks in between doublings > will increase linearly based on the block's timestamp. The maximum size of > blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes. > > Expressed in pseudo-code, using integer math: > > function max_block_size(block_timestamp): > > time_start = 1452470400 > time_double = 60*60*24*365*2 > size_start = 8000000 > if block_timestamp >= time_start+time_double*10 > return size_start * 2^10 > > // Piecewise-linear-between-doublings growth: > time_delta = block_timestamp - t_start > doublings = time_delta / time_double > remainder = time_delta % time_double > interpolate = (size_start * 2^doublings * remainder) / time_double > max_size = size_start * 2^doublings + interpolate > > return max_size > > ==Deployment== > > Deployment shall be controlled by hash-power supermajority vote (similar > to the technique used in BIP34), but the earliest possible activation time > is 2016-01-11 00:00:00 UTC. > > Activation is achieved when 750 of 1,000 consecutive blocks in the best > chain have a version number with bits 3 and 14 set (0x20000004 in hex). The > activation time will be the timestamp of the 750'th block plus a two week > (1,209,600 second) grace period to give any remaining miners or services > time to upgrade to support larger blocks. If a supermajority is achieved > more than two weeks before 2016-01-11 00:00:00 UTC, the activation time > will be 2016-01-11 00:00:00 UTC. > > Block version numbers are used only for activation; once activation is > achieved, the maximum block size shall be as described in the specification > section, regardless of the version number of the block. > > > ==Rationale== > > The initial size of 8,000,000 bytes was chosen after testing the current > reference implementation code with larger block sizes and receiving > feedback from miners stuck behind bandwidth-constrained networks (in > particular, Chinese miners behind the Great Firewall of China). > > The doubling interval was chosen based on long-term growth trends for CPU > power, storage, and Internet bandwidth. The 20-year limit was chosen > because exponential growth cannot continue forever. > > Calculations are based on timestamps and not blockchain height because a > timestamp is part of every block's header. This allows implementations to > know a block's maximum size after they have downloaded it's header, but > before downloading any transactions. > > The deployment plan is taken from Jeff Garzik's proposed BIP100 block size > increase, and is designed to give miners, merchants, and > full-node-running-end-users sufficient time to upgrade to software that > supports bigger blocks. A 75% supermajority was chosen so that one large > mining pool does not have effective veto power over a blocksize increase. > The version number scheme is designed to be compatible with Pieter's > Wuille's proposed "Version bits" BIP. > > TODO: summarize objections/arguments from > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. > > TODO: describe other proposals and their advantages/disadvantages over > this proposal. > > > ==Compatibility== > > This is a hard-forking change to the Bitcoin protocol; anybody running > code that fully validates blocks must upgrade before the activation time or > they will risk rejecting a chain containing larger-than-one-megabyte blocks. > > Simplified Payment Verification software is not affected, unless it makes > assumptions about the maximum depth of a transaction's merkle branch based > on the minimum size of a transaction and the maximum block size. > > ==Implementation== > > https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
I don't think essentially replacing most of Testnet with a specialised test chain is a good idea, but this might be a good time to consider a 4th test network with very large blocks from genesis onwards.
I do tend to think 2 years of 8mb blocks is excessive as a test, too, and while certainly large projects should have or can raise funds for test infrastructure, I would worry about the smaller stuff out there. Is there anything specific 2 years gives us over, say, 6 months?
Ross
On 22/06/2015 20:23, Peter Todd wrote:
Quoted text (31 lines)
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote: >> I promised to write a BIP after I'd implemented >> increase-the-maximum-block-size code, so here it is. It also lives at: >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > It's important that we see a wide range of realistic testing of what an > 8MB limit could look in the near future. An important part of that > testing is load testing. > > As of writing the BIP above has no mention of what switchover rules will > be used for testnet; code floating around has August 1st 2015 as that > date. I propose we use August 1st 2013. > > This switch over date should be set in the _past_ to allow for the > creation (via reorg) of a realistic full-load blockchain on testnet to > fully test the real-world behavior of the entire infrastructure > ecosystem, including questions like the scalability of block explorers, > SPV wallets, feasibility of initial syncronization, scalability of the > UTXO set, etc. While this is of course inconvenient - 2 years of 8MB > blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to > make a change like this blindly. > > I'm sure with a $3.5 billion market cap at stake we can scrape together > the resources to voluntarily run a few hundred full-load full-nodes for > testing a change with the potential to destroy that market cap. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Also, before that's turned into "8MB blocks are infeasible", my presumption is that blocks are not expected to jump suddenly to 8MB, and that most will have time to ramp up storage and bandwidth.
The point about not outright replacing existing test data is the more critical one, anyway, although in retrospect we could simply add spam transactions on top of existing transactions.
Ross
On 23 Jun 2015 08:35, Ross Nicoll <jrn@jrn•me•uk> wrote:
On Mon, Jun 22, 2015 at 03:23:09PM -0400, Peter Todd wrote:
Quoted text (25 lines)
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote: > > I promised to write a BIP after I'd implemented > > increase-the-maximum-block-size code, so here it is. It also lives at: > > https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > > It's important that we see a wide range of realistic testing of what an > 8MB limit could look in the near future. An important part of that > testing is load testing. > > As of writing the BIP above has no mention of what switchover rules will > be used for testnet; code floating around has August 1st 2015 as that > date. I propose we use August 1st 2013. > > This switch over date should be set in the _past_ to allow for the > creation (via reorg) of a realistic full-load blockchain on testnet to > fully test the real-world behavior of the entire infrastructure > ecosystem, including questions like the scalability of block explorers, > SPV wallets, feasibility of initial syncronization, scalability of the > UTXO set, etc. While this is of course inconvenient - 2 years of 8MB > blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to > make a change like this blindly. > > I'm sure with a $3.5 billion market cap at stake we can scrape together > the resources to voluntarily run a few hundred full-load full-nodes for > testing a change with the potential to destroy that market cap.
Also, as a few people have pointed out to me, the BIP proposal has no information at all about testing, reproducable or not.
As much of the discussion about the acceptability of this BIP will be heavily influenced by real world test results we should expect sufficient information available to understand and reproduce those tests; the Quality Assurance Test Plan done for BIP16 is a model worth looking at:
https://github.com/bitcoin/bips/blob/master/bip-0016/qa.mediawiki
On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
Quoted text (10 lines)
> ==Rationale== > > The initial size of 8,000,000 bytes was chosen after testing the current > reference implementation code with larger block sizes and receiving > feedback from miners stuck behind bandwidth-constrained networks (in > particular, Chinese miners behind the Great Firewall of China). > > The doubling interval was chosen based on long-term growth trends for CPU > power, storage, and Internet bandwidth. The 20-year limit was chosen > because exponential growth cannot continue forever.
Wladimir noted that 'The original presented intention of block size increase was a one-time "scaling" to grant time for more decentralizing solutions to develop'
Comments?
In particular, if bandwidth scaling doesn't go according to your plan, e.g. the exponential exponent is too large, perhaps due to technological growth not keeping pace, or the political realities of actual bandwidth deployment making theoretical technological growth irrelevant, what mechanism will prevent centralization? (if any)
On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (18 lines)
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote: > > ==Rationale== > > > > The initial size of 8,000,000 bytes was chosen after testing the current > > reference implementation code with larger block sizes and receiving > > feedback from miners stuck behind bandwidth-constrained networks (in > > particular, Chinese miners behind the Great Firewall of China). > > > > The doubling interval was chosen based on long-term growth trends for CPU > > power, storage, and Internet bandwidth. The 20-year limit was chosen > > because exponential growth cannot continue forever. > > Wladimir noted that 'The original presented intention of block size > increase was a one-time "scaling" to grant time for more decentralizing > solutions to develop' > > Comments? >
Consensus is that this process is too painful to go through once a year. I agree.
If you disagree and would like to see a Blocksize Council meet once a year to issue a decree on what the maximum block size shall be for the next year, then propose a process for who gets to sit on the Council and how their decrees are enforced.....
Quoted text (6 lines)
> > In particular, if bandwidth scaling doesn't go according to your plan, > e.g. the exponential exponent is too large, perhaps due to technological > growth not keeping pace, or the political realities of actual bandwidth > deployment making theoretical technological growth irrelevant, what > mechanism will prevent centralization? (if any)
Simulations show that:
Latency/bandwidth matter for miners. Low latency, high bandwidth is better. However, miners with bad connectivity can simply create smaller blocks...
... until transaction fees become significant. But by the time that happens, protocol optimizations of block propagation will make the block size an insignificant term in the "how profitable is it to mine in THIS particular place on the Internet / part of the world" equation.
(Reference: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08224.html )
So: for the immediate future, there is no problem. And in the long term, there is no problem.
On Tue, Jun 23, 2015 at 10:12 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (12 lines)
> On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd•org> wrote: > >> Wladimir noted that 'The original presented intention of block size >> increase was a one-time "scaling" to grant time for more decentralizing >> solutions to develop' >> >> Comments? >> > > Consensus is that this process is too painful to go through once a year. > I agree. >
If you believe we will need to go through this process once a year, we are not talking about a one-time scaling to grant time for more decentralizing solutions. It means you think we should keep scaling. I don't disagree there - as long as we're talking about scaling as availability of bandwidth, storage and processing power increase, there is no reason Bitcoin's blockchain can't grow proportionally.
However, an initial bump 8 MB and the growth rate afterwards seem more like a no-effectively-limit-ever to me.
I fear that the wish of not wanting to deal with - admittedly - a very hard problem, resulted here in throwing away several protections we currently have. And yes, I know you believe 8 MB won't be created immediately. I truly, honestly, do not think so either. But I prefer a system where I don't need to rely on anyone's guesses for the future.
On Tue, Jun 23, 2015 at 04:12:17PM -0400, Gavin Andresen wrote:
Quoted text (12 lines)
> > In particular, if bandwidth scaling doesn't go according to your plan, > > e.g. the exponential exponent is too large, perhaps due to technological > > growth not keeping pace, or the political realities of actual bandwidth > > deployment making theoretical technological growth irrelevant, what > > mechanism will prevent centralization? (if any) > > > Simulations show that: > > Latency/bandwidth matter for miners. Low latency, high bandwidth is > better. However, miners with bad connectivity can simply create smaller > blocks...
Pieter Wuille showed with simulations that miners with bad connectivity are negatively affected by other miners creating larger blocks. Similarly I showed that with equation-based analysis. I've seen no response to either argument, and it's a centralization pressure.
Note how propagation times are important enough to miners that they already mine on top of unverified headers from other miners to increase profitability, a grave threat to the security of the Bitcoin network.
Quoted text (4 lines)
> ... until transaction fees become significant. But by the time that > happens, protocol optimizations of block propagation will make the block > size an insignificant term in the "how profitable is it to mine in THIS > particular place on the Internet / part of the world" equation.
These block propagation improvements are both already implemented (Matt Corallo's relay network, p2pool) and require co-operation.
For instance, notice the recent full-RBF debate where Coinbase said they'd consider getting contracts directly with miners to get transactions they desired mined even when they otherwise would not be due to double-spends. This is one of many scenarios where block propagation improvements fail. Thus for a safety engineering analysis we need to talk about worst-case scenarios.
Equally, I don't see any analysis from anyone of that % of non-optimized transactions need to fail for what kind of centralizing pressure.
In any case, this ponts to the need for your proposal to explictly talk about what kind of resources are needed by miners for what kind of profitability, including the case where other miners are sabotaging their profitability.
On Tue, Jun 23, 2015 at 10:26:38PM +0200, Pieter Wuille wrote:
Quoted text (25 lines)
> On Tue, Jun 23, 2015 at 10:12 PM, Gavin Andresen <gavinandresen@gmail•com> > wrote: > > > On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd•org> wrote: > > > >> Wladimir noted that 'The original presented intention of block size > >> increase was a one-time "scaling" to grant time for more decentralizing > >> solutions to develop' > >> > >> Comments? > >> > > > > Consensus is that this process is too painful to go through once a year. > > I agree. > > > > If you believe we will need to go through this process once a year, we are > not talking about a one-time scaling to grant time for more decentralizing > solutions. It means you think we should keep scaling. I don't disagree > there - as long as we're talking about scaling as availability of > bandwidth, storage and processing power increase, there is no reason > Bitcoin's blockchain can't grow proportionally. > > However, an initial bump 8 MB and the growth rate afterwards seem more like > a no-effectively-limit-ever to me.
In particular, note how this bump is being proposed at a time when blockchain space demand is so low that transactions usually cost well under a penny each, a insignificant amount of money for almost all use-cases.
Quoted text (5 lines)
> I fear that the wish of not wanting to deal with - admittedly - a very hard > problem, resulted here in throwing away several protections we currently > have. And yes, I know you believe 8 MB won't be created immediately. I > truly, honestly, do not think so either. But I prefer a system where I > don't need to rely on anyone's guesses for the future.
In that regard Jeff Garzik's proposal of a blocksize increase with a miner vote feedback mechanism is a huge improvement over Gavin's proposal.
Quoted text (7 lines)
> Consensus is that this process is too painful to go through once a year. I > agree. > > If you disagree and would like to see a Blocksize Council meet once a year > to issue a decree on what the maximum block size shall be for the next > year, then propose a process for who gets to sit on the Council and how > their decrees are enforced.....
We could just as well say that the increases continue for 20 years, or until there is concensus to schedule a soft-fork to prevent further increase - whichever comes first. That is the case already, of course, since there is no way to prevent a modest supermajority of miners from pushing through a soft-fork. But explicitly accepting the possibility that the community might choose to cut the process short might make the BIP more palatable to some.
It is also the reality: halting the blocksize increase before it hits the final 8GB limit is relatively easy, compared to the task of setting it in motion, so it does no real harm to set the "20 years" figure at the upper range of what we think is reasonable - even though under other circumstances one would probably say that extrapolating exponentials that far out would be foolhardy...
roy
On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (3 lines)
> Pieter Wuille showed with simulations that miners with bad connectivity > are negatively affected by other miners creating larger blocks. >
... but the effect is only significant if they have an absurdly low-bandwidth connection and do NOTHING to work around it (like rent a server on the other side of the bandwidth bottleneck and write some code to make sure you're creating blocks that will propagate quickly on both sides of the bottleneck).
Why do you think connectivity is a centralizing effect? It is just one factor in the profitability-of-mining equation. A location with bad connectivity (the US, maybe) but 10% cheaper electricity might be just as good as one with great connectivity but more expensive electricity.
Having lots of variables in the profitability equation is a decentralizing force, it means there is very likely to be several different places in the world / on the net where mining is equally profitable.
Quoted text (8 lines)
> ... until transaction fees become significant. But by the time that > > happens, protocol optimizations of block propagation will make the block > > size an insignificant term in the "how profitable is it to mine in THIS > > particular place on the Internet / part of the world" equation. > > These block propagation improvements are both already implemented (Matt > Corallo's relay network, p2pool) and require co-operation. >
Long term the p2p protocol will evolve to incorporate those optimizations, so will require no co-operation.
Quoted text (14 lines)
> For instance, notice the recent full-RBF debate where Coinbase said > they'd consider getting contracts directly with miners to get > transactions they desired mined even when they otherwise would not be > due to double-spends. This is one of many scenarios where block > propagation improvements fail. Thus for a safety engineering > analysis we need to talk about worst-case scenarioss > Equally, I don't see any analysis from anyone of that % of non-optimized > transactions need to fail for what kind of centralizing pressure. > > In any case, this ponts to the need for your proposal to explictly talk > about what kind of resources are needed by miners for what kind of > profitability, including the case where other miners are sabotaging > their profitability. >
Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ?
I have written quite a lot about the kind of resources needed to run a full node, and have asked you, specifically, several times "how much do you think is too much" and received no answer.
1) Hard fork not (necessarily) needed 2) See Garzik's BIP 100, better (this is not meant to say "superior to your stuff," but rather simply to say, "Better you should work with Garzik to implement BIP-100, that would be good") 3) See points 1 and 2 above 4) If still reading... changes should be (as you seem to have been trying to lean towards)... lean towards gradual change; hence, changes that would flow from this BIP would be better off oriented in a process that dies not require the "way you have done it."
You did address that, to be fair - in your TODO, this link: http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
contained the following link:
http://gavinandresen.ninja/bigger-blocks-another-way
However, in reading that, I didn't see any meaningful statements that would refute the approach in Garzik's BIP-100.
Maybe a better way to say this is,
Work with Jeff Garzik (which I am sure you are already having such discussions in private) as well as the list discussions, Move forward on BIP-100 with Garzik and other developers (not such a bad plan really) and don't get caught up in XT. (If you feel you can develop XT further, that is your thing but it would perhaps make you lose focus, work together with other developers.)
Relax into the process. Things will be ok.
Respectfully,
- -O
On 06/22/2015 11:18 AM, Gavin Andresen wrote:
Quoted text (136 lines)
> I promised to write a BIP after I'd implemented > increase-the-maximum-block-size code, so here it is. It also lives > at: > https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > > I don't expect any proposal to please everybody; there are > unavoidable tradeoffs to increasing the maximum block size. I > prioritize implementation simplicity -- it is hard to write > consensus-critical code, so simpler is better. > > > > > BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen > <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: > Draft Type: Standards Track Created: 2015-06-22 > > ==Abstract== > > This BIP proposes replacing the fixed one megabyte maximum block > size with a maximum size that grows over time at a predictable > rate. > > ==Motivation== > > Transaction volume on the Bitcoin network has been growing, and > will soon reach the one-megabyte-every-ten-minutes limit imposed by > the one megabyte maximum block size. Increasing the maximum size > reduces the impact of that limit on Bitcoin adoption and growth. > > ==Specification== > > After deployment on the network (see the Deployment section for > details), the maximum allowed size of a block on the main network > shall be calculated based on the timestamp in the block header. > > The maximum size shall be 8,000,000 bytes at a timestamp of > 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double > every 63,072,000 seconds (two years, ignoring leap years), until > 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of > blocks in between doublings will increase linearly based on the > block's timestamp. The maximum size of blocks after 2036-01-06 > 00:00:00 UTC shall be 8,192,000,000 bytes. > > Expressed in pseudo-code, using integer math: > > function max_block_size(block_timestamp): > > time_start = 1452470400 time_double = 60*60*24*365*2 size_start = > 8000000 if block_timestamp >= time_start+time_double*10 return > size_start * 2^10 > > // Piecewise-linear-between-doublings growth: time_delta = > block_timestamp - t_start doublings = time_delta / time_double > remainder = time_delta % time_double interpolate = (size_start * > 2^doublings * remainder) / time_double max_size = size_start * > 2^doublings + interpolate > > return max_size > > ==Deployment== > > Deployment shall be controlled by hash-power supermajority vote > (similar to the technique used in BIP34), but the earliest possible > activation time is 2016-01-11 00:00:00 UTC. > > Activation is achieved when 750 of 1,000 consecutive blocks in the > best chain have a version number with bits 3 and 14 set (0x20000004 > in hex). The activation time will be the timestamp of the 750'th > block plus a two week (1,209,600 second) grace period to give any > remaining miners or services time to upgrade to support larger > blocks. If a supermajority is achieved more than two weeks before > 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 > 00:00:00 UTC. > > Block version numbers are used only for activation; once activation > is achieved, the maximum block size shall be as described in the > specification section, regardless of the version number of the > block. > > > ==Rationale== > > The initial size of 8,000,000 bytes was chosen after testing the > current reference implementation code with larger block sizes and > receiving feedback from miners stuck behind bandwidth-constrained > networks (in particular, Chinese miners behind the Great Firewall > of China). > > The doubling interval was chosen based on long-term growth trends > for CPU power, storage, and Internet bandwidth. The 20-year limit > was chosen because exponential growth cannot continue forever. > > Calculations are based on timestamps and not blockchain height > because a timestamp is part of every block's header. This allows > implementations to know a block's maximum size after they have > downloaded it's header, but before downloading any transactions. > > The deployment plan is taken from Jeff Garzik's proposed BIP100 > block size increase, and is designed to give miners, merchants, > and full-node-running-end-users sufficient time to upgrade to > software that supports bigger blocks. A 75% supermajority was > chosen so that one large mining pool does not have effective veto > power over a blocksize increase. The version number scheme is > designed to be compatible with Pieter's Wuille's proposed "Version > bits" BIP. > > TODO: summarize objections/arguments from > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. > > TODO: describe other proposals and their advantages/disadvantages > over this proposal. > > > ==Compatibility== > > This is a hard-forking change to the Bitcoin protocol; anybody > running code that fully validates blocks must upgrade before the > activation time or they will risk rejecting a chain containing > larger-than-one-megabyte blocks. > > Simplified Payment Verification software is not affected, unless > it makes assumptions about the maximum depth of a transaction's > merkle branch based on the minimum size of a transaction and the > maximum block size. > > ==Implementation== > > https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn
Here are refutations of the approach in BIP-100 here: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
To recap BIP-100:
1) Hard form to remove static 1MB block size limit 2) Add new floating block size limit set to 1MB 3) Historical 32MB message limit remains 4) Hard form on testnet 9/1/2015 5) Hard form on main 1/11/2016 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block threshold by 90% of blocks 7) Limit increase or decrease may not exceed 2x in any one step 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase scriptSig, e.g. "/BV8000000/" to vote for 8M. 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the most common floor (minimum) is chosen.
8MB limits doubling just under every 2 years makes a static value grow in a predictable manner.
BIP-100 makes a static value grow (or more importantly potentially shrink) in an unpredictable manner based on voting mechanics that are untested in this capacity in the bitcoin network. Introducing a highly variable and untested dynamic into an already complex system is unnecessarily risky.
For example, the largely arbitrary voting rules listed in 9 above can be gamed. If I control pools or have affiliates involved in pools that mine slightly more than 20% of blocks, I could wait until block sizes are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and "/BV5000001/" for the remaining 10%. If others don't consistently vote for the same "/BV#/" value, vote too consistently and have their value thrown out as the top 20%, I could win the resize to half capacity "/BV5000001/" because it was the lowest repeated value not in the bottom 20%.
I could use this to force an exodus to my sidechain/alt coin, or to choke out the bitcoin network. A first improvement would be to only let BIP-100 raise the cap and not lower it, but if I can think of a vulnerability off the top of my head, there will be others on the other side of the equation that have not been thought of. Why bother introducing a rube goldberg machine like voting when a simple 8mb cap with predictable growth gets the job done, potentially permanently?
On 6/23/2015 9:43 PM, odinn wrote:
Quoted text (197 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 1) Hard fork not (necessarily) needed > 2) See Garzik's BIP 100, better (this is not meant to say "superior to > your stuff," but rather simply to say, "Better you should work with > Garzik to implement BIP-100, that would be good") > 3) See points 1 and 2 above > 4) If still reading... changes should be (as you seem to have been > trying to lean towards)... lean towards gradual change; hence, changes > that would flow from this BIP would be better off oriented in a > process that dies not require the "way you have done it." > > You did address that, to be fair - in your TODO, this link: > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks > > contained the following link: > > http://gavinandresen.ninja/bigger-blocks-another-way > > However, in reading that, I didn't see any meaningful statements that > would refute the approach in Garzik's BIP-100. > > Maybe a better way to say this is, > > Work with Jeff Garzik (which I am sure you are already having such > discussions in private) as well as the list discussions, > Move forward on BIP-100 with Garzik and other developers (not such a > bad plan really) and don't get caught up in XT. (If you feel you can > develop XT further, that is your thing but it would perhaps make you > lose focus, work together with other developers.) > > Relax into the process. Things will be ok. > > Respectfully, > > - -O > > On 06/22/2015 11:18 AM, Gavin Andresen wrote: >> I promised to write a BIP after I'd implemented >> increase-the-maximum-block-size code, so here it is. It also lives >> at: >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki >> >> I don't expect any proposal to please everybody; there are >> unavoidable tradeoffs to increasing the maximum block size. I >> prioritize implementation simplicity -- it is hard to write >> consensus-critical code, so simpler is better. >> >> >> >> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen >> <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: >> Draft Type: Standards Track Created: 2015-06-22 >> >> ==Abstract== >> >> This BIP proposes replacing the fixed one megabyte maximum block >> size with a maximum size that grows over time at a predictable >> rate. >> >> ==Motivation== >> >> Transaction volume on the Bitcoin network has been growing, and >> will soon reach the one-megabyte-every-ten-minutes limit imposed by >> the one megabyte maximum block size. Increasing the maximum size >> reduces the impact of that limit on Bitcoin adoption and growth. >> >> ==Specification== >> >> After deployment on the network (see the Deployment section for >> details), the maximum allowed size of a block on the main network >> shall be calculated based on the timestamp in the block header. >> >> The maximum size shall be 8,000,000 bytes at a timestamp of >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double >> every 63,072,000 seconds (two years, ignoring leap years), until >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of >> blocks in between doublings will increase linearly based on the >> block's timestamp. The maximum size of blocks after 2036-01-06 >> 00:00:00 UTC shall be 8,192,000,000 bytes. >> >> Expressed in pseudo-code, using integer math: >> >> function max_block_size(block_timestamp): >> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = >> 8000000 if block_timestamp >= time_start+time_double*10 return >> size_start * 2^10 >> >> // Piecewise-linear-between-doublings growth: time_delta = >> block_timestamp - t_start doublings = time_delta / time_double >> remainder = time_delta % time_double interpolate = (size_start * >> 2^doublings * remainder) / time_double max_size = size_start * >> 2^doublings + interpolate >> >> return max_size >> >> ==Deployment== >> >> Deployment shall be controlled by hash-power supermajority vote >> (similar to the technique used in BIP34), but the earliest possible >> activation time is 2016-01-11 00:00:00 UTC. >> >> Activation is achieved when 750 of 1,000 consecutive blocks in the >> best chain have a version number with bits 3 and 14 set (0x20000004 >> in hex). The activation time will be the timestamp of the 750'th >> block plus a two week (1,209,600 second) grace period to give any >> remaining miners or services time to upgrade to support larger >> blocks. If a supermajority is achieved more than two weeks before >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 >> 00:00:00 UTC. >> >> Block version numbers are used only for activation; once activation >> is achieved, the maximum block size shall be as described in the >> specification section, regardless of the version number of the >> block. >> >> >> ==Rationale== >> >> The initial size of 8,000,000 bytes was chosen after testing the >> current reference implementation code with larger block sizes and >> receiving feedback from miners stuck behind bandwidth-constrained >> networks (in particular, Chinese miners behind the Great Firewall >> of China). >> >> The doubling interval was chosen based on long-term growth trends >> for CPU power, storage, and Internet bandwidth. The 20-year limit >> was chosen because exponential growth cannot continue forever. >> >> Calculations are based on timestamps and not blockchain height >> because a timestamp is part of every block's header. This allows >> implementations to know a block's maximum size after they have >> downloaded it's header, but before downloading any transactions. >> >> The deployment plan is taken from Jeff Garzik's proposed BIP100 >> block size increase, and is designed to give miners, merchants, >> and full-node-running-end-users sufficient time to upgrade to >> software that supports bigger blocks. A 75% supermajority was >> chosen so that one large mining pool does not have effective veto >> power over a blocksize increase. The version number scheme is >> designed to be compatible with Pieter's Wuille's proposed "Version >> bits" BIP. >> >> TODO: summarize objections/arguments from >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. >> >> TODO: describe other proposals and their advantages/disadvantages >> over this proposal. >> >> >> ==Compatibility== >> >> This is a hard-forking change to the Bitcoin protocol; anybody >> running code that fully validates blocks must upgrade before the >> activation time or they will risk rejecting a chain containing >> larger-than-one-megabyte blocks. >> >> Simplified Payment Verification software is not affected, unless >> it makes assumptions about the maximum depth of a transaction's >> merkle branch based on the minimum size of a transaction and the >> maximum block size. >> >> ==Implementation== >> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork >> >> >> >> _______________________________________________ bitcoin-dev mailing >> list bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > - -- > http://abis.io ~ > "a protocol concept to enable decentralization > and expansion of a giving economy, and a new social good" > https://keybase.io/odinn > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= > =ft62 > -----END PGP SIGNATURE----- > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Miners can collude today to lower the block size limit.
In fact, this largely happens already out of laziness - miners often follow the "soft" default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software: http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri•com> wrote:
Quoted text (249 lines)
> Here are refutations of the approach in BIP-100 here: > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf > > To recap BIP-100: > > 1) Hard form to remove static 1MB block size limit > 2) Add new floating block size limit set to 1MB > 3) Historical 32MB message limit remains > 4) Hard form on testnet 9/1/2015 > 5) Hard form on main 1/11/2016 > 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block > threshold by 90% of blocks > 7) Limit increase or decrease may not exceed 2x in any one step > 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase > scriptSig, e.g. "/BV8000000/" to vote for 8M. > 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the > most common floor (minimum) is chosen. > > 8MB limits doubling just under every 2 years makes a static value grow > in a predictable manner. > > BIP-100 makes a static value grow (or more importantly potentially > shrink) in an unpredictable manner based on voting mechanics that are > untested in this capacity in the bitcoin network. Introducing a highly > variable and untested dynamic into an already complex system is > unnecessarily risky. > > For example, the largely arbitrary voting rules listed in 9 above can be > gamed. If I control pools or have affiliates involved in pools that > mine slightly more than 20% of blocks, I could wait until block sizes > are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and > "/BV5000001/" for the remaining 10%. If others don't consistently vote > for the same "/BV#/" value, vote too consistently and have their value > thrown out as the top 20%, I could win the resize to half capacity > "/BV5000001/" because it was the lowest repeated value not in the bottom > 20%. > > I could use this to force an exodus to my sidechain/alt coin, or to > choke out the bitcoin network. A first improvement would be to only let > BIP-100 raise the cap and not lower it, but if I can think of a > vulnerability off the top of my head, there will be others on the other > side of the equation that have not been thought of. Why bother > introducing a rube goldberg machine like voting when a simple 8mb cap > with predictable growth gets the job done, potentially permanently? > > > On 6/23/2015 9:43 PM, odinn wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > 1) Hard fork not (necessarily) needed > > 2) See Garzik's BIP 100, better (this is not meant to say "superior to > > your stuff," but rather simply to say, "Better you should work with > > Garzik to implement BIP-100, that would be good") > > 3) See points 1 and 2 above > > 4) If still reading... changes should be (as you seem to have been > > trying to lean towards)... lean towards gradual change; hence, changes > > that would flow from this BIP would be better off oriented in a > > process that dies not require the "way you have done it." > > > > You did address that, to be fair - in your TODO, this link: > > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks > > > > contained the following link: > > > > http://gavinandresen.ninja/bigger-blocks-another-way > > > > However, in reading that, I didn't see any meaningful statements that > > would refute the approach in Garzik's BIP-100. > > > > Maybe a better way to say this is, > > > > Work with Jeff Garzik (which I am sure you are already having such > > discussions in private) as well as the list discussions, > > Move forward on BIP-100 with Garzik and other developers (not such a > > bad plan really) and don't get caught up in XT. (If you feel you can > > develop XT further, that is your thing but it would perhaps make you > > lose focus, work together with other developers.) > > > > Relax into the process. Things will be ok. > > > > Respectfully, > > > > - -O > > > > On 06/22/2015 11:18 AM, Gavin Andresen wrote: > >> I promised to write a BIP after I'd implemented > >> increase-the-maximum-block-size code, so here it is. It also lives > >> at: > >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > >> > >> I don't expect any proposal to please everybody; there are > >> unavoidable tradeoffs to increasing the maximum block size. I > >> prioritize implementation simplicity -- it is hard to write > >> consensus-critical code, so simpler is better. > >> > >> > >> > >> > >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen > >> <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: > >> Draft Type: Standards Track Created: 2015-06-22 > >> > >> ==Abstract== > >> > >> This BIP proposes replacing the fixed one megabyte maximum block > >> size with a maximum size that grows over time at a predictable > >> rate. > >> > >> ==Motivation== > >> > >> Transaction volume on the Bitcoin network has been growing, and > >> will soon reach the one-megabyte-every-ten-minutes limit imposed by > >> the one megabyte maximum block size. Increasing the maximum size > >> reduces the impact of that limit on Bitcoin adoption and growth. > >> > >> ==Specification== > >> > >> After deployment on the network (see the Deployment section for > >> details), the maximum allowed size of a block on the main network > >> shall be calculated based on the timestamp in the block header. > >> > >> The maximum size shall be 8,000,000 bytes at a timestamp of > >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double > >> every 63,072,000 seconds (two years, ignoring leap years), until > >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of > >> blocks in between doublings will increase linearly based on the > >> block's timestamp. The maximum size of blocks after 2036-01-06 > >> 00:00:00 UTC shall be 8,192,000,000 bytes. > >> > >> Expressed in pseudo-code, using integer math: > >> > >> function max_block_size(block_timestamp): > >> > >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = > >> 8000000 if block_timestamp >= time_start+time_double*10 return > >> size_start * 2^10 > >> > >> // Piecewise-linear-between-doublings growth: time_delta = > >> block_timestamp - t_start doublings = time_delta / time_double > >> remainder = time_delta % time_double interpolate = (size_start * > >> 2^doublings * remainder) / time_double max_size = size_start * > >> 2^doublings + interpolate > >> > >> return max_size > >> > >> ==Deployment== > >> > >> Deployment shall be controlled by hash-power supermajority vote > >> (similar to the technique used in BIP34), but the earliest possible > >> activation time is 2016-01-11 00:00:00 UTC. > >> > >> Activation is achieved when 750 of 1,000 consecutive blocks in the > >> best chain have a version number with bits 3 and 14 set (0x20000004 > >> in hex). The activation time will be the timestamp of the 750'th > >> block plus a two week (1,209,600 second) grace period to give any > >> remaining miners or services time to upgrade to support larger > >> blocks. If a supermajority is achieved more than two weeks before > >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 > >> 00:00:00 UTC. > >> > >> Block version numbers are used only for activation; once activation > >> is achieved, the maximum block size shall be as described in the > >> specification section, regardless of the version number of the > >> block. > >> > >> > >> ==Rationale== > >> > >> The initial size of 8,000,000 bytes was chosen after testing the > >> current reference implementation code with larger block sizes and > >> receiving feedback from miners stuck behind bandwidth-constrained > >> networks (in particular, Chinese miners behind the Great Firewall > >> of China). > >> > >> The doubling interval was chosen based on long-term growth trends > >> for CPU power, storage, and Internet bandwidth. The 20-year limit > >> was chosen because exponential growth cannot continue forever. > >> > >> Calculations are based on timestamps and not blockchain height > >> because a timestamp is part of every block's header. This allows > >> implementations to know a block's maximum size after they have > >> downloaded it's header, but before downloading any transactions. > >> > >> The deployment plan is taken from Jeff Garzik's proposed BIP100 > >> block size increase, and is designed to give miners, merchants, > >> and full-node-running-end-users sufficient time to upgrade to > >> software that supports bigger blocks. A 75% supermajority was > >> chosen so that one large mining pool does not have effective veto > >> power over a blocksize increase. The version number scheme is > >> designed to be compatible with Pieter's Wuille's proposed "Version > >> bits" BIP. > >> > >> TODO: summarize objections/arguments from > >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. > >> > >> TODO: describe other proposals and their advantages/disadvantages > >> over this proposal. > >> > >> > >> ==Compatibility== > >> > >> This is a hard-forking change to the Bitcoin protocol; anybody > >> running code that fully validates blocks must upgrade before the > >> activation time or they will risk rejecting a chain containing > >> larger-than-one-megabyte blocks. > >> > >> Simplified Payment Verification software is not affected, unless > >> it makes assumptions about the maximum depth of a transaction's > >> merkle branch based on the minimum size of a transaction and the > >> maximum block size. > >> > >> ==Implementation== > >> > >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork > >> > >> > >> > >> _______________________________________________ bitcoin-dev mailing > >> list bitcoin-dev@lists•linuxfoundation•org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > > > > - -- > > http://abis.io ~ > > "a protocol concept to enable decentralization > > and expansion of a giving economy, and a new social good" > > https://keybase.io/odinn > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1 > > > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 > > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ > > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw > > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN > > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s > > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= > > =ft62 > > -----END PGP SIGNATURE----- > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
No, they can lower their own block sizes. But they cannot currently lower the sizes of blocks mined by others. That is not the same thing by any stretch of the imagination.
On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail•com> wrote:Miners can collude today to lower the block size limit.
In fact, this largely happens already out of laziness - miners often follow the "soft" default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software: http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri•com> wrote: Here are refutations of the approach in BIP-100 here:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
To recap BIP-100:
1) Hard form to remove static 1MB block size limit
2) Add new floating block size limit set to 1MB
3) Historical 32MB message limit remains
4) Hard form on testnet 9/1/2015
5) Hard form on main 1/11/2016
6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
threshold by 90% of blocks
7) Limit increase or decrease may not exceed 2x in any one step
8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
scriptSig, e.g. "/BV8000000/" to vote for 8M.
9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
most common floor (minimum) is chosen.
8MB limits doubling just under every 2 years makes a static value grow
in a predictable manner.
BIP-100 makes a static value grow (or more importantly potentially
shrink) in an unpredictable manner based on voting mechanics that are
untested in this capacity in the bitcoin network. Introducing a highly
variable and untested dynamic into an already complex system is
unnecessarily risky.
For example, the largely arbitrary voting rules listed in 9 above can be
gamed. If I control pools or have affiliates involved in pools that
mine slightly more than 20% of blocks, I could wait until block sizes
are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
"/BV5000001/" for the remaining 10%. If others don't consistently vote
for the same "/BV#/" value, vote too consistently and have their value
thrown out as the top 20%, I could win the resize to half capacity
"/BV5000001/" because it was the lowest repeated value not in the bottom
20%.
I could use this to force an exodus to my sidechain/alt coin, or to
choke out the bitcoin network. A first improvement would be to only let
BIP-100 raise the cap and not lower it, but if I can think of a
vulnerability off the top of my head, there will be others on the other
side of the equation that have not been thought of. Why bother
introducing a rube goldberg machine like voting when a simple 8mb cap
with predictable growth gets the job done, potentially permanently?
On 6/23/2015 9:43 PM, odinn wrote:
Quoted text (197 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 1) Hard fork not (necessarily) needed > 2) See Garzik's BIP 100, better (this is not meant to say "superior to > your stuff," but rather simply to say, "Better you should work with > Garzik to implement BIP-100, that would be good") > 3) See points 1 and 2 above > 4) If still reading... changes should be (as you seem to have been > trying to lean towards)... lean towards gradual change; hence, changes > that would flow from this BIP would be better off oriented in a > process that dies not require the "way you have done it." > > You did address that, to be fair - in your TODO, this link: > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks > > contained the following link: > > http://gavinandresen.ninja/bigger-blocks-another-way > > However, in reading that, I didn't see any meaningful statements that > would refute the approach in Garzik's BIP-100. > > Maybe a better way to say this is, > > Work with Jeff Garzik (which I am sure you are already having such > discussions in private) as well as the list discussions, > Move forward on BIP-100 with Garzik and other developers (not such a > bad plan really) and don't get caught up in XT. (If you feel you can > develop XT further, that is your thing but it would perhaps make you > lose focus, work together with other developers.) > > Relax into the process. Things will be ok. > > Respectfully, > > - -O > > On 06/22/2015 11:18 AM, Gavin Andresen wrote: >> I promised to write a BIP after I'd implemented >> increase-the-maximum-block-size code, so here it is. It also lives >> at: >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki >> >> I don't expect any proposal to please everybody; there are >> unavoidable tradeoffs to increasing the maximum block size. I >> prioritize implementation simplicity -- it is hard to write >> consensus-critical code, so simpler is better. >> >> >> >> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen >> <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: >> Draft Type: Standards Track Created: 2015-06-22 >> >> ==Abstract== >> >> This BIP proposes replacing the fixed one megabyte maximum block >> size with a maximum size that grows over time at a predictable >> rate. >> >> ==Motivation== >> >> Transaction volume on the Bitcoin network has been growing, and >> will soon reach the one-megabyte-every-ten-minutes limit imposed by >> the one megabyte maximum block size. Increasing the maximum size >> reduces the impact of that limit on Bitcoin adoption and growth. >> >> ==Specification== >> >> After deployment on the network (see the Deployment section for >> details), the maximum allowed size of a block on the main network >> shall be calculated based on the timestamp in the block header. >> >> The maximum size shall be 8,000,000 bytes at a timestamp of >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double >> every 63,072,000 seconds (two years, ignoring leap years), until >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of >> blocks in between doublings will increase linearly based on the >> block's timestamp. The maximum size of blocks after 2036-01-06 >> 00:00:00 UTC shall be 8,192,000,000 bytes. >> >> Expressed in pseudo-code, using integer math: >> >> function max_block_size(block_timestamp): >> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = >> 8000000 if block_timestamp >= time_start+time_double*10 return >> size_start * 2^10 >> >> // Piecewise-linear-between-doublings growth: time_delta = >> block_timestamp - t_start doublings = time_delta / time_double >> remainder = time_delta % time_double interpolate = (size_start * >> 2^doublings * remainder) / time_double max_size = size_start * >> 2^doublings + interpolate >> >> return max_size >> >> ==Deployment== >> >> Deployment shall be controlled by hash-power supermajority vote >> (similar to the technique used in BIP34), but the earliest possible >> activation time is 2016-01-11 00:00:00 UTC. >> >> Activation is achieved when 750 of 1,000 consecutive blocks in the >> best chain have a version number with bits 3 and 14 set (0x20000004 >> in hex). The activation time will be the timestamp of the 750'th >> block plus a two week (1,209,600 second) grace period to give any >> remaining miners or services time to upgrade to support larger >> blocks. If a supermajority is achieved more than two weeks before >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 >> 00:00:00 UTC. >> >> Block version numbers are used only for activation; once activation >> is achieved, the maximum block size shall be as described in the >> specification section, regardless of the version number of the >> block. >> >> >> ==Rationale== >> >> The initial size of 8,000,000 bytes was chosen after testing the >> current reference implementation code with larger block sizes and >> receiving feedback from miners stuck behind bandwidth-constrained >> networks (in particular, Chinese miners behind the Great Firewall >> of China). >> >> The doubling interval was chosen based on long-term growth trends >> for CPU power, storage, and Internet bandwidth. The 20-year limit >> was chosen because exponential growth cannot continue forever. >> >> Calculations are based on timestamps and not blockchain height >> because a timestamp is part of every block's header. This allows >> implementations to know a block's maximum size after they have >> downloaded it's header, but before downloading any transactions. >> >> The deployment plan is taken from Jeff Garzik's proposed BIP100 >> block size increase, and is designed to give miners, merchants, >> and full-node-running-end-users sufficient time to upgrade to >> software that supports bigger blocks. A 75% supermajority was >> chosen so that one large mining pool does not have effective veto >> power over a blocksize increase. The version number scheme is >> designed to be compatible with Pieter's Wuille's proposed "Version >> bits" BIP. >> >> TODO: summarize objections/arguments from >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. >> >> TODO: describe other proposals and their advantages/disadvantages >> over this proposal. >> >> >> ==Compatibility== >> >> This is a hard-forking change to the Bitcoin protocol; anybody >> running code that fully validates blocks must upgrade before the >> activation time or they will risk rejecting a chain containing >> larger-than-one-megabyte blocks. >> >> Simplified Payment Verification software is not affected, unless >> it makes assumptions about the maximum depth of a transaction's >> merkle branch based on the minimum size of a transaction and the >> maximum block size. >> >> ==Implementation== >> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork >> >> >> >> _______________________________________________ bitcoin-dev mailing >> list bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > - -- > http://abis.io ~ > "a protocol concept to enable decentralization > and expansion of a giving economy, and a new social good" > https://keybase.io/odinn > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= > =ft62 > -----END PGP SIGNATURE----- > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Tue, Jun 23, 2015 at 4:50 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (3 lines)
> In particular, note how this bump is being proposed at a time when > blockchain space demand is so low that transactions usually cost well > under a penny each
Recent averages seem to be offering around $0.04... https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-2-macro-transaction-trends With various stress tests indicate needing 10x more... http://www.reddit.com/r/Bitcoin/search?restrict_sr=on&q=stress+test+fees
Quoted text (2 lines)
> a insignificant amount of money for almost all > use-cases.
Penny stocks? Voting? Notarizing? There's a whole ecosystem of non-purchase cases for which non-profit-mining fees are enabling.
Yes, but with a key distinction. Today miners may collude to (or unintentionally) lower the block size limit for blocks they win. BIP-100 introduces the possibility of lowering the block size limit for everyone over the next 12,000 blocks.
Another gap involves laziness. What is a far more likely issue is not a conspiracy but that miners will be lazy and hard code their vote values, requiring arm twisting later to change them. Preventing this headache introduces the need for more complexity, either by making the default a non-vote (which makes it easier to game the system with less voting power), or by making the default vote = MAX_BLOCK_SIZE * 1.09 (which makes the default similar is to Gavin's proposal).
I think with a default vote that is ~9% larger than the previous max block size and no option to lower the max block size then BIP-100 could work without added risk or defeating the intended purpose. Still, one has to ask if the benefit is there to justify the additional moving parts.
Quoted text (258 lines)
> On Jun 23, 2015, at 11:49 PM, Jeff Garzik <jgarzik@gmail•com> wrote: > > Miners can collude today to lower the block size limit. > > In fact, this largely happens already out of laziness - miners often follow the "soft" default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software: http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block > > > >> On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri•com> wrote: >> Here are refutations of the approach in BIP-100 here: >> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf >> >> To recap BIP-100: >> >> 1) Hard form to remove static 1MB block size limit >> 2) Add new floating block size limit set to 1MB >> 3) Historical 32MB message limit remains >> 4) Hard form on testnet 9/1/2015 >> 5) Hard form on main 1/11/2016 >> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block >> threshold by 90% of blocks >> 7) Limit increase or decrease may not exceed 2x in any one step >> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase >> scriptSig, e.g. "/BV8000000/" to vote for 8M. >> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the >> most common floor (minimum) is chosen. >> >> 8MB limits doubling just under every 2 years makes a static value grow >> in a predictable manner. >> >> BIP-100 makes a static value grow (or more importantly potentially >> shrink) in an unpredictable manner based on voting mechanics that are >> untested in this capacity in the bitcoin network. Introducing a highly >> variable and untested dynamic into an already complex system is >> unnecessarily risky. >> >> For example, the largely arbitrary voting rules listed in 9 above can be >> gamed. If I control pools or have affiliates involved in pools that >> mine slightly more than 20% of blocks, I could wait until block sizes >> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and >> "/BV5000001/" for the remaining 10%. If others don't consistently vote >> for the same "/BV#/" value, vote too consistently and have their value >> thrown out as the top 20%, I could win the resize to half capacity >> "/BV5000001/" because it was the lowest repeated value not in the bottom >> 20%. >> >> I could use this to force an exodus to my sidechain/alt coin, or to >> choke out the bitcoin network. A first improvement would be to only let >> BIP-100 raise the cap and not lower it, but if I can think of a >> vulnerability off the top of my head, there will be others on the other >> side of the equation that have not been thought of. Why bother >> introducing a rube goldberg machine like voting when a simple 8mb cap >> with predictable growth gets the job done, potentially permanently? >> >> >> On 6/23/2015 9:43 PM, odinn wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > 1) Hard fork not (necessarily) needed >> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to >> > your stuff," but rather simply to say, "Better you should work with >> > Garzik to implement BIP-100, that would be good") >> > 3) See points 1 and 2 above >> > 4) If still reading... changes should be (as you seem to have been >> > trying to lean towards)... lean towards gradual change; hence, changes >> > that would flow from this BIP would be better off oriented in a >> > process that dies not require the "way you have done it." >> > >> > You did address that, to be fair - in your TODO, this link: >> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks >> > >> > contained the following link: >> > >> > http://gavinandresen.ninja/bigger-blocks-another-way >> > >> > However, in reading that, I didn't see any meaningful statements that >> > would refute the approach in Garzik's BIP-100. >> > >> > Maybe a better way to say this is, >> > >> > Work with Jeff Garzik (which I am sure you are already having such >> > discussions in private) as well as the list discussions, >> > Move forward on BIP-100 with Garzik and other developers (not such a >> > bad plan really) and don't get caught up in XT. (If you feel you can >> > develop XT further, that is your thing but it would perhaps make you >> > lose focus, work together with other developers.) >> > >> > Relax into the process. Things will be ok. >> > >> > Respectfully, >> > >> > - -O >> > >> > On 06/22/2015 11:18 AM, Gavin Andresen wrote: >> >> I promised to write a BIP after I'd implemented >> >> increase-the-maximum-block-size code, so here it is. It also lives >> >> at: >> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki >> >> >> >> I don't expect any proposal to please everybody; there are >> >> unavoidable tradeoffs to increasing the maximum block size. I >> >> prioritize implementation simplicity -- it is hard to write >> >> consensus-critical code, so simpler is better. >> >> >> >> >> >> >> >> >> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen >> >> <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: >> >> Draft Type: Standards Track Created: 2015-06-22 >> >> >> >> ==Abstract== >> >> >> >> This BIP proposes replacing the fixed one megabyte maximum block >> >> size with a maximum size that grows over time at a predictable >> >> rate. >> >> >> >> ==Motivation== >> >> >> >> Transaction volume on the Bitcoin network has been growing, and >> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by >> >> the one megabyte maximum block size. Increasing the maximum size >> >> reduces the impact of that limit on Bitcoin adoption and growth. >> >> >> >> ==Specification== >> >> >> >> After deployment on the network (see the Deployment section for >> >> details), the maximum allowed size of a block on the main network >> >> shall be calculated based on the timestamp in the block header. >> >> >> >> The maximum size shall be 8,000,000 bytes at a timestamp of >> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double >> >> every 63,072,000 seconds (two years, ignoring leap years), until >> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of >> >> blocks in between doublings will increase linearly based on the >> >> block's timestamp. The maximum size of blocks after 2036-01-06 >> >> 00:00:00 UTC shall be 8,192,000,000 bytes. >> >> >> >> Expressed in pseudo-code, using integer math: >> >> >> >> function max_block_size(block_timestamp): >> >> >> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = >> >> 8000000 if block_timestamp >= time_start+time_double*10 return >> >> size_start * 2^10 >> >> >> >> // Piecewise-linear-between-doublings growth: time_delta = >> >> block_timestamp - t_start doublings = time_delta / time_double >> >> remainder = time_delta % time_double interpolate = (size_start * >> >> 2^doublings * remainder) / time_double max_size = size_start * >> >> 2^doublings + interpolate >> >> >> >> return max_size >> >> >> >> ==Deployment== >> >> >> >> Deployment shall be controlled by hash-power supermajority vote >> >> (similar to the technique used in BIP34), but the earliest possible >> >> activation time is 2016-01-11 00:00:00 UTC. >> >> >> >> Activation is achieved when 750 of 1,000 consecutive blocks in the >> >> best chain have a version number with bits 3 and 14 set (0x20000004 >> >> in hex). The activation time will be the timestamp of the 750'th >> >> block plus a two week (1,209,600 second) grace period to give any >> >> remaining miners or services time to upgrade to support larger >> >> blocks. If a supermajority is achieved more than two weeks before >> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 >> >> 00:00:00 UTC. >> >> >> >> Block version numbers are used only for activation; once activation >> >> is achieved, the maximum block size shall be as described in the >> >> specification section, regardless of the version number of the >> >> block. >> >> >> >> >> >> ==Rationale== >> >> >> >> The initial size of 8,000,000 bytes was chosen after testing the >> >> current reference implementation code with larger block sizes and >> >> receiving feedback from miners stuck behind bandwidth-constrained >> >> networks (in particular, Chinese miners behind the Great Firewall >> >> of China). >> >> >> >> The doubling interval was chosen based on long-term growth trends >> >> for CPU power, storage, and Internet bandwidth. The 20-year limit >> >> was chosen because exponential growth cannot continue forever. >> >> >> >> Calculations are based on timestamps and not blockchain height >> >> because a timestamp is part of every block's header. This allows >> >> implementations to know a block's maximum size after they have >> >> downloaded it's header, but before downloading any transactions. >> >> >> >> The deployment plan is taken from Jeff Garzik's proposed BIP100 >> >> block size increase, and is designed to give miners, merchants, >> >> and full-node-running-end-users sufficient time to upgrade to >> >> software that supports bigger blocks. A 75% supermajority was >> >> chosen so that one large mining pool does not have effective veto >> >> power over a blocksize increase. The version number scheme is >> >> designed to be compatible with Pieter's Wuille's proposed "Version >> >> bits" BIP. >> >> >> >> TODO: summarize objections/arguments from >> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. >> >> >> >> TODO: describe other proposals and their advantages/disadvantages >> >> over this proposal. >> >> >> >> >> >> ==Compatibility== >> >> >> >> This is a hard-forking change to the Bitcoin protocol; anybody >> >> running code that fully validates blocks must upgrade before the >> >> activation time or they will risk rejecting a chain containing >> >> larger-than-one-megabyte blocks. >> >> >> >> Simplified Payment Verification software is not affected, unless >> >> it makes assumptions about the maximum depth of a transaction's >> >> merkle branch based on the minimum size of a transaction and the >> >> maximum block size. >> >> >> >> ==Implementation== >> >> >> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork >> >> >> >> >> >> >> >> _______________________________________________ bitcoin-dev mailing >> >> list bitcoin-dev@lists•linuxfoundation•org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> > >> > - -- >> > http://abis.io ~ >> > "a protocol concept to enable decentralization >> > and expansion of a giving economy, and a new social good" >> > https://keybase.io/odinn >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v1 >> > >> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 >> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ >> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw >> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN >> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s >> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= >> > =ft62 >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists•linuxfoundation•org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
This BIP has been assigned number 101 by the BIP editor. I plan on filling in the TODOs and will submit it as a pull request to the BIP repository today.
Quoted text (1 line)
> Title: Increase Maximum Block Size
They do so by not building on larger blocks On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn@hotmail•com> wrote:
Quoted text (274 lines)
> No, they can lower their own block sizes. But they cannot currently lower > the sizes of blocks mined by others. That is not the same thing by any > stretch of the imagination. > On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail•com> wrote: > > Miners can collude today to lower the block size limit. > > In fact, this largely happens already out of laziness - miners often > follow the "soft" default limit set by Bitcoin Core, to the point where you > can chart when miners upgrade to new software: > http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block > > > > On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri•com> > wrote: > > Here are refutations of the approach in BIP-100 here: > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf > > To recap BIP-100: > > 1) Hard form to remove static 1MB block size limit > 2) Add new floating block size limit set to 1MB > 3) Historical 32MB message limit remains > 4) Hard form on testnet 9/1/2015 > 5) Hard form on main 1/11/2016 > 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block > threshold by 90% of blocks > 7) Limit increase or decrease may not exceed 2x in any one step > 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase > scriptSig, e.g. "/BV8000000/" to vote for 8M. > 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the > most common floor (minimum) is chosen. > > 8MB limits doubling just under every 2 years makes a static value grow > in a predictable manner. > > BIP-100 makes a static value grow (or more importantly potentially > shrink) in an unpredictable manner based on voting mechanics that are > untested in this capacity in the bitcoin network. Introducing a highly > variable and untested dynamic into an already complex system is > unnecessarily risky. > > For example, the largely arbitrary voting rules listed in 9 above can be > gamed. If I control pools or have affiliates involved in pools that > mine slightly more than 20% of blocks, I could wait until block sizes > are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and > "/BV5000001/" for the remaining 10%. If others don't consistently vote > for the same "/BV#/" value, vote too consistently and have their value > thrown out as the top 20%, I could win the resize to half capacity > "/BV5000001/" because it was the lowest repeated value not in the bottom > 20%. > > I could use this to force an exodus to my sidechain/alt coin, or to > choke out the bitcoin network. A first improvement would be to only let > BIP-100 raise the cap and not lower it, but if I can think of a > vulnerability off the top of my head, there will be others on the other > side of the equation that have not been thought of. Why bother > introducing a rube goldberg machine like voting when a simple 8mb cap > with predictable growth gets the job done, potentially permanently? > > > On 6/23/2015 9:43 PM, odinn wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > 1) Hard fork not (necessarily) needed > > 2) See Garzik's BIP 100, better (this is not meant to say "superior to > > your stuff," but rather simply to say, "Better you should work with > > Garzik to implement BIP-100, that would be good") > > 3) See points 1 and 2 above > > 4) If still reading... changes should be (as you seem to have been > > trying to lean towards)... lean towards gradual change; hence, changes > > that would flow from this BIP would be better off oriented in a > > process that dies not require the "way you have done it." > > > > You did address that, to be fair - in your TODO, this link: > > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks > > > > contained the following link: > > > > http://gavinandresen.ninja/bigger-blocks-another-way > > > > However, in reading that, I didn't see any meaningful statements that > > would refute the approach in Garzik's BIP-100. > > > > Maybe a better way to say this is, > > > > Work with Jeff Garzik (which I am sure you are already having such > > discussions in private) as well as the list discussions, > > Move forward on BIP-100 with Garzik and other developers (not such a > > bad plan really) and don't get caught up in XT. (If you feel you can > > develop XT further, that is your thing but it would perhaps make you > > lose focus, work together with other developers.) > > > > Relax into the process. Things will be ok. > > > > Respectfully, > > > > - -O > > > > On 06/22/2015 11:18 AM, Gavin Andresen wrote: > >> I promised to write a BIP after I'd implemented > >> increase-the-maximum-block-size code, so here it is. It also lives > >> at: > >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > >> > >> I don't expect any proposal to please everybody; there are > >> unavoidable tradeoffs to increasing the maximum block size. I > >> prioritize implementation simplicity -- it is hard to write > >> consensus-critical code, so simpler is better. > >> > >> > >> > >> > >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen > >> <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: > >> Draft Type: Standards Track Created: 2015-06-22 > >> > >> ==Abstract== > >> > >> This BIP proposes replacing the fixed one megabyte maximum block > >> size with a maximum size that grows over time at a predictable > >> rate. > >> > >> ==Motivation== > >> > >> Transaction volume on the Bitcoin network has been growing, and > >> will soon reach the one-megabyte-every-ten-minutes limit imposed by > >> the one megabyte maximum block size. Increasing the maximum size > >> reduces the impact of that limit on Bitcoin adoption and growth. > >> > >> ==Specification== > >> > >> After deployment on the network (see the Deployment section for > >> details), the maximum allowed size of a block on the main network > >> shall be calculated based on the timestamp in the block header. > >> > >> The maximum size shall be 8,000,000 bytes at a timestamp of > >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double > >> every 63,072,000 seconds (two years, ignoring leap years), until > >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of > >> blocks in between doublings will increase linearly based on the > >> block's timestamp. The maximum size of blocks after 2036-01-06 > >> 00:00:00 UTC shall be 8,192,000,000 bytes. > >> > >> Expressed in pseudo-code, using integer math: > >> > >> function max_block_size(block_timestamp): > >> > >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = > >> 8000000 if block_timestamp >= time_start+time_double*10 return > >> size_start * 2^10 > >> > >> // Piecewise-linear-between-doublings growth: time_delta = > >> block_timestamp - t_start doublings = time_delta / time_double > >> remainder = time_delta % time_double interpolate = (size_start * > >> 2^doublings * remainder) / time_double max_size = size_start * > >> 2^doublings + interpolate > >> > >> return max_size > >> > >> ==Deployment== > >> > >> Deployment shall be controlled by hash-power supermajority vote > >> (similar to the technique used in BIP34), but the earliest possible > >> activation time is 2016-01-11 00:00:00 UTC. > >> > >> Activation is achieved when 750 of 1,000 consecutive blocks in the > >> best chain have a version number with bits 3 and 14 set (0x20000004 > >> in hex). The activation time will be the timestamp of the 750'th > >> block plus a two week (1,209,600 second) grace period to give any > >> remaining miners or services time to upgrade to support larger > >> blocks. If a supermajority is achieved more than two weeks before > >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 > >> 00:00:00 UTC. > >> > >> Block version numbers are used only for activation; once activation > >> is achieved, the maximum block size shall be as described in the > >> specification section, regardless of the version number of the > >> block. > >> > >> > >> ==Rationale== > >> > >> The initial size of 8,000,000 bytes was chosen after testing the > >> current reference implementation code with larger block sizes and > >> receiving feedback from miners stuck behind bandwidth-constrained > >> networks (in particular, Chinese miners behind the Great Firewall > >> of China). > >> > >> The doubling interval was chosen based on long-term growth trends > >> for CPU power, storage, and Internet bandwidth. The 20-year limit > >> was chosen because exponential growth cannot continue forever. > >> > >> Calculations are based on timestamps and not blockchain height > >> because a timestamp is part of every block's header. This allows > >> implementations to know a block's maximum size after they have > >> downloaded it's header, but before downloading any transactions. > >> > >> The deployment plan is taken from Jeff Garzik's proposed BIP100 > >> block size increase, and is designed to give miners, merchants, > >> and full-node-running-end-users sufficient time to upgrade to > >> software that supports bigger blocks. A 75% supermajority was > >> chosen so that one large mining pool does not have effective veto > >> power over a blocksize increase. The version number scheme is > >> designed to be compatible with Pieter's Wuille's proposed "Version > >> bits" BIP. > >> > >> TODO: summarize objections/arguments from > >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. > >> > >> TODO: describe other proposals and their advantages/disadvantages > >> over this proposal. > >> > >> > >> ==Compatibility== > >> > >> This is a hard-forking change to the Bitcoin protocol; anybody > >> running code that fully validates blocks must upgrade before the > >> activation time or they will risk rejecting a chain containing > >> larger-than-one-megabyte blocks. > >> > >> Simplified Payment Verification software is not affected, unless > >> it makes assumptions about the maximum depth of a transaction's > >> merkle branch based on the minimum size of a transaction and the > >> maximum block size. > >> > >> ==Implementation== > >> > >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork > >> > >> > >> > >> _______________________________________________ bitcoin-dev mailing > >> list bitcoin-dev@lists•linuxfoundation•org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > > > > - -- > > http://abis.io ~ > > "a protocol concept to enable decentralization > > and expansion of a giving economy, and a new social good" > > https://keybase.io/odinn > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1 > > > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 > > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ > > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw > > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN > > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s > > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= > > =ft62 > > -----END PGP SIGNATURE----- > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
You really believe they would risk getting orphaned by skipping the longer chain, just to attempt to reduce average block size? No, that doesn't happen today. Laziness in leaving the default size is common. But that is not collusion, nor an attempt to manipulate the block sizes of other miners.
On 24 Jun 2015 10:05 am, Mark Friedenbach <mark@friedenbach•org> wrote:They do so by not building on larger blocks
On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn@hotmail•com> wrote: No, they can lower their own block sizes. But they cannot currently lower the sizes of blocks mined by others. That is not the same thing by any stretch of the imagination.
On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail•com> wrote: Miners can collude today to lower the block size limit.
In fact, this largely happens already out of laziness - miners often follow the "soft" default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software: http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri•com> wrote: Here are refutations of the approach in BIP-100 here:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
To recap BIP-100:
1) Hard form to remove static 1MB block size limit
2) Add new floating block size limit set to 1MB
3) Historical 32MB message limit remains
4) Hard form on testnet 9/1/2015
5) Hard form on main 1/11/2016
6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
threshold by 90% of blocks
7) Limit increase or decrease may not exceed 2x in any one step
8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
scriptSig, e.g. "/BV8000000/" to vote for 8M.
9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
most common floor (minimum) is chosen.
8MB limits doubling just under every 2 years makes a static value grow
in a predictable manner.
BIP-100 makes a static value grow (or more importantly potentially
shrink) in an unpredictable manner based on voting mechanics that are
untested in this capacity in the bitcoin network. Introducing a highly
variable and untested dynamic into an already complex system is
unnecessarily risky.
For example, the largely arbitrary voting rules listed in 9 above can be
gamed. If I control pools or have affiliates involved in pools that
mine slightly more than 20% of blocks, I could wait until block sizes
are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
"/BV5000001/" for the remaining 10%. If others don't consistently vote
for the same "/BV#/" value, vote too consistently and have their value
thrown out as the top 20%, I could win the resize to half capacity
"/BV5000001/" because it was the lowest repeated value not in the bottom
20%.
I could use this to force an exodus to my sidechain/alt coin, or to
choke out the bitcoin network. A first improvement would be to only let
BIP-100 raise the cap and not lower it, but if I can think of a
vulnerability off the top of my head, there will be others on the other
side of the equation that have not been thought of. Why bother
introducing a rube goldberg machine like voting when a simple 8mb cap
with predictable growth gets the job done, potentially permanently?
On 6/23/2015 9:43 PM, odinn wrote:
Quoted text (197 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 1) Hard fork not (necessarily) needed > 2) See Garzik's BIP 100, better (this is not meant to say "superior to > your stuff," but rather simply to say, "Better you should work with > Garzik to implement BIP-100, that would be good") > 3) See points 1 and 2 above > 4) If still reading... changes should be (as you seem to have been > trying to lean towards)... lean towards gradual change; hence, changes > that would flow from this BIP would be better off oriented in a > process that dies not require the "way you have done it." > > You did address that, to be fair - in your TODO, this link: > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks > > contained the following link: > > http://gavinandresen.ninja/bigger-blocks-another-way > > However, in reading that, I didn't see any meaningful statements that > would refute the approach in Garzik's BIP-100. > > Maybe a better way to say this is, > > Work with Jeff Garzik (which I am sure you are already having such > discussions in private) as well as the list discussions, > Move forward on BIP-100 with Garzik and other developers (not such a > bad plan really) and don't get caught up in XT. (If you feel you can > develop XT further, that is your thing but it would perhaps make you > lose focus, work together with other developers.) > > Relax into the process. Things will be ok. > > Respectfully, > > - -O > > On 06/22/2015 11:18 AM, Gavin Andresen wrote: >> I promised to write a BIP after I'd implemented >> increase-the-maximum-block-size code, so here it is. It also lives >> at: >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki >> >> I don't expect any proposal to please everybody; there are >> unavoidable tradeoffs to increasing the maximum block size. I >> prioritize implementation simplicity -- it is hard to write >> consensus-critical code, so simpler is better. >> >> >> >> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen >> <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: >> Draft Type: Standards Track Created: 2015-06-22 >> >> ==Abstract== >> >> This BIP proposes replacing the fixed one megabyte maximum block >> size with a maximum size that grows over time at a predictable >> rate. >> >> ==Motivation== >> >> Transaction volume on the Bitcoin network has been growing, and >> will soon reach the one-megabyte-every-ten-minutes limit imposed by >> the one megabyte maximum block size. Increasing the maximum size >> reduces the impact of that limit on Bitcoin adoption and growth. >> >> ==Specification== >> >> After deployment on the network (see the Deployment section for >> details), the maximum allowed size of a block on the main network >> shall be calculated based on the timestamp in the block header. >> >> The maximum size shall be 8,000,000 bytes at a timestamp of >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double >> every 63,072,000 seconds (two years, ignoring leap years), until >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of >> blocks in between doublings will increase linearly based on the >> block's timestamp. The maximum size of blocks after 2036-01-06 >> 00:00:00 UTC shall be 8,192,000,000 bytes. >> >> Expressed in pseudo-code, using integer math: >> >> function max_block_size(block_timestamp): >> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = >> 8000000 if block_timestamp >= time_start+time_double*10 return >> size_start * 2^10 >> >> // Piecewise-linear-between-doublings growth: time_delta = >> block_timestamp - t_start doublings = time_delta / time_double >> remainder = time_delta % time_double interpolate = (size_start * >> 2^doublings * remainder) / time_double max_size = size_start * >> 2^doublings + interpolate >> >> return max_size >> >> ==Deployment== >> >> Deployment shall be controlled by hash-power supermajority vote >> (similar to the technique used in BIP34), but the earliest possible >> activation time is 2016-01-11 00:00:00 UTC. >> >> Activation is achieved when 750 of 1,000 consecutive blocks in the >> best chain have a version number with bits 3 and 14 set (0x20000004 >> in hex). The activation time will be the timestamp of the 750'th >> block plus a two week (1,209,600 second) grace period to give any >> remaining miners or services time to upgrade to support larger >> blocks. If a supermajority is achieved more than two weeks before >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 >> 00:00:00 UTC. >> >> Block version numbers are used only for activation; once activation >> is achieved, the maximum block size shall be as described in the >> specification section, regardless of the version number of the >> block. >> >> >> ==Rationale== >> >> The initial size of 8,000,000 bytes was chosen after testing the >> current reference implementation code with larger block sizes and >> receiving feedback from miners stuck behind bandwidth-constrained >> networks (in particular, Chinese miners behind the Great Firewall >> of China). >> >> The doubling interval was chosen based on long-term growth trends >> for CPU power, storage, and Internet bandwidth. The 20-year limit >> was chosen because exponential growth cannot continue forever. >> >> Calculations are based on timestamps and not blockchain height >> because a timestamp is part of every block's header. This allows >> implementations to know a block's maximum size after they have >> downloaded it's header, but before downloading any transactions. >> >> The deployment plan is taken from Jeff Garzik's proposed BIP100 >> block size increase, and is designed to give miners, merchants, >> and full-node-running-end-users sufficient time to upgrade to >> software that supports bigger blocks. A 75% supermajority was >> chosen so that one large mining pool does not have effective veto >> power over a blocksize increase. The version number scheme is >> designed to be compatible with Pieter's Wuille's proposed "Version >> bits" BIP. >> >> TODO: summarize objections/arguments from >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. >> >> TODO: describe other proposals and their advantages/disadvantages >> over this proposal. >> >> >> ==Compatibility== >> >> This is a hard-forking change to the Bitcoin protocol; anybody >> running code that fully validates blocks must upgrade before the >> activation time or they will risk rejecting a chain containing >> larger-than-one-megabyte blocks. >> >> Simplified Payment Verification software is not affected, unless >> it makes assumptions about the maximum depth of a transaction's >> merkle branch based on the minimum size of a transaction and the >> maximum block size. >> >> ==Implementation== >> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork >> >> >> >> _______________________________________________ bitcoin-dev mailing >> list bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > - -- > http://abis.io ~ > "a protocol concept to enable decentralization > and expansion of a giving economy, and a new social good" > https://keybase.io/odinn > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= > =ft62 > -----END PGP SIGNATURE----- > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
This is no different than any other soft fork. Proper communication can coordinate soft forks easily.
On Wed, Jun 24, 2015 at 12:23 PM, Raystonn <raystonn@hotmail•com> wrote:
Quoted text (289 lines)
> You really believe they would risk getting orphaned by skipping the longer > chain, just to attempt to reduce average block size? No, that doesn't > happen today. Laziness in leaving the default size is common. But that is > not collusion, nor an attempt to manipulate the block sizes of other miners. > On 24 Jun 2015 10:05 am, Mark Friedenbach <mark@friedenbach•org> wrote: > > They do so by not building on larger blocks > On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn@hotmail•com> wrote: > > No, they can lower their own block sizes. But they cannot currently lower > the sizes of blocks mined by others. That is not the same thing by any > stretch of the imagination. > On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail•com> wrote: > > Miners can collude today to lower the block size limit. > > In fact, this largely happens already out of laziness - miners often > follow the "soft" default limit set by Bitcoin Core, to the point where you > can chart when miners upgrade to new software: > http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block > > > > On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri•com> > wrote: > > Here are refutations of the approach in BIP-100 here: > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf > > To recap BIP-100: > > 1) Hard form to remove static 1MB block size limit > 2) Add new floating block size limit set to 1MB > 3) Historical 32MB message limit remains > 4) Hard form on testnet 9/1/2015 > 5) Hard form on main 1/11/2016 > 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block > threshold by 90% of blocks > 7) Limit increase or decrease may not exceed 2x in any one step > 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase > scriptSig, e.g. "/BV8000000/" to vote for 8M. > 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the > most common floor (minimum) is chosen. > > 8MB limits doubling just under every 2 years makes a static value grow > in a predictable manner. > > BIP-100 makes a static value grow (or more importantly potentially > shrink) in an unpredictable manner based on voting mechanics that are > untested in this capacity in the bitcoin network. Introducing a highly > variable and untested dynamic into an already complex system is > unnecessarily risky. > > For example, the largely arbitrary voting rules listed in 9 above can be > gamed. If I control pools or have affiliates involved in pools that > mine slightly more than 20% of blocks, I could wait until block sizes > are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and > "/BV5000001/" for the remaining 10%. If others don't consistently vote > for the same "/BV#/" value, vote too consistently and have their value > thrown out as the top 20%, I could win the resize to half capacity > "/BV5000001/" because it was the lowest repeated value not in the bottom > 20%. > > I could use this to force an exodus to my sidechain/alt coin, or to > choke out the bitcoin network. A first improvement would be to only let > BIP-100 raise the cap and not lower it, but if I can think of a > vulnerability off the top of my head, there will be others on the other > side of the equation that have not been thought of. Why bother > introducing a rube goldberg machine like voting when a simple 8mb cap > with predictable growth gets the job done, potentially permanently? > > > On 6/23/2015 9:43 PM, odinn wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > 1) Hard fork not (necessarily) needed > > 2) See Garzik's BIP 100, better (this is not meant to say "superior to > > your stuff," but rather simply to say, "Better you should work with > > Garzik to implement BIP-100, that would be good") > > 3) See points 1 and 2 above > > 4) If still reading... changes should be (as you seem to have been > > trying to lean towards)... lean towards gradual change; hence, changes > > that would flow from this BIP would be better off oriented in a > > process that dies not require the "way you have done it." > > > > You did address that, to be fair - in your TODO, this link: > > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks > > > > contained the following link: > > > > http://gavinandresen.ninja/bigger-blocks-another-way > > > > However, in reading that, I didn't see any meaningful statements that > > would refute the approach in Garzik's BIP-100. > > > > Maybe a better way to say this is, > > > > Work with Jeff Garzik (which I am sure you are already having such > > discussions in private) as well as the list discussions, > > Move forward on BIP-100 with Garzik and other developers (not such a > > bad plan really) and don't get caught up in XT. (If you feel you can > > develop XT further, that is your thing but it would perhaps make you > > lose focus, work together with other developers.) > > > > Relax into the process. Things will be ok. > > > > Respectfully, > > > > - -O > > > > On 06/22/2015 11:18 AM, Gavin Andresen wrote: > >> I promised to write a BIP after I'd implemented > >> increase-the-maximum-block-size code, so here it is. It also lives > >> at: > >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > >> > >> I don't expect any proposal to please everybody; there are > >> unavoidable tradeoffs to increasing the maximum block size. I > >> prioritize implementation simplicity -- it is hard to write > >> consensus-critical code, so simpler is better. > >> > >> > >> > >> > >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen > >> <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: > >> Draft Type: Standards Track Created: 2015-06-22 > >> > >> ==Abstract== > >> > >> This BIP proposes replacing the fixed one megabyte maximum block > >> size with a maximum size that grows over time at a predictable > >> rate. > >> > >> ==Motivation== > >> > >> Transaction volume on the Bitcoin network has been growing, and > >> will soon reach the one-megabyte-every-ten-minutes limit imposed by > >> the one megabyte maximum block size. Increasing the maximum size > >> reduces the impact of that limit on Bitcoin adoption and growth. > >> > >> ==Specification== > >> > >> After deployment on the network (see the Deployment section for > >> details), the maximum allowed size of a block on the main network > >> shall be calculated based on the timestamp in the block header. > >> > >> The maximum size shall be 8,000,000 bytes at a timestamp of > >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double > >> every 63,072,000 seconds (two years, ignoring leap years), until > >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of > >> blocks in between doublings will increase linearly based on the > >> block's timestamp. The maximum size of blocks after 2036-01-06 > >> 00:00:00 UTC shall be 8,192,000,000 bytes. > >> > >> Expressed in pseudo-code, using integer math: > >> > >> function max_block_size(block_timestamp): > >> > >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = > >> 8000000 if block_timestamp >= time_start+time_double*10 return > >> size_start * 2^10 > >> > >> // Piecewise-linear-between-doublings growth: time_delta = > >> block_timestamp - t_start doublings = time_delta / time_double > >> remainder = time_delta % time_double interpolate = (size_start * > >> 2^doublings * remainder) / time_double max_size = size_start * > >> 2^doublings + interpolate > >> > >> return max_size > >> > >> ==Deployment== > >> > >> Deployment shall be controlled by hash-power supermajority vote > >> (similar to the technique used in BIP34), but the earliest possible > >> activation time is 2016-01-11 00:00:00 UTC. > >> > >> Activation is achieved when 750 of 1,000 consecutive blocks in the > >> best chain have a version number with bits 3 and 14 set (0x20000004 > >> in hex). The activation time will be the timestamp of the 750'th > >> block plus a two week (1,209,600 second) grace period to give any > >> remaining miners or services time to upgrade to support larger > >> blocks. If a supermajority is achieved more than two weeks before > >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 > >> 00:00:00 UTC. > >> > >> Block version numbers are used only for activation; once activation > >> is achieved, the maximum block size shall be as described in the > >> specification section, regardless of the version number of the > >> block. > >> > >> > >> ==Rationale== > >> > >> The initial size of 8,000,000 bytes was chosen after testing the > >> current reference implementation code with larger block sizes and > >> receiving feedback from miners stuck behind bandwidth-constrained > >> networks (in particular, Chinese miners behind the Great Firewall > >> of China). > >> > >> The doubling interval was chosen based on long-term growth trends > >> for CPU power, storage, and Internet bandwidth. The 20-year limit > >> was chosen because exponential growth cannot continue forever. > >> > >> Calculations are based on timestamps and not blockchain height > >> because a timestamp is part of every block's header. This allows > >> implementations to know a block's maximum size after they have > >> downloaded it's header, but before downloading any transactions. > >> > >> The deployment plan is taken from Jeff Garzik's proposed BIP100 > >> block size increase, and is designed to give miners, merchants, > >> and full-node-running-end-users sufficient time to upgrade to > >> software that supports bigger blocks. A 75% supermajority was > >> chosen so that one large mining pool does not have effective veto > >> power over a blocksize increase. The version number scheme is > >> designed to be compatible with Pieter's Wuille's proposed "Version > >> bits" BIP. > >> > >> TODO: summarize objections/arguments from > >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. > >> > >> TODO: describe other proposals and their advantages/disadvantages > >> over this proposal. > >> > >> > >> ==Compatibility== > >> > >> This is a hard-forking change to the Bitcoin protocol; anybody > >> running code that fully validates blocks must upgrade before the > >> activation time or they will risk rejecting a chain containing > >> larger-than-one-megabyte blocks. > >> > >> Simplified Payment Verification software is not affected, unless > >> it makes assumptions about the maximum depth of a transaction's > >> merkle branch based on the minimum size of a transaction and the > >> maximum block size. > >> > >> ==Implementation== > >> > >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork > >> > >> > >> > >> _______________________________________________ bitcoin-dev mailing > >> list bitcoin-dev@lists•linuxfoundation•org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > > > > - -- > > http://abis.io ~ > > "a protocol concept to enable decentralization > > and expansion of a giving economy, and a new social good" > > https://keybase.io/odinn > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1 > > > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 > > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ > > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw > > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN > > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s > > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= > > =ft62 > > -----END PGP SIGNATURE----- > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
Or put another way, lowering the block size limit (or cancelling an increase) is a soft fork. Like all soft forks, a majority of the hash power can force the soft fork to take place.
On Wed, Jun 24, 2015 at 10:05:42AM -0700, Mark Friedenbach wrote:
Quoted text (281 lines)
> They do so by not building on larger blocks > On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn@hotmail•com> wrote: > > > No, they can lower their own block sizes. But they cannot currently lower > > the sizes of blocks mined by others. That is not the same thing by any > > stretch of the imagination. > > On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail•com> wrote: > > > > Miners can collude today to lower the block size limit. > > > > In fact, this largely happens already out of laziness - miners often > > follow the "soft" default limit set by Bitcoin Core, to the point where you > > can chart when miners upgrade to new software: > > http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block > > > > > > > > On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri•com> > > wrote: > > > > Here are refutations of the approach in BIP-100 here: > > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf > > > > To recap BIP-100: > > > > 1) Hard form to remove static 1MB block size limit > > 2) Add new floating block size limit set to 1MB > > 3) Historical 32MB message limit remains > > 4) Hard form on testnet 9/1/2015 > > 5) Hard form on main 1/11/2016 > > 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block > > threshold by 90% of blocks > > 7) Limit increase or decrease may not exceed 2x in any one step > > 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase > > scriptSig, e.g. "/BV8000000/" to vote for 8M. > > 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the > > most common floor (minimum) is chosen. > > > > 8MB limits doubling just under every 2 years makes a static value grow > > in a predictable manner. > > > > BIP-100 makes a static value grow (or more importantly potentially > > shrink) in an unpredictable manner based on voting mechanics that are > > untested in this capacity in the bitcoin network. Introducing a highly > > variable and untested dynamic into an already complex system is > > unnecessarily risky. > > > > For example, the largely arbitrary voting rules listed in 9 above can be > > gamed. If I control pools or have affiliates involved in pools that > > mine slightly more than 20% of blocks, I could wait until block sizes > > are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and > > "/BV5000001/" for the remaining 10%. If others don't consistently vote > > for the same "/BV#/" value, vote too consistently and have their value > > thrown out as the top 20%, I could win the resize to half capacity > > "/BV5000001/" because it was the lowest repeated value not in the bottom > > 20%. > > > > I could use this to force an exodus to my sidechain/alt coin, or to > > choke out the bitcoin network. A first improvement would be to only let > > BIP-100 raise the cap and not lower it, but if I can think of a > > vulnerability off the top of my head, there will be others on the other > > side of the equation that have not been thought of. Why bother > > introducing a rube goldberg machine like voting when a simple 8mb cap > > with predictable growth gets the job done, potentially permanently? > > > > > > On 6/23/2015 9:43 PM, odinn wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > 1) Hard fork not (necessarily) needed > > > 2) See Garzik's BIP 100, better (this is not meant to say "superior to > > > your stuff," but rather simply to say, "Better you should work with > > > Garzik to implement BIP-100, that would be good") > > > 3) See points 1 and 2 above > > > 4) If still reading... changes should be (as you seem to have been > > > trying to lean towards)... lean towards gradual change; hence, changes > > > that would flow from this BIP would be better off oriented in a > > > process that dies not require the "way you have done it." > > > > > > You did address that, to be fair - in your TODO, this link: > > > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks > > > > > > contained the following link: > > > > > > http://gavinandresen.ninja/bigger-blocks-another-way > > > > > > However, in reading that, I didn't see any meaningful statements that > > > would refute the approach in Garzik's BIP-100. > > > > > > Maybe a better way to say this is, > > > > > > Work with Jeff Garzik (which I am sure you are already having such > > > discussions in private) as well as the list discussions, > > > Move forward on BIP-100 with Garzik and other developers (not such a > > > bad plan really) and don't get caught up in XT. (If you feel you can > > > develop XT further, that is your thing but it would perhaps make you > > > lose focus, work together with other developers.) > > > > > > Relax into the process. Things will be ok. > > > > > > Respectfully, > > > > > > - -O > > > > > > On 06/22/2015 11:18 AM, Gavin Andresen wrote: > > >> I promised to write a BIP after I'd implemented > > >> increase-the-maximum-block-size code, so here it is. It also lives > > >> at: > > >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki > > >> > > >> I don't expect any proposal to please everybody; there are > > >> unavoidable tradeoffs to increasing the maximum block size. I > > >> prioritize implementation simplicity -- it is hard to write > > >> consensus-critical code, so simpler is better. > > >> > > >> > > >> > > >> > > >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen > > >> <gavinandresen@gmail•com <mailto:gavinandresen@gmail.com>> Status: > > >> Draft Type: Standards Track Created: 2015-06-22 > > >> > > >> ==Abstract== > > >> > > >> This BIP proposes replacing the fixed one megabyte maximum block > > >> size with a maximum size that grows over time at a predictable > > >> rate. > > >> > > >> ==Motivation== > > >> > > >> Transaction volume on the Bitcoin network has been growing, and > > >> will soon reach the one-megabyte-every-ten-minutes limit imposed by > > >> the one megabyte maximum block size. Increasing the maximum size > > >> reduces the impact of that limit on Bitcoin adoption and growth. > > >> > > >> ==Specification== > > >> > > >> After deployment on the network (see the Deployment section for > > >> details), the maximum allowed size of a block on the main network > > >> shall be calculated based on the timestamp in the block header. > > >> > > >> The maximum size shall be 8,000,000 bytes at a timestamp of > > >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double > > >> every 63,072,000 seconds (two years, ignoring leap years), until > > >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of > > >> blocks in between doublings will increase linearly based on the > > >> block's timestamp. The maximum size of blocks after 2036-01-06 > > >> 00:00:00 UTC shall be 8,192,000,000 bytes. > > >> > > >> Expressed in pseudo-code, using integer math: > > >> > > >> function max_block_size(block_timestamp): > > >> > > >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = > > >> 8000000 if block_timestamp >= time_start+time_double*10 return > > >> size_start * 2^10 > > >> > > >> // Piecewise-linear-between-doublings growth: time_delta = > > >> block_timestamp - t_start doublings = time_delta / time_double > > >> remainder = time_delta % time_double interpolate = (size_start * > > >> 2^doublings * remainder) / time_double max_size = size_start * > > >> 2^doublings + interpolate > > >> > > >> return max_size > > >> > > >> ==Deployment== > > >> > > >> Deployment shall be controlled by hash-power supermajority vote > > >> (similar to the technique used in BIP34), but the earliest possible > > >> activation time is 2016-01-11 00:00:00 UTC. > > >> > > >> Activation is achieved when 750 of 1,000 consecutive blocks in the > > >> best chain have a version number with bits 3 and 14 set (0x20000004 > > >> in hex). The activation time will be the timestamp of the 750'th > > >> block plus a two week (1,209,600 second) grace period to give any > > >> remaining miners or services time to upgrade to support larger > > >> blocks. If a supermajority is achieved more than two weeks before > > >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 > > >> 00:00:00 UTC. > > >> > > >> Block version numbers are used only for activation; once activation > > >> is achieved, the maximum block size shall be as described in the > > >> specification section, regardless of the version number of the > > >> block. > > >> > > >> > > >> ==Rationale== > > >> > > >> The initial size of 8,000,000 bytes was chosen after testing the > > >> current reference implementation code with larger block sizes and > > >> receiving feedback from miners stuck behind bandwidth-constrained > > >> networks (in particular, Chinese miners behind the Great Firewall > > >> of China). > > >> > > >> The doubling interval was chosen based on long-term growth trends > > >> for CPU power, storage, and Internet bandwidth. The 20-year limit > > >> was chosen because exponential growth cannot continue forever. > > >> > > >> Calculations are based on timestamps and not blockchain height > > >> because a timestamp is part of every block's header. This allows > > >> implementations to know a block's maximum size after they have > > >> downloaded it's header, but before downloading any transactions. > > >> > > >> The deployment plan is taken from Jeff Garzik's proposed BIP100 > > >> block size increase, and is designed to give miners, merchants, > > >> and full-node-running-end-users sufficient time to upgrade to > > >> software that supports bigger blocks. A 75% supermajority was > > >> chosen so that one large mining pool does not have effective veto > > >> power over a blocksize increase. The version number scheme is > > >> designed to be compatible with Pieter's Wuille's proposed "Version > > >> bits" BIP. > > >> > > >> TODO: summarize objections/arguments from > > >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. > > >> > > >> TODO: describe other proposals and their advantages/disadvantages > > >> over this proposal. > > >> > > >> > > >> ==Compatibility== > > >> > > >> This is a hard-forking change to the Bitcoin protocol; anybody > > >> running code that fully validates blocks must upgrade before the > > >> activation time or they will risk rejecting a chain containing > > >> larger-than-one-megabyte blocks. > > >> > > >> Simplified Payment Verification software is not affected, unless > > >> it makes assumptions about the maximum depth of a transaction's > > >> merkle branch based on the minimum size of a transaction and the > > >> maximum block size. > > >> > > >> ==Implementation== > > >> > > >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork > > >> > > >> > > >> > > >> _______________________________________________ bitcoin-dev mailing > > >> list bitcoin-dev@lists•linuxfoundation•org > > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > >> > > > > > > - -- > > > http://abis.io ~ > > > "a protocol concept to enable decentralization > > > and expansion of a giving economy, and a new social good" > > > https://keybase.io/odinn > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1 > > > > > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 > > > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ > > > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw > > > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN > > > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s > > > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= > > > =ft62 > > > -----END PGP SIGNATURE----- > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists•linuxfoundation•org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
60% of the hashrate can easily agree to force a softfork which reduces the block size. As soon as the fork occurs, there is a very strong incentive for all the remaining 40% to go along with it: if they don't, they're mining worthless blocks.
They can use a BIP-34 style mechanism to trigger the fork so there's negligible risk to the miners.
On Wed, Jun 24, 2015 at 10:23:18AM -0700, Raystonn wrote:
Quoted text (263 lines)
> <p dir="ltr">You really believe they would risk getting orphaned by skipping the longer chain, just to attempt to reduce average block size? No, that doesn't happen today. Laziness in leaving the default size is common. But that is not collusion, nor an attempt to manipulate the block sizes of other miners.<br> > </p> > <div class="gmail_quote">On 24 Jun 2015 10:05 am, Mark Friedenbach <mark@friedenbach•org> wrote:<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">They do so by not building on larger blocks</p> > <div class="elided-text">On Jun 23, 2015 9:31 PM, "Raystonn" <<a href="mailto:raystonn@hotmail.com">raystonn@hotmail.com</a>> wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">No, they can lower their own block sizes.?? But they cannot currently lower the sizes of blocks mined by others.?? That is not the same thing by any stretch of the imagination.</p> > <div class="elided-text">On 23 Jun 2015 8:50 pm, Jeff Garzik <<a href="mailto:jgarzik@gmail.com">jgarzik@gmail.com</a>> wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Miners can collude today to lower the block size limit.<div><br /></div><div>In fact, this largely happens already out of laziness - miners often follow the "soft" default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software:??<a href="http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block">http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block</a></div><div><br /></div><div><br /></div></div><div><br /><div>On Tue, Jun 23, 2015 at 8:05 PM, William Madden <span dir="ltr"><<a href="mailto:will.madden@novauri.com">will.madden@novauri.com</a>></span> wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">Here are refutations of the approach in BIP-100 here:<br /> > <a href="http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf">http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf</a><br /> > <br /> > To recap BIP-100:<br /> > <br /> > 1) Hard form to remove static 1MB block size limit<br /> > 2) Add new floating block size limit set to 1MB<br /> > 3) Historical 32MB message limit remains<br /> > 4) Hard form on testnet 9/1/2015<br /> > 5) Hard form on main 1/11/2016<br /> > 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block<br /> > threshold by 90% of blocks<br /> > 7) Limit increase or decrease may not exceed 2x in any one step<br /> > 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase<br /> > scriptSig, e.g. "/BV8000000/" to vote for 8M.<br /> > 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the<br /> > most common floor (minimum) is chosen.<br /> > <br /> > 8MB limits doubling just under every 2 years makes a static value grow<br /> > in a predictable manner.<br /> > <br /> > BIP-100 makes a static value grow (or more importantly potentially<br /> > shrink) in an unpredictable manner based on voting mechanics that are<br /> > untested in this capacity in the bitcoin network.?? Introducing a highly<br /> > variable and untested dynamic into an already complex system is<br /> > unnecessarily risky.<br /> > <br /> > For example, the largely arbitrary voting rules listed in 9 above can be<br /> > gamed.?? If I control pools or have affiliates involved in pools that<br /> > mine slightly more than 20% of blocks, I could wait until block sizes<br /> > are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and<br /> > "/BV5000001/" for the remaining 10%.?? If others don't consistently vote<br /> > for the same "/BV#/" value, vote too consistently and have their value<br /> > thrown out as the top 20%, I could win the resize to half capacity<br /> > "/BV5000001/" because it was the lowest repeated value not in the bottom<br /> > 20%.<br /> > <br /> > I could use this to force an exodus to my sidechain/alt coin, or to<br /> > choke out the bitcoin network.?? A first improvement would be to only let<br /> > BIP-100 raise the cap and not lower it, but if I can think of a<br /> > vulnerability off the top of my head, there will be others on the other<br /> > side of the equation that have not been thought of.?? Why bother<br /> > introducing a rube goldberg machine like voting when a simple 8mb cap<br /> > with predictable growth gets the job done, potentially permanently?<br /> > <div><div><br /> > <br /> > On 6/23/2015 9:43 PM, odinn wrote:<br /> > > -----BEGIN PGP SIGNED MESSAGE-----<br /> > > Hash: SHA1<br /> > ><br /> > > 1) Hard fork not (necessarily) needed<br /> > > 2) See Garzik's BIP 100, better (this is not meant to say "superior to<br /> > > your stuff," but rather simply to say, "Better you should work with<br /> > > Garzik to implement BIP-100, that would be good")<br /> > > 3) See points 1 and 2 above<br /> > > 4) If still reading... changes should be (as you seem to have been<br /> > > trying to lean towards)... lean towards gradual change; hence, changes<br /> > > that would flow from this BIP would be better off oriented in a<br /> > > process that dies not require the "way you have done it."<br /> > ><br /> > > You did address that, to be fair - in your TODO, this link:<br /> > > <a href="http://gavinandresen.ninja/time-to-roll-out-bigger-blocks">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a><br /> > ><br /> > > contained the following link:<br /> > ><br /> > > <a href="http://gavinandresen.ninja/bigger-blocks-another-way">http://gavinandresen.ninja/bigger-blocks-another-way</a><br /> > ><br /> > > However, in reading that, I didn't see any meaningful statements that<br /> > > would refute the approach in Garzik's BIP-100.<br /> > ><br /> > > Maybe a better way to say this is,<br /> > ><br /> > > Work with Jeff Garzik (which I am sure you are already having such<br /> > > discussions in private) as well as the list discussions,<br /> > > Move forward on BIP-100 with Garzik and other developers (not such a<br /> > > bad plan really) and don't get caught up in XT.?? (If you feel you can<br /> > > develop XT further, that is your thing but it would perhaps make you<br /> > > lose focus, work together with other developers.)<br /> > ><br /> > > Relax into the process.?? Things will be ok.<br /> > ><br /> > > Respectfully,<br /> > ><br /> > > - -O<br /> > ><br /> > > On 06/22/2015 11:18 AM, Gavin Andresen wrote:<br /> > >> I promised to write a BIP after I'd implemented<br /> > >> increase-the-maximum-block-size code, so here it is. It also lives<br /> > >> at:<br /> > >> <a href="https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki">https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki</a><br /> > >><br /> > >>?? I don't expect any proposal to please everybody; there are<br /> > >> unavoidable tradeoffs to increasing the maximum block size. I<br /> > >> prioritize implementation simplicity -- it is hard to write<br /> > >> consensus-critical code, so simpler is better.<br /> > >><br /> > >><br /> > >><br /> > >><br /> > >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen<br /> > >> <<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a> <mailto:<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>>> Status:<br /> > >> Draft Type: Standards Track Created: 2015-06-22<br /> > >><br /> > >> ==Abstract==<br /> > >><br /> > >> This BIP proposes replacing the fixed one megabyte maximum block<br /> > >> size with a maximum size that grows over time at a predictable<br /> > >> rate.<br /> > >><br /> > >> ==Motivation==<br /> > >><br /> > >> Transaction volume on the Bitcoin network has been growing, and<br /> > >> will soon reach the one-megabyte-every-ten-minutes limit imposed by<br /> > >> the one megabyte maximum block size. Increasing the maximum size<br /> > >> reduces the impact of that limit on Bitcoin adoption and growth.<br /> > >><br /> > >> ==Specification==<br /> > >><br /> > >> After deployment on the network (see the Deployment section for<br /> > >> details), the maximum allowed size of a block on the main network<br /> > >> shall be calculated based on the timestamp in the block header.<br /> > >><br /> > >> The maximum size shall be 8,000,000 bytes at a timestamp of<br /> > >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double<br /> > >> every 63,072,000 seconds (two years, ignoring leap years), until<br /> > >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of<br /> > >> blocks in between doublings will increase linearly based on the<br /> > >> block's timestamp. The maximum size of blocks after 2036-01-06<br /> > >> 00:00:00 UTC shall be 8,192,000,000 bytes.<br /> > >><br /> > >> Expressed in pseudo-code, using integer math:<br /> > >><br /> > >> function max_block_size(block_timestamp):<br /> > >><br /> > >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =<br /> > >> 8000000 if block_timestamp >= time_start+time_double*10 return<br /> > >> size_start * 2^10<br /> > >><br /> > >> // Piecewise-linear-between-doublings growth: time_delta =<br /> > >> block_timestamp - t_start doublings = time_delta / time_double<br /> > >> remainder = time_delta % time_double interpolate = (size_start *<br /> > >> 2^doublings * remainder) / time_double max_size = size_start *<br /> > >> 2^doublings + interpolate<br /> > >><br /> > >> return max_size<br /> > >><br /> > >> ==Deployment==<br /> > >><br /> > >> Deployment shall be controlled by hash-power supermajority vote<br /> > >> (similar to the technique used in BIP34), but the earliest possible<br /> > >> activation time is 2016-01-11 00:00:00 UTC.<br /> > >><br /> > >> Activation is achieved when 750 of 1,000 consecutive blocks in the<br /> > >> best chain have a version number with bits 3 and 14 set (0x20000004<br /> > >> in hex). The activation time will be the timestamp of the 750'th<br /> > >> block plus a two week (1,209,600 second) grace period to give any<br /> > >> remaining miners or services time to upgrade to support larger<br /> > >> blocks. If a supermajority is achieved more than two weeks before<br /> > >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11<br /> > >> 00:00:00 UTC.<br /> > >><br /> > >> Block version numbers are used only for activation; once activation<br /> > >> is achieved, the maximum block size shall be as described in the<br /> > >> specification section, regardless of the version number of the<br /> > >> block.<br /> > >><br /> > >><br /> > >> ==Rationale==<br /> > >><br /> > >> The initial size of 8,000,000 bytes was chosen after testing the<br /> > >> current reference implementation code with larger block sizes and<br /> > >> receiving feedback from miners stuck behind bandwidth-constrained<br /> > >> networks (in particular, Chinese miners behind the Great Firewall<br /> > >> of China).<br /> > >><br /> > >> The doubling interval was chosen based on long-term growth trends<br /> > >> for CPU power, storage, and Internet bandwidth. The 20-year limit<br /> > >> was chosen because exponential growth cannot continue forever.<br /> > >><br /> > >> Calculations are based on timestamps and not blockchain height<br /> > >> because a timestamp is part of every block's header. This allows<br /> > >> implementations to know a block's maximum size after they have<br /> > >> downloaded it's header, but before downloading any transactions.<br /> > >><br /> > >> The deployment plan is taken from Jeff Garzik's proposed BIP100<br /> > >> block size increase, and is designed to give miners, merchants,<br /> > >> and full-node-running-end-users sufficient time to upgrade to<br /> > >> software that supports bigger blocks. A 75% supermajority was<br /> > >> chosen so that one large mining pool does not have effective veto<br /> > >> power over a blocksize increase. The version number scheme is<br /> > >> designed to be compatible with Pieter's Wuille's proposed "Version<br /> > >> bits" BIP.<br /> > >><br /> > >> TODO: summarize objections/arguments from<br /> > >> <a href="http://gavinandresen.ninja/time-to-roll-out-bigger-blocks">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a>.<br /> > >><br /> > >> TODO: describe other proposals and their advantages/disadvantages<br /> > >> over this proposal.<br /> > >><br /> > >><br /> > >> ==Compatibility==<br /> > >><br /> > >> This is a hard-forking change to the Bitcoin protocol; anybody<br /> > >> running code that fully validates blocks must upgrade before the<br /> > >> activation time or they will risk rejecting a chain containing<br /> > >> larger-than-one-megabyte blocks.<br /> > >><br /> > >> Simplified Payment Verification software is not affected, unless<br /> > >> it makes assumptions about the maximum depth of a transaction's<br /> > >> merkle branch based on the minimum size of a transaction and the<br /> > >> maximum block size.<br /> > >><br /> > >> ==Implementation==<br /> > >><br /> > >> <a href="https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork">https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork</a><br /> > >><br /> > >><br /> > >><br /> > >> _______________________________________________ bitcoin-dev mailing<br /> > >> list <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br /> > >> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /> > >><br /> > ><br /> > > - --<br /> > > <a href="http://abis.io">http://abis.io</a> ~<br /> > > "a protocol concept to enable decentralization<br /> > > and expansion of a giving economy, and a new social good"<br /> > > <a href="https://keybase.io/odinn">https://keybase.io/odinn</a><br /> > > -----BEGIN PGP SIGNATURE-----<br /> > > Version: GnuPG v1<br /> > ><br /> > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175<br /> > > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+<br /> > > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw<br /> > > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN<br /> > > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s<br /> > > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=<br /> > > =ft62<br /> > > -----END PGP SIGNATURE-----<br /> > > _______________________________________________<br /> > > bitcoin-dev mailing list<br /> > > <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br /> > > <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /> > ><br /> > _______________________________________________<br /> > bitcoin-dev mailing list<br /> > <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br /> > <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /> > </div></div></blockquote></div><br /></div> > </blockquote></div><br />_______________________________________________<br /> > bitcoin-dev mailing list<br /> > <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br /> > <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /> > <br /></blockquote></div> > </blockquote></div> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Dear Gavin,
Thank you for your kind consideration and for working within the established BIP process.
p.
On Wed, Jun 24, 2015 at 9:44 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (16 lines)
> This BIP has been assigned number 101 by the BIP editor. I plan on filling > in the TODOs and will submit it as a pull request to the BIP repository > today. > > > Title: Increase Maximum Block Size > > -- > -- > Gavin Andresen > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik@gmail•com> wrote:
Quoted text (1 line)
>Miners can collude today to lower the block size limit.
Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism?
You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway.
Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway.
* but with a safer "supermajority" than 75% please :)
Note Jeff's proposal and Greg Maxwell's flexcap proposals also have a growth limiter as a hard-cap and a mechanism for influencing a dynamic cap within that envelope.
The hard-cap serves the purpose of a safety limit in case our understanding about the economics, incentives or game-theory is wrong worst case.
More comments to follow.
Adam
On 25 June 2015 at 15:50, Gareth Williams <gacrux@gmail•com> wrote:
Quoted text (16 lines)
> On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik@gmail•com> wrote: >>Miners can collude today to lower the block size limit. > > Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism? > > You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway. > > Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway. > > * but with a safer "supermajority" than 75% please :) > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace•org> wrote:
Quoted text (4 lines)
> The hard-cap serves the purpose of a safety limit in case our > understanding about the economics, incentives or game-theory is wrong > worst case. >
True.
BIP 100 and 101 could be combined. Would that increase consensus?
- Miner vote threshold reached - Wait notice period or until earliest start time - Block size default target set to 1 MB - Soft limit set to 1MB - Hard limit set to 8MB + double every 2 years - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum)
Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks.
Miners could leave the 1MB limit in place initially. The vote is to get the option to increase the block size.
Legacy clients would remain in the network until >80% of miners vote to raise the limit and a miner produces a >1MB block.
If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it.
The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal.
Make the default soft vote = to previous max block size * 1.09 every 12k (or whatever mirrors the hard cap growth rate) and don't allow voting to lower the soft limit and I think you have something.
You need a default that grows because most miners are lazy and will do squirrelly things like hard code 8000000 as their vote permanently.
Make the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting.
Quoted text (31 lines)
> On Jun 26, 2015, at 9:47 AM, Tier Nolan <tier.nolan@gmail•com> wrote: > >> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace•org> wrote: >> The hard-cap serves the purpose of a safety limit in case our >> understanding about the economics, incentives or game-theory is wrong >> worst case. > > True. > > BIP 100 and 101 could be combined. Would that increase consensus? > > - Miner vote threshold reached > - Wait notice period or until earliest start time > - Block size default target set to 1 MB > - Soft limit set to 1MB > - Hard limit set to 8MB + double every 2 years > - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum) > > Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks. > > Miners could leave the 1MB limit in place initially. The vote is to get the option to increase the block size. > > Legacy clients would remain in the network until >80% of miners vote to raise the limit and a miner produces a >1MB block. > > If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it. > > The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Fri, Jun 26, 2015 at 11:13 AM, Will <will.madden@novauri•com> wrote:
Quoted text (2 lines)
> Make the lazy miners' default choice grow at the hard cap growth rate and > you should be ok if you want voting.
I think the default block size is an orthogonal issue to the max block size.
HOWEVER: I think changing the default 'target' block size from the current, fixed 750K to the average of the size of the last N blocks would have some nice properties. It is policy-neutral (we should get out of the business of deciding the right block size and let the miners who care drive block size up or down) and if there are a significant proportion of lazy miners going with defaults it gives the system a healthy "fee pressure."
Moving averages have upsides and downsides vs fixed growth. Moving averages are backwards looking and don't handle seasonalities or unanticipated increases in demand very well.
Think "Black Friday" or the horribly named "Cyber Monday" in retail or market hysteria where millions of noobs jump into or out of bitcoin.
If you want to create fee pressure I think this can be done, but I would keep both of these in mind before choosing a value for N. Adjustments would need to be frequent and nimble enough to handle seasonalities and other unanticipated outliers.
Quoted text (12 lines)
> On Jun 26, 2015, at 1:39 PM, Gavin Andresen <gavinandresen@gmail•com> wrote: > >> On Fri, Jun 26, 2015 at 11:13 AM, Will <will.madden@novauri•com> wrote: >> Make the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting. > > I think the default block size is an orthogonal issue to the max block size. > > HOWEVER: I think changing the default 'target' block size from the current, fixed 750K to the average of the size of the last N blocks would have some nice properties. It is policy-neutral (we should get out of the business of deciding the right block size and let the miners who care drive block size up or down) and if there are a significant proportion of lazy miners going with defaults it gives the system a healthy "fee pressure." > > -- > -- > Gavin Andresen
On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
Quoted text (11 lines)
> On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@petertodd•org> wrote: > > > Pieter Wuille showed with simulations that miners with bad connectivity > > are negatively affected by other miners creating larger blocks. > > > > ... but the effect is only significant if they have an absurdly > low-bandwidth connection and do NOTHING to work around it (like rent a > server on the other side of the bandwidth bottleneck and write some code to > make sure you're creating blocks that will propagate quickly on both sides > of the bottleneck).
"Just rent a server" forces miners into deploying insecure hosted infrastructure that's vulnerable to hacking and seizure; that we encourage this already is worrying; requiring it for miners to be profitable isn't acceptable.
Quoted text (4 lines)
> Why do you think connectivity is a centralizing effect? It is just one > factor in the profitability-of-mining equation. A location with bad > connectivity (the US, maybe) but 10% cheaper electricity might be just as > good as one with great connectivity but more expensive electricity.
See above. The obvious thing to do if connectivity matters is keep your hashing in the cheapest possible place and sell that hashing power to centralized miners, an effect we're already seeing. Making this effect about an order of magnitude worse, then doubling the problem every two years is dangerous.
Quoted text (3 lines)
> Having lots of variables in the profitability equation is a decentralizing > force, it means there is very likely to be several different places in the > world / on the net where mining is equally profitable.
As mining and hashing can be trivially separated that theory just doesn't work.
Again, what concretely works against centralization of mining control? A proper proposal would discuss this issue, and explain what the expected effect will be.
Quoted text (6 lines)
> > These block propagation improvements are both already implemented (Matt > > Corallo's relay network, p2pool) and require co-operation. > > > > Long term the p2p protocol will evolve to incorporate those optimizations, > so will require no co-operation.
The co-operation comes form the fact that mempool policies have to be syncronized, not the protocol itself.
On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
Quoted text (11 lines)
> > In any case, this ponts to the need for your proposal to explictly talk > > about what kind of resources are needed by miners for what kind of > > profitability, including the case where other miners are sabotaging > > their profitability. > > > > Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ? > > I have written quite a lot about the kind of resources needed to run a full > node, and have asked you, specifically, several times "how much do you > think is too much" and received no answer.
You're the one proposing a change here; we're evaluating the safety of that change.
An analogous situation is imagine we have two islands, with a suspension bridge between them. The bridge has just two lanes in either direction, so obviously there's a limited amount of traffic that can flow across it. It used to be used to little that people would joyride back and forth as the toll booths at either end just charged a hundreth of a penny per trip, or even not at all, but as demand has been increasing tolls are going up as well.
You've come along with a bold new plan to add fifteen more lanes to that bridge by expanding the bridge deck, then hire contractors in advance to double the number of lanes every two years after that with no clear way of terminating their contract if anything goes wrong. (in just over a decade our two lane bridge will be a mile wide!)
Of course, obviously if we add enough lanes the cables holding it up will snap, so we've better carefully analyse the carrying capacity of the brdige and the threats it faces. For instance, earthquakes happen every so often - the last one even snapped a few strands in the main cables, which people claim were fixed... but we don't really know for sure as a thick layer of paint was quickly slapped over the fix and no-one's been able to inspect it.
It's perfectly reasonable to ask what kind of earthquakes you expect the bridge to withstand, as well as peer-reviewed and peer-reproducable figures about the strength of the cables and the weight of the traffic. Similarly, we've got the funds to make a test bridge of the same dimensions and see if it collapses. Any bridge widening proposal that doesn't have this data is simply incomplete, end of story.
As for the other side, the worst that happens if nothing changes is usage of this bridge gets proportioned to the most valuable users by the supply and demand toll system. Some people might decide to take the bus across rather than an inefficient individual car, some of the advertising companies running trucks back and forth with billboards on the side are going to stop doing that. But traffic is still going to get across. It's not a politically easy position to be in - there's enormous pressure to quickly "do something" however dangerous - but the actual effects of doing nothing are ultimately not a big deal.
In civil engineering we have enough experience with disasters to know that you can't give into political pressure to do potentially dangerous things until the consequences are well understood; hopefully we'll learn that in the consensus cryptography space before a big disaster rather than after.
Dear all,
On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
Quoted text (3 lines)
> I promised to write a BIP after I'd implemented > increase-the-maximum-block-size code, so here it is. It also lives at: > https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
The URL is dead, and the BIP moved here: https://github.com/gavinandresen/bips/blob/blocksize/bip-0101.mediawiki
Corresponding Pull Request: https://github.com/bitcoin/bips/pull/163/
Best regards, Dr. Carsten Otto
On Fri, Jun 26, 2015 at 3:08 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (20 lines)
> On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote: > > On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@petertodd•org> wrote: > > > > > Pieter Wuille showed with simulations that miners with bad connectivity > > > are negatively affected by other miners creating larger blocks. > > > > > > > ... but the effect is only significant if they have an absurdly > > low-bandwidth connection and do NOTHING to work around it (like rent a > > server on the other side of the bandwidth bottleneck and write some code > to > > make sure you're creating blocks that will propagate quickly on both > sides > > of the bottleneck). > > "Just rent a server" forces miners into deploying insecure hosted > infrastructure that's vulnerable to hacking and seizure; that we > encourage this already is worrying; requiring it for miners to be > profitable isn't acceptable. >
There are a number of factors that contribute to mining vulnerabilities. For example, presuming a miner is a meaningful contributor to the network, they'll be using more electricity than their neighbors and will be easily identifiable in the same way illegal grow-houses are identified by the local power company working with authorities. A hacked or seized hosted server is far easier to recover from than seized equipment. Its hard to see how requiring a reasonably reliable internet connection is a particularly high barrier to entry when compared to the other mining requirements, such as funds to purchase ASICs, competitive electricity costs, reasonable belief that equipment won't be stolen or seized, the technical knowledge for setting up a p2pool node, etc.
If Bitcoin is a $3bn project where stakeholder interests are to be safeguarded, or if Bitcoin is to be compared to a civil engineering project where life and death is at stake, it seems only logical that a well-defined and well-documented process be introduced to properly evaluate proposed changes. Although too late for the block size debate, it seems odd that discussion of such a process is often dismissed out of hand.
To maintain the current approach of supermajority consensus, based around ingrained wisdom, personal preference and unwritten rules would suggest that Bitcoin is still an experiment, in which case perhaps any decision regarding the block size should be based upon technical merit alone rather than economic interest.
--Simon
Quoted text (1 line)
> You're the one proposing a change here; we're evaluating the safety of
that change.
Quoted text (5 lines)
> In civil engineering we have enough experience with disasters to know > that you can't give into political pressure to do potentially dangerous > things until the consequences are well understood; hopefully we'll learn > that in the consensus cryptography space before a big disaster rather > than after.
It is actually not odd at all that a formal process is dismissed out of hand. It is all about protecting turf and holding on to power. If there is a well defined process then that takes the power out of the hands of the people who have been running the show and making up the rules. In some cases developers see Bitcoin as their "baby" and they think they must control it in order to protect it but in doing so they can become an "overprotective parent." Another problem is that some people in Bitcoin have disdain for the people they need such as financial, economic, security, and legal experts. Some think they are smarter than those people because they discovered Bitcoin first and they think their knowledge of Bitcoin means they are also superior in all these other areas. I have seen some discussions of developers who have met with people from the financial sector and they come out of the meeting with the attitude that all the experts are stupid and that Bitcoiners have everything figured out. One developer tried to tell me that you can't do systems engineering in Bitcoin because it involves security rather than safety (of course that issue has been well vetted and NIST has a whole series of documents to address that very issue http://csrc.nist.gov/publications/PubsSPs.html).
Russ
On 6/26/2015 6:16 PM, Simon Liu wrote:
Quoted text (29 lines)
> If Bitcoin is a $3bn project where stakeholder interests are to be > safeguarded, or if Bitcoin is to be compared to a civil engineering > project where life and death is at stake, it seems only logical that a > well-defined and well-documented process be introduced to properly > evaluate proposed changes. Although too late for the block size debate, > it seems odd that discussion of such a process is often dismissed out of > hand. > > To maintain the current approach of supermajority consensus, based > around ingrained wisdom, personal preference and unwritten rules would > suggest that Bitcoin is still an experiment, in which case perhaps any > decision regarding the block size should be based upon technical merit > alone rather than economic interest. > > --Simon > >> You're the one proposing a change here; we're evaluating the safety of > that change. > >> In civil engineering we have enough experience with disasters to know >> that you can't give into political pressure to do potentially dangerous >> things until the consequences are well understood; hopefully we'll learn >> that in the consensus cryptography space before a big disaster rather >> than after. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
(My replies below)
On 06/26/2015 06:47 AM, Tier Nolan wrote:
Quoted text (9 lines)
> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace•org > <mailto:adam@cypherspace.org>> wrote: > > The hard-cap serves the purpose of a safety limit in case our > understanding about the economics, incentives or game-theory is > wrong worst case. > > > True.
Yep.
Quoted text (2 lines)
> > BIP 100 and 101 could be combined. Would that increase consensus?
Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100 is a better alternative to Gavin's proposal(s), but that I didn't think that this should be taken to mean that I am saying one thing is "superior" to Gavin's work, rather, I emphasized that Gavin work with Jeff and Adam.
At least, at this stage the things are in a BIP process.
If the BIP 100 and BIP 101 would be combined, what would that look like on paper?
Quoted text (28 lines)
> > - Miner vote threshold reached - Wait notice period or until > earliest start time - Block size default target set to 1 MB - Soft > limit set to 1MB - Hard limit set to 8MB + double every 2 years - > Miner vote to decide soft limit (lowest size ignoring bottom 20% > but 1MB minimum) > > Block size updates could be aligned with the difficulty setting > and based on the last 2016 blocks. > > Miners could leave the 1MB limit in place initially. The vote is > to get the option to increase the block size. > > Legacy clients would remain in the network until >80% of miners > vote to raise the limit and a miner produces a >1MB block. > > If the growth rate over-estimates hardware improvements, the devs > could add a limit into the core client. If they give notice and > enough users update, then miners would have to accept it. > > The block size becomes min(miner's vote, core devs). Even if 4 > years notice is given, blocks would only be 4X optimal. > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn
One of the comments made by the mining pools is that they won't run XT because it is "experimental".
Has there been any consideration to making available a version of XT with only the blocksize changes?
The least "experimental" version would be one that makes the absolute minimum changes to core.
The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes. This saves creating a new function.
Without the consensus measuring code, the patch would be even easier. Satoshi's proposal was just a block height comparison (a year in advance).
The state storing code is also another complication. If the standard "counting" upgrade system was used, then no state would need to be stored in the database.
On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla@riseup•net> wrote:
Quoted text (78 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (My replies below) > > On 06/26/2015 06:47 AM, Tier Nolan wrote: > > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace•org > > <mailto:adam@cypherspace.org>> wrote: > > > > The hard-cap serves the purpose of a safety limit in case our > > understanding about the economics, incentives or game-theory is > > wrong worst case. > > > > > > True. > > Yep. > > > > > BIP 100 and 101 could be combined. Would that increase consensus? > > Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100 > is a better alternative to Gavin's proposal(s), but that I didn't > think that this should be taken to mean that I am saying one thing is > "superior" to Gavin's work, rather, I emphasized that Gavin work with > Jeff and Adam. > > At least, at this stage the things are in a BIP process. > > If the BIP 100 and BIP 101 would be combined, what would that look > like on paper? > > > > > - Miner vote threshold reached - Wait notice period or until > > earliest start time - Block size default target set to 1 MB - Soft > > limit set to 1MB - Hard limit set to 8MB + double every 2 years - > > Miner vote to decide soft limit (lowest size ignoring bottom 20% > > but 1MB minimum) > > > > Block size updates could be aligned with the difficulty setting > > and based on the last 2016 blocks. > > > > Miners could leave the 1MB limit in place initially. The vote is > > to get the option to increase the block size. > > > > Legacy clients would remain in the network until >80% of miners > > vote to raise the limit and a miner produces a >1MB block. > > > > If the growth rate over-estimates hardware improvements, the devs > > could add a limit into the core client. If they give notice and > > enough users update, then miners would have to accept it. > > > > The block size becomes min(miner's vote, core devs). Even if 4 > > years notice is given, blocks would only be 4X optimal. > > > > > > _______________________________________________ bitcoin-dev mailing > > list bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > - -- > http://abis.io ~ > "a protocol concept to enable decentralization > and expansion of a giving economy, and a new social good" > https://keybase.io/odinn > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb > hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC > 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP > wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH > YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ > 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog= > =rtTH > -----END PGP SIGNATURE----- >
The "only bigblock" patch you want is actually available here : https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks
Le lun. 17 août 2015 à 15:16, Tier Nolan via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> a écrit :
Quoted text (106 lines)
> One of the comments made by the mining pools is that they won't run XT > because it is "experimental". > > Has there been any consideration to making available a version of XT with > only the blocksize changes? > > The least "experimental" version would be one that makes the absolute > minimum changes to core. > > The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip > changes. This saves creating a new function. > > Without the consensus measuring code, the patch would be even easier. > Satoshi's proposal was just a block height comparison (a year in advance). > > The state storing code is also another complication. If the standard > "counting" upgrade system was used, then no state would need to be stored > in the database. > > On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla@riseup•net> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> (My replies below) >> >> On 06/26/2015 06:47 AM, Tier Nolan wrote: >> > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace•org >> > <mailto:adam@cypherspace.org>> wrote: >> > >> > The hard-cap serves the purpose of a safety limit in case our >> > understanding about the economics, incentives or game-theory is >> > wrong worst case. >> > >> > >> > True. >> >> Yep. >> >> > >> > BIP 100 and 101 could be combined. Would that increase consensus? >> >> Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100 >> is a better alternative to Gavin's proposal(s), but that I didn't >> think that this should be taken to mean that I am saying one thing is >> "superior" to Gavin's work, rather, I emphasized that Gavin work with >> Jeff and Adam. >> >> At least, at this stage the things are in a BIP process. >> >> If the BIP 100 and BIP 101 would be combined, what would that look >> like on paper? >> >> > >> > - Miner vote threshold reached - Wait notice period or until >> > earliest start time - Block size default target set to 1 MB - Soft >> > limit set to 1MB - Hard limit set to 8MB + double every 2 years - >> > Miner vote to decide soft limit (lowest size ignoring bottom 20% >> > but 1MB minimum) >> > >> > Block size updates could be aligned with the difficulty setting >> > and based on the last 2016 blocks. >> > >> > Miners could leave the 1MB limit in place initially. The vote is >> > to get the option to increase the block size. >> > >> > Legacy clients would remain in the network until >80% of miners >> > vote to raise the limit and a miner produces a >1MB block. >> > >> > If the growth rate over-estimates hardware improvements, the devs >> > could add a limit into the core client. If they give notice and >> > enough users update, then miners would have to accept it. >> > >> > The block size becomes min(miner's vote, core devs). Even if 4 >> > years notice is given, blocks would only be 4X optimal. >> > >> > >> > _______________________________________________ bitcoin-dev mailing >> > list bitcoin-dev@lists•linuxfoundation•org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> >> - -- >> http://abis.io ~ >> "a protocol concept to enable decentralization >> and expansion of a giving economy, and a new social good" >> https://keybase.io/odinn >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb >> hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC >> 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP >> wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH >> YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ >> 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog= >> =rtTH >> -----END PGP SIGNATURE----- >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Mon, Jun 22, 2015 at 11:32 PM, Ross Nicoll <jrn@jrn•me•uk> wrote:
Quoted text (5 lines)
> Potentially daft question, why not use a minimum height? Yes, it's > imprecise, but over an extended period of time they're good enough IMHO. > > I'd have to do more careful calculations to confirm, but block 388,000 > should be about right as a minimum.
BIP99 (still a draft too) currently recommends a minimum height plus 95% mining upgrade confirmation (aka "miner voting") after that for uncontroversial hardforks:
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki#Uncontroversial_hardforks http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html
But general hardfork activation discussion is still inconclusive in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
The code for the example uncontroversial hardfork proposed in bip99 is at: https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11 But I haven't created a PR for either the code or the bip yet.
On Tue, Jun 23, 2015 at 9:35 AM, Ross Nicoll <jrn@jrn•me•uk> wrote:
Quoted text (3 lines)
> I don't think essentially replacing most of Testnet with a specialised test > chain is a good idea, but this might be a good time to consider a 4th test > network with very large blocks from genesis onwards.
You may be interested in this patch/PR:
https://github.com/bitcoin/bitcoin/pull/6382
Why only one more testchain when you can add std::numeric_limits<uint64_t>::max() new testchains with approximately the same code?
On Fri, Jun 26, 2015 at 3:47 PM, Tier Nolan <tier.nolan@gmail•com> wrote:
Quoted text (2 lines)
> - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB > minimum)
I don't think is all that interesting to make miners vote on lower limit. Say the community wants to reduce the size to limit mining centralization, it's not unthinkable that the hashrate majority (which may have to face more competition or harvest less transactions after the change) may oppose to that and then the community is forced to deploy an anti-miner's hardfork (maybe even asic-reset hardfork?) instead of a softfork. Yes, uncontroversial sofforks are easier and less risky to deploy than uncontroversial hardforks, but anti-miner hardforks are not. Not only I don't think it's a good idea for miners to vote on the block size (which is there to control them), I don't even buy the assumption that "we can always just softfork a smallwer size later". If you give something to miners they may not want to give it back later. We could hardfork to 42 M supply and then "just softfork back to 21 M", right? Or what's the same, we could "just softfork supply to 15 M". Such a change would be clearly controversial among miners, so it wouldn't be an uncontroversial softfork anymore. Some of these cases are discussed in BIP99.
Tier ~
I don't think the XT author(s) are going to do what you are describing. Their recent release, at https://github.com/bitcoinxt/bitcoinxt/blob/0.11A/README.md doesn't show any sign of moving toward a version which would be "increasing consensus." Instead, they ignore any meaningful process and, as I have recently indicated, have created somthing which "sidetrack(s) real discussion necessary to resolve the issues so as to achieve some level of consensus in block size debates."
That doesn't rule out that the BIP authors can't work together and create something meaningful and useful, though. As I stated before,
"In my past message(s), I've suggested that Jeff's BIP 100 is a better alternative to Gavin's proposal(s), but that I didn't think that this should be taken to mean that I am saying one thing is "superior" to Gavin's work, rather, I emphasized that Gavin work with Jeff and Adam."
I am also looking forward to seeing some visualizations or graphs of the miner votes going on right now on BIP 100 and BIP 101, for example.
Regarding XT, my statement is simple:
"Do not download this loathsome XT thing. Cast it back into the fires from whence it came."
- - Odinn
On 08/17/2015 06:15 AM, Tier Nolan via bitcoin-dev wrote:
Quoted text (93 lines)
> One of the comments made by the mining pools is that they won't run > XT because it is "experimental". > > Has there been any consideration to making available a version of > XT with only the blocksize changes? > > The least "experimental" version would be one that makes the > absolute minimum changes to core. > > The MAX_BLOCK_SIZE parameter could be overwritten whenever the > longest tip changes. This saves creating a new function. > > Without the consensus measuring code, the patch would be even > easier. Satoshi's proposal was just a block height comparison (a > year in advance). > > The state storing code is also another complication. If the > standard "counting" upgrade system was used, then no state would > need to be stored in the database. > > On Wed, Jul 1, 2015 at 11:49 PM, odinn > <odinn.cyberguerrilla@riseup•net > <mailto:odinn.cyberguerrilla@riseup.net>> wrote: > > (My replies below) > > On 06/26/2015 06:47 AM, Tier Nolan wrote: >> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace•org >> <mailto:adam@cypherspace.org> <mailto:adam@cypherspace.org >> <mailto:adam@cypherspace.org>>> wrote: > >> The hard-cap serves the purpose of a safety limit in case our >> understanding about the economics, incentives or game-theory is >> wrong worst case. > > >> True. > > Yep. > > >> BIP 100 and 101 could be combined. Would that increase >> consensus? > > Possibly ~ In my past message(s), I've suggested that Jeff's BIP > 100 is a better alternative to Gavin's proposal(s), but that I > didn't think that this should be taken to mean that I am saying one > thing is "superior" to Gavin's work, rather, I emphasized that > Gavin work with Jeff and Adam. > > At least, at this stage the things are in a BIP process. > > If the BIP 100 and BIP 101 would be combined, what would that look > like on paper? > > >> - Miner vote threshold reached - Wait notice period or until >> earliest start time - Block size default target set to 1 MB - >> Soft limit set to 1MB - Hard limit set to 8MB + double every 2 >> years - Miner vote to decide soft limit (lowest size ignoring >> bottom 20% but 1MB minimum) > >> Block size updates could be aligned with the difficulty setting >> and based on the last 2016 blocks. > >> Miners could leave the 1MB limit in place initially. The vote >> is to get the option to increase the block size. > >> Legacy clients would remain in the network until >80% of miners >> vote to raise the limit and a miner produces a >1MB block. > >> If the growth rate over-estimates hardware improvements, the >> devs could add a limit into the core client. If they give notice >> and enough users update, then miners would have to accept it. > >> The block size becomes min(miner's vote, core devs). Even if 4 >> years notice is given, blocks would only be 4X optimal. > > >> _______________________________________________ bitcoin-dev >> mailing list bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn