Chris Wardell [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-17 📝 Original message:I would prefer a dynamic ...

📅 Original date posted:2015-07-17
📝 Original message: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 <
bitcoin-dev at lists.linuxfoundation.org> 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 listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150717/5e09fdb8/attachment.html>;