Not so much that the implementation is difficult, as it requires context
to validate a block size, rather than being able to validate it without
requiring the preceeding blocks. Yes, time on different machines may
vary, but block time is safe to use for this, because it's a
straight-forward test of "if block time is acceptable and block time is
after <date> then maximum block size allowed is n MB otherwise m MB".
Ross
On 21/07/2015 10:26, Jorge Timón wrote:
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
