MIME-Version: 1.0
In-Reply-To: <CABerxhEwA7Pz0hdSuOf+RwWZiZpY1fSArB+UiyVUwr6S2fr3vQ@mail.gmail.com>
References: <CABerxhEwA7Pz0hdSuOf+RwWZiZpY1fSArB+UiyVUwr6S2fr3vQ@mail.gmail.com>
Date: Mon, 17 Aug 2015 13:43:46 +0100
Message-ID: <CAE-z3OVgQuFsXNEe0ccXXS=pzxhHzZNJiuFJ3tc=5QD=D4oDSg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a114661980d6033051d812788
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Precedence: list

--001a114661980d6033051d812788
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I haven't run any statistics or simulations, but I'm concerned that the
> interplay between the random distribution of transaction arrival and the
> random distribution of block times may lead to false signals.
>

You could just take the average of all the block sizes for the last 2016
window.

If average of last 2016 > 50% of the limit, then increase by 6.25%
Otherwise, decrease by 6.25%

This means that the average would be around 50% of the limit.  This gives
margin to create larger blocks when blocks are happening slowly.

A majority of miners could force the limit upwards by creating spam but
full blocks.

It could be coupled with a hard limit that grows at whatever is seen as the
maximum reasonable.  This would be both a maximum and a minimum.

All of these schemes add state to the system.  If the schedule is
predictable, then you can check determine the maximum block size purely
from the header and coinbase.

--001a114661980d6033051d812788
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev <span dir=3D"lt=
r">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div>I haven&#39;t run any statistics or simulations,=
 but I&#39;m concerned that the interplay between the random distribution o=
f transaction arrival and the random distribution of block times may lead t=
o false signals.</div></div></div></div></blockquote><div><br></div><div>Yo=
u could just take the average of all the block sizes for the last 2016 wind=
ow.<br><br></div><div>If average of last 2016 &gt; 50% of the limit, then i=
ncrease by 6.25%<br></div><div>Otherwise, decrease by 6.25%<br><br></div><d=
iv>This means that the average would be around 50% of the limit.=C2=A0 This=
 gives margin to create larger blocks when blocks are happening slowly.<br>=
<br></div><div>A majority of miners could force the limit upwards by creati=
ng spam but full blocks.<br></div><div><br></div>It could be coupled with a=
 hard limit that grows at whatever is seen as the maximum reasonable.=C2=A0=
 This would be both a maximum and a minimum.<br><br></div><div class=3D"gma=
il_quote">All of these schemes add state to the system.=C2=A0 If the schedu=
le is predictable, then you can check determine the maximum block size pure=
ly from the header and coinbase.<br></div></div></div>

--001a114661980d6033051d812788--