I still disagree. Using height instead of time may make the implementation more complex by requiring some additional preparations but using height is in fact a simpler design. Why relay on clocks that we know will differ in different computers and places when we have a universal tick with every block?
Btw, BIP16 and BIP34 could be changed to height-based activation already. BIP16 simply should have used height instead of time from the beginning. On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > 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. > > Ross > > > 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@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
