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