Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

From: "Jorge Timón" <jtimon@jtimon.cc>
To: Chun Wang <1240902@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time
Date: Fri, 18 Dec 2015 20:52:19 +0100	[thread overview]
Message-ID: <CABm2gDqJgPM1KRRSR3wSEhQ77Oq6P_VVvHwc3Yt4qnkAr7d2nA@mail.gmail.com> (raw)
In-Reply-To: <CAFzgq-xNZmWrdwCDv3twdsqSWk-FyMuLYJjZ_bA42_5Po0mgEg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

I agree that nHeight is the simplest option and is my preference.
Another option is to use the median time from the previous block (thus you
know whether or not the next block should start the miner confirmation or
not). In fact, if we're going to use bip9  for 95% miner upgrade
confirmation, it would be nice to always pick a difficulty retarget block
(ie block.nHeight % DifficultyAdjustmentInterval == 0).
Actually I would always have an initial height in bip9, for softforks too.
I would also use the sign bit as the "hardfork bit" that gets activated for
the next diff interval after 95% is reached and a hardfork becomes active
(that way even SPV nodes will notice when a softfork  or hardfork happens
and also be able to tell which one is it).
I should update bip99 with all this. And if the 2 mb bump is
uncontroversial, maybe I can add that to the timewarp fix and th recovery
of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
follow bip99's recommendations and doesn't want to give 6 full months as
the pre activation grace period).
On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> In many BIPs we have seen, include the latest BIP202, it is the block
> time that determine the max block size. From from pool's point of
> view, it cannot issue a job with a fixed ntime due to the existence of
> ntime roll. It is hard to issue a job with the max block size unknown.
> For developers, it is also easier to implement if max block size is a
> function of block height instead of time. Block height is also much
> more simple and elegant than time.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2331 bytes --]