Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.175 as permitted sender)
	client-ip=209.85.212.175; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f175.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
	<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
	<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
	<CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
	<CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
Date: Fri, 29 May 2015 13:26:40 +0200
Message-ID: <CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043bdabc0bc855051736c01b
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
Precedence: list

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

>
> By the time a hard fork can happen, I expect average block size will be
> above 500K.
>

Yes, possibly.


> Would you support a rule that was "larger of 1MB or 2x average size" ?
> That is strictly better than the situation we're in today.
>

It is, but only by a trivial amount - hitting the limit is still very
likely. I don't want to see this issue come up over and over again. Ideally
never. We shouldn't be artificially throttling organic growth of the
network, especially not by accident.

IMO it's not even clear there needs to be a size limit at all. Currently
the 32mb message cap imposes one anyway, but if miners can always just
discourage blocks over some particular size if they want to.

But I can get behind a 20mb limit (or 20mb+N) as it represents a reasonable
compromise: the limit still exists, it's far below VISA capacity etc, but
it should also free up enough space that everyone can get back to what we
*should* be focusing on, which is user growth!

--f46d043bdabc0bc855051736c01b
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 class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><div>By the time a hard fork can happen, I expect av=
erage block size will be above 500K.</div></div></div></div></blockquote><d=
iv><br></div><div>Yes, possibly.</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><div>Would you support a rule that was &quot;larger of 1MB or 2x ave=
rage size&quot; ? That is strictly better than the situation we&#39;re in t=
oday.</div></div></div></div></blockquote><div><br></div><div>It is, but on=
ly by a trivial amount - hitting the limit is still very likely. I don&#39;=
t want to see this issue come up over and over again. Ideally never. We sho=
uldn&#39;t be artificially throttling organic growth of the network, especi=
ally not by accident.<br></div><div><br></div><div>IMO it&#39;s not even cl=
ear there needs to be a size limit at all. Currently the 32mb message cap i=
mposes one anyway, but if miners can always just discourage blocks over som=
e particular size if they want to.</div><div><br></div><div>But I can get b=
ehind a 20mb limit (or 20mb+N) as it represents a reasonable compromise: th=
e limit still exists, it&#39;s far below VISA capacity etc, but it should a=
lso free up enough space that everyone can get back to what we <i>should</i=
>=C2=A0be focusing on, which is user growth!</div></div></div></div>

--f46d043bdabc0bc855051736c01b--