MIME-Version: 1.0
In-Reply-To: <55AC29DB.4060800@jrn.me.uk>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
	<55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk>
Date: Tue, 21 Jul 2015 11:26:35 +0200
Message-ID: <CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Ross Nicoll <jrn@jrn.me.uk>
Content-Type: text/plain; charset=UTF-8
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Precedence: list

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
>