📅 Original date posted:2015-07-30
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> On 30 July 2015 at 16:12, Jorge Timón <
> bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/39d7af41/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 15:44:16
in reply to nevent1q…vj3w
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 15:44:16Event JSON
{
"id": "156ac1e9377b559f6b8b171f9a140c57afd433f1c782cec3a551e603933ba89a",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686152656,
"kind": 1,
"tags": [
[
"e",
"a5089d8cc94280b0825961adbe16d28b69a12ea3db4d49196026224a1cf60689",
"",
"root"
],
[
"e",
"5d5f09f5fd41f4012867910acd772473edac54a53073f90f16d70fd11bc14f84",
"",
"reply"
],
[
"p",
"c1498cc9db5c1dbd1963a224498f7c41ed8603e86e25c2af5a3bc910db5e43b3"
]
],
"content": "📅 Original date posted:2015-07-30\n📝 Original message:The median is used here because that is the consensus rule -- a block\ncannot have a timestamp older than the median time of the last 11 blocks.\nBy linking the changeover to this rule we avoid perverse incentives about\nminers lying in their timestamps, or the threshold being crossed, then\nreverted, then crossed again, etc.\n\nMaybe a different percentile would have been a better choice, but that ship\nsailed in 2009. The rule is what it is right now, and we benefit the most\nfrom using the same rule as consensus for the threshold.\nOn Jul 30, 2015 9:57 AM, \"Gary Mulder via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On 30 July 2015 at 16:12, Jorge Timón \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e 1) Unlike previous blocksize hardfork proposals, this uses median time\n\u003e\u003e instead of block.nTime for activation. I like that more but my\n\u003e\u003e preference is still using height for everything. But that discussion\n\u003e\u003e is not specific to this proposal, so it's better if we discuss that\n\u003e\u003e for all of them here:\n\u003e\u003e\n\u003e\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html\n\u003e\n\u003e\n\u003e Note that a \"median\" is a special case of a 50% percentile. If you desire\n\u003e to apply a more stringent criteria you can use the 75th or even 90th\n\u003e percentile.\n\u003e\n\u003e https://en.wikipedia.org/wiki/Percentile\n\u003e\n\u003e Perhaps if a statistician (i.e. not me) could be found to offer her\n\u003e services, she could become a resource for helping selecting the most\n\u003e appropriate statistical algorithms on request (and implemented Integer math\n\u003e as per Gavin, from memory), considering the consequences of learning\n\u003e post-fork that a \"bad statistical model\" was chosen.\n\u003e\n\u003e e.g. an exponentially weighted moving average is usually much less\n\u003e volatile and harder to manipulate than a simple moving average, but still\n\u003e can \"respond\" to short term drivers.\n\u003e\n\u003e Regards,\n\u003e Gary\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/39d7af41/attachment.html\u003e",
"sig": "7e2ef3e3f262abef4d6e505b4f5636afe2a1d7511e90191a20ca225c5b1a32a8c71e9c875f5bb3f338756219e9176a8ae2c7387cbb7fc3fb5eebfc45f0c1475a"
}