MIME-Version: 1.0
In-Reply-To: <CAG0bcYw=k_z82buUQ_kApmPgSenNy6FEsdXotLaS4Gn-kZbrKg@mail.gmail.com>
References: <CAG0bcYzzg4yeQvd27PZu5Fqv1ULS3cKeQHaRZ2zPcM3OASw1cg@mail.gmail.com>
	<CADJgMztJx1cBFhNOwMgBHJGPmBNPqsTdQbCCjFBmDBSBfTMMUg@mail.gmail.com>
	<CAAre=yRawFU_WMdE+ReemscYD33ez1PF6VhU2FmWo2fAEcw_Xw@mail.gmail.com>
	<CALqxMTERUFEFgJ4quz2dWLRw9fD3DkBp-6RO4cuvdBGV2MSyhw@mail.gmail.com>
	<CAG0bcYzBCsg9xNLGmu4S=PEPjtbd2iBLH52ryswbkRM23OqquA@mail.gmail.com>
	<CALqxMTFQhFusR5jkEMvRdxDVLZPzWSW5hUHpXoON-K-+xJjpNA@mail.gmail.com>
	<CAG0bcYw=k_z82buUQ_kApmPgSenNy6FEsdXotLaS4Gn-kZbrKg@mail.gmail.com>
Date: Tue, 8 Sep 2015 13:04:16 -0400
Message-ID: <CABsx9T1a5kbtw=SQrdXyp32LF7gA9LMShPMYEefP4arb6SQcHw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Washington Sanchez <washington.sanchez@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2280c325b92051f3f5b75
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft
	discussion
Precedence: list

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

>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
> consider it?
>

I'm not clear on what problem(s) you're trying to solve.

If you want blocks to be at least 60% full, then just specify a simple rule
like "maximum block size is 1.0/0.6 = 1.666 times the average block size
over the last N blocks (applied at every block or every 2016 blocks or
whatever, details don't really matter)".

If you want an upper limit on growth, then just implement a simple rule
like "Absolute maximum block size is 1 megabyte in 2016, 3.45 megabytes in
2017, and increases by a maximum of 3.45 times every year."

If you want me to take your proposal seriously, you need to justify why 60%
full is a good answer (and why we need a centralized decision on how full
blocks "should" be), and why 3.45 times-per-year is a good answer for
maximum growth (and, again, why we need a centralized decision on that).

-- 
--
Gavin Andresen

--001a11c2280c325b92051f3f5b75
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>3) Let me put it another w=
ay, I&#39;ve read that both Gavin and yourself are favorable to a dynamic l=
imit on the block size. In your view, what is missing from this proposal, o=
r what variables should be adjusted, to get the rules to a place where you =
and other Core developers would seriously consider it?</div></div></blockqu=
ote><div><br></div><div>I&#39;m not clear on what problem(s) you&#39;re try=
ing to solve.</div><div><br></div><div>If you want blocks to be at least 60=
% full, then just specify a simple rule like &quot;maximum block size is 1.=
0/0.6 =3D 1.666 times the average block size over the last N blocks (applie=
d at every block or every 2016 blocks or whatever, details don&#39;t really=
 matter)&quot;.</div><div><br></div><div>If you want an upper limit on grow=
th, then just implement a simple rule like &quot;Absolute maximum block siz=
e is 1 megabyte in 2016, 3.45 megabytes in 2017, and increases by a maximum=
 of 3.45 times every year.&quot;</div></div><div class=3D"gmail_extra"><br>=
</div>If you want me to take your proposal seriously, you need to justify w=
hy 60% full is a good answer (and why we need a centralized decision on how=
 full blocks &quot;should&quot; be), and why 3.45 times-per-year is a good =
answer for maximum growth (and, again, why we need a centralized decision o=
n that).<br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signatu=
re">--<br>Gavin Andresen<br></div>
</div></div>

--001a11c2280c325b92051f3f5b75--