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
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
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
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).
-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
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