From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A29AA415 for ; Thu, 30 Jul 2015 17:13:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05236253 for ; Thu, 30 Jul 2015 17:13:13 +0000 (UTC) Received: by iodd187 with SMTP id d187so60269427iod.2 for ; Thu, 30 Jul 2015 10:13:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TkspycX4j7UsBjoR46sd8Ai2cii2WH/7DoUR8oKUOBY=; b=L2PF8Dj06xy81ajlWpgv6gL1pkcgTcXTjkUU+02S4UoIDhsBNwjQioeYX/eNGu+eGY j/Vt0kYBNy2NPCVerxAkO55iLVmQe9kneXbHvjfkme5SWoKzEtRmmEydyG3R1FhLsJ+d UXE6rZ1QKpZ+5JioGZiQOUPFYFmq5h46MKaN3FB7kQJhKvkgvggboAdRAhOIMukKkMVR JctXqodxHqYPyTIMq440FyokBOajBBKCWH8rnE0ymrwWfyqfAa7qnbP7AE8d0odZeNbO Vf6vctFyUjcqwWKa6IcOnfT7BTVZqQMUCrJwtMifVmBDLgw3bgQmARIGMyI95j+P4C03 rvww== X-Gm-Message-State: ALoCoQkd8oTJXdBVId02RY7N6GMLs70N0naaadPNcWHSZsprkNbmItQHtEaq2aTIeFJurhE6eCAF MIME-Version: 1.0 X-Received: by 10.107.130.166 with SMTP id m38mr13569421ioi.77.1438276393442; Thu, 30 Jul 2015 10:13:13 -0700 (PDT) Received: by 10.107.158.140 with HTTP; Thu, 30 Jul 2015 10:13:13 -0700 (PDT) X-Originating-IP: [172.56.17.151] Received: by 10.107.158.140 with HTTP; Thu, 30 Jul 2015 10:13:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jul 2015 10:13:13 -0700 Message-ID: From: Mark Friedenbach To: Gary Mulder Content-Type: multipart/alternative; boundary=001a113eb9c88552a1051c1ad18e X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Block size following technological growth X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 17:13:15 -0000 --001a113eb9c88552a1051c1ad18e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=B3n < > 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 ma= th > 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 > > --001a113eb9c88552a1051c1ad18e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 incentive= s about miners lying in their timestamps, or the threshold being crossed, t= hen 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 be= nefit the most from using the same rule as consensus for the threshold.

On Jul 30, 2015 9:57 AM, "Gary Mulder via b= itcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
On 30 July 2015 at 16:12,= Jorge Tim=C3=B3n=C2=A0<bitcoin-dev@lists.linuxfoundation.org>=C2=A0wrote:
1) U= nlike previous blocksize hardfork proposals, this uses median time
inste= ad of block.nTime for activation. I like that more but my
preference is = still using height for everything. But that discussion
is not specific t= o this proposal, so it's better if we discuss that
for all of them h= ere:
http://lists.lin= uxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

Note that a "median" is a special case o= f a 50% percentile. If you desire to apply a more stringent criteria you ca= n use the 75th or even 90th percentile.


Perhaps i= f a statistician (i.e. not me) could be found to offer her services, she co= uld become a resource for helping selecting the most appropriate statistica= l algorithms on request (and implemented Integer math as per Gavin, from me= mory), considering the consequences of learning post-fork that a "bad = statistical model" was chosen.

e.g. an exp= onentially weighted moving average is usually much less volatile and harder= to manipulate than a simple moving average, but still can "respond&qu= ot; to short term drivers.=C2=A0

Regards,
=
Gary

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a113eb9c88552a1051c1ad18e--