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

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

[Chun Wang]

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.

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

[Jorge Timón]

[-- 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 --]

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

[Jeff Garzik]

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

From a code standpoint, based off height is easy.

My first internal version triggered on block 406,800 (~May 5), and each
block increased by 20 bytes thereafter.

It was changed to time, because time was the standard used in years past
for other changes; MTP flag day is more stable than block height.

It is preferred to have a single flag trigger (height or time), rather than
the more complex trigger-on-time, increment-on-height, but any combination
of those will work.

Easy to change code back to height-based...



On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

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

[Jorge Timón]

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

Well, if it's not going to be height, I think median time of the previous
block is better than the time of the current one, and would also solve Chun
Wang's concerns.
But as said I prefer to use heights that correspond to diff recalculation
(because that's the window that bip9 will use for the later 95%
confirmation anyway).
On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote:

> From a code standpoint, based off height is easy.
>
> My first internal version triggered on block 406,800 (~May 5), and each
> block increased by 20 bytes thereafter.
>
> It was changed to time, because time was the standard used in years past
> for other changes; MTP flag day is more stable than block height.
>
> It is preferred to have a single flag trigger (height or time), rather
> than the more complex trigger-on-time, increment-on-height, but any
> combination of those will work.
>
> Easy to change code back to height-based...
>
>
>
> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

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

[Jeff Garzik]

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

My preference is height activation + one step per block (i.e. also
height).  Height seems KISS.

AFAICT most of the attacks would occur around the already-heavily-watched
flag day activation event, in a height based environment, a useful
attribute.

However I would like to hear from others about possible attacks with the
various approaches, before diverging from the default community approach of
switch-based-on-time.






On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón <jtimon@jtimon.cc> wrote:

> Well, if it's not going to be height, I think median time of the previous
> block is better than the time of the current one, and would also solve Chun
> Wang's concerns.
> But as said I prefer to use heights that correspond to diff recalculation
> (because that's the window that bip9 will use for the later 95%
> confirmation anyway).
> On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote:
>
>> From a code standpoint, based off height is easy.
>>
>> My first internal version triggered on block 406,800 (~May 5), and each
>> block increased by 20 bytes thereafter.
>>
>> It was changed to time, because time was the standard used in years past
>> for other changes; MTP flag day is more stable than block height.
>>
>> It is preferred to have a single flag trigger (height or time), rather
>> than the more complex trigger-on-time, increment-on-height, but any
>> combination of those will work.
>>
>> Easy to change code back to height-based...
>>
>>
>>
>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>

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

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

[Jorge Timón]

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

I believe the attacks are the same for height or median time of the prev
block are equal, only the time of the current block has more edge cases.
On Dec 18, 2015 9:15 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote:

> My preference is height activation + one step per block (i.e. also
> height).  Height seems KISS.
>
> AFAICT most of the attacks would occur around the already-heavily-watched
> flag day activation event, in a height based environment, a useful
> attribute.
>
> However I would like to hear from others about possible attacks with the
> various approaches, before diverging from the default community approach of
> switch-based-on-time.
>
>
>
>
>
>
> On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
>
>> Well, if it's not going to be height, I think median time of the previous
>> block is better than the time of the current one, and would also solve Chun
>> Wang's concerns.
>> But as said I prefer to use heights that correspond to diff recalculation
>> (because that's the window that bip9 will use for the later 95%
>> confirmation anyway).
>> On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote:
>>
>>> From a code standpoint, based off height is easy.
>>>
>>> My first internal version triggered on block 406,800 (~May 5), and each
>>> block increased by 20 bytes thereafter.
>>>
>>> It was changed to time, because time was the standard used in years past
>>> for other changes; MTP flag day is more stable than block height.
>>>
>>> It is preferred to have a single flag trigger (height or time), rather
>>> than the more complex trigger-on-time, increment-on-height, but any
>>> combination of those will work.
>>>
>>> Easy to change code back to height-based...
>>>
>>>
>>>
>>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>

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

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

[gb]

On Fri, 2015-12-18 at 15:15 -0500, Jeff Garzik via bitcoin-dev wrote:
> My preference is height activation + one step per block (i.e. also
> height).  Height seems KISS.
> 
> 
Under this scheme the size of the step-per-block increase could be
decreased every 210,000 blocks (at time of reward halvings). 

So, a linear growth rate that decreases every ~4 years, ultimately
grandfathering max_block_size increases on the same block-schedule that
reward decreases.

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

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 18 December 2015 11:52:19 GMT-08:00, "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>I agree that nHeight is the simplest option and is my preference.
>Another option is to use the median time from the previous block


FWIW all these median time based schemes should be using median time past: the point is to use a time that the block creator has no direct control of, while still tying the rule to wall clock time for planning purposes.
-----BEGIN PGP SIGNATURE-----

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWdG/r
AAoJEMCF8hzn9Lncz4MH/iYJv6aB9rvfvy1KuSSHAQDQ++6j7Flmk2n8f/S4jt4q
92MZnKDw09HxUJiWvwREi81wHpq4JedgK1Z/+8m3wlK+jaIyWZ7Su+Jm+EqsoOSJ
Sx6oisbyFlhVEUAdaG/XOX/K0mqh01NSvGGpoQjHAYzcG3pI03OC4G7Qg4WGeZLx
O0yb387DmK/of52JGJcei3TUx0w8Up/GdXDqerLxioH7fhGhtGCj0vyD4LugnNLQ
hka5g+hri27YltfaRxncNQ0nZT4rAfgRgRH1Qi3kHnc6ZgRcRjjb36TyrWjZ34eb
9+YDAirFwu8HGmi7lfxh9DDtVjPZCwKal7/rNeRI744=
=7f+W
-----END PGP SIGNATURE-----

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

[Jorge Timón]

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

On Dec 18, 2015 9:43 PM, "Peter Todd" <pete@petertodd.org> wrote:
> FWIW all these median time based schemes should be using median time
past: the point is to use a time that the block creator has no direct
control of, while still tying the rule to wall clock time for planning
purposes.

Well, if after the "planned clock time" you need to wait for the next diff
retarget and then wait for 95% (bip9) I think the value of being able to
use "human friendly clock time" is very dubious (specially since median
time is different from real-world time anyway).
But yeah, not giving the creator of the current block direct control over
whether its block starts the activation process or not is achieved with
median time of the previous block just as well as nHeight does.
So even if I disagree with the value that median time brings over the
simpler height approach, let's please decide on one and always use that for
both hardforks and softforks as part of bip9 (which we would need to
modify).
An initial time threshold is not necessary for uncontroversial softforks,
but it doesn't hurt (you can always set it in the past if you want to not
use it) and in fact it simplifies bip9's implementation.
Let's please decide once and for all, update bip9 and bip99 and stop doing
something different on every hardfork patch we write.

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

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

[Peter Todd]

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

On Sat, Dec 19, 2015 at 03:17:03AM +0800, Chun Wang via bitcoin-dev 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.

If size is calculated from the median time past, which is fixed for a
given block and has no dependency on the block header's nTime field,
does that solve your problem?

By "median time past" I mean the median time for the previous block.

-- 
'peter'[:-1]@petertodd.org
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]