I'll leave others to comment on whether we can get consensus on that, but your years listed are inconsistent with everything else you've written. Should be: block 400,000 = 2MB (2016) block 500,000 = 4MB (2018) block 600,000 = 8MB (2020) On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote: > I would prefer a dynamic solution that did not necessitate a second > hard fork down the road. > > I propose doubling the block size every 100k blocks (~2 years) > > block 400,000 = 2MB (2016) > block 500,000 = 4MB (2017) > block 600,000 = 8MB (2018) > > Chris > > > On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev > > wrote: > > I'd back this if we can't find a permanent solution - 2MB gives us > a lot more wiggle room in the interim at least; one of my concerns > with block size is 3 transactions per second is absolutely tiny, > and we need space for the network to search for an equilibrium > between volume and pricing without risk of an adoption spike > rendering it essentially unusable. > > I'd favour switching over by block height rather than time, and > I'd suggest that given virtually every wallet/node out there will > require testing (even if many do not currently enforce a limit and > therefore do not need changing), 6 months should be considered a > minimum target. I'd open with a suggestion of block 390k as a target. > > Ross > > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: >> Opening a mailing list thread on this BIP: >> >> BIP PR: https://github.com/bitcoin/bips/pull/173 >> Code PR: https://github.com/bitcoin/bitcoin/pull/6451 >> >> The general intent of this BIP is as a minimum viable alternative >> plan to my preferred proposal (BIP 100). >> >> If agreement is not reached on a more comprehensive solution, >> then this solution is at least available and a known quantity. A >> good backup plan. >> >> Benefits: conservative increase. proves network can upgrade. >> permits some added growth, while the community & market gathers >> data on how an increased block size impacts privacy, security, >> centralization, transaction throughput and other metrics. 2MB >> seems to be a Least Common Denominator on an increase. >> >> Costs: requires a hard fork. requires another hard fork down >> the road. >> >> >> >> >> _______________________________________________ >> 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