Ross Nicoll [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-17 📝 Original message:I'll leave others to ...
📅 Original date posted:2015-07-17
📝 Original message: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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto: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 list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://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/201c99fb/attachment-0001.html>;
📝 Original message: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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto: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 list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://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/201c99fb/attachment-0001.html>;