<unnamed>

Public Key

npub1c9ycejwmtswm6xtr5gjynrmug8kcvqlgdcju9t6680y3pk67gwesp06mf3

Profile Code

nprofile1qqsvzjvve8d4c8dar936yfzf3a7yrmvxq05xufwz4adrhjgsmd0y8vcpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqarem39

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:44:16 UTC

- reply

📅 Original date posted:2015-07-30
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/b6d539f7/attachment.html>