Re: [bitcoin-dev] Block size following technological growth

From: Mark Friedenbach <mark@friedenbach•org>
To: Gary Mulder <flyingkiwiguy@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Thu, 30 Jul 2015 10:13:13 -0700	[thread overview]
Message-ID: <CAOG=w-v7sudzc91P32pw7VG=OMNigaj9-dbLLYz_2NYZheW4cQ@mail.gmail.com> (raw)
In-Reply-To: <CAKy9zTA1j6311Y8uo-c_z2JQr8gEwf_gH+HH56rRgZac9fqh9Q@mail.gmail.com>

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

The median is used here because that is the consensus rule -- a block
cannot have a timestamp older than the median time of the last 11 blocks.
By linking the changeover to this rule we avoid perverse incentives about
miners lying in their timestamps, or the threshold being crossed, then
reverted, then crossed again, etc.

Maybe a different percentile would have been a better choice, but that ship
sailed in 2009. The rule is what it is right now, and we benefit the most
from using the same rule as consensus for the threshold.
On Jul 30, 2015 9:57 AM, "Gary Mulder via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On 30 July 2015 at 16:12, Jorge Timón <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 1) Unlike previous blocksize hardfork proposals, this uses median time
>> instead of block.nTime for activation. I like that more but my
>> preference is still using height for everything. But that discussion
>> is not specific to this proposal, so it's better if we discuss that
>> for all of them here:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
>
>
> Note that a "median" is a special case of a 50% percentile. If you desire
> to apply a more stringent criteria you can use the 75th or even 90th
> percentile.
>
> https://en.wikipedia.org/wiki/Percentile
>
> Perhaps if a statistician (i.e. not me) could be found to offer her
> services, she could become a resource for helping selecting the most
> appropriate statistical algorithms on request (and implemented Integer math
> as per Gavin, from memory), considering the consequences of learning
> post-fork that a "bad statistical model" was chosen.
>
> e.g. an exponentially weighted moving average is usually much less
> volatile and harder to manipulate than a simple moving average, but still
> can "respond" to short term drivers.
>
> Regards,
> Gary
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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