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

[Peter Todd via bitcoin-dev]

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
0188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[gb via bitcoin-dev]

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

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

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

[Jorge Timón via bitcoin-dev]

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"  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  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"  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


>>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Chun Wang via bitcoin-dev]

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

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

[Peter Todd via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 18 December 2015 11:52:19 GMT-08:00, "Jorge Timón via bitcoin-dev" 
 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-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

On Dec 18, 2015 9:43 PM, "Peter Todd"  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev