[bitcoin-dev] BIP 102 - kick the can down the road to 2MB

Ross Nicoll jrn at jrn.me.uk
Sun Jul 19 22:51:07 UTC 2015

Further to that - please disregard what I said about using block height. 
Had failed to realise that in using contextual information (block 
height) it complicates block validation (i.e. it would be impossible to 
tell if a block is too big, without having all previous blocks first). 
Block time is in fact the better option.


On 17/07/2015 18:57, 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 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/20150719/f1ee52d6/attachment.html>

More information about the bitcoin-dev mailing list