From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YyIR7-0008RP-5X for bitcoin-development@lists.sourceforge.net; Fri, 29 May 2015 11:26:49 +0000 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; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YyIR5-0005eD-9l for bitcoin-development@lists.sourceforge.net; Fri, 29 May 2015 11:26:49 +0000 Received: by wivl4 with SMTP id l4so14212441wiv.1 for ; Fri, 29 May 2015 04:26:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.96.196 with SMTP id du4mr5424348wib.77.1432898801222; Fri, 29 May 2015 04:26:41 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.143.9 with HTTP; Fri, 29 May 2015 04:26:40 -0700 (PDT) In-Reply-To: References: <16096345.A1MpJQQkRW@crushinator> Date: Fri, 29 May 2015 13:26:40 +0200 X-Google-Sender-Auth: CPPlem1qIdspgyVDhE2WUZguMIs Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=f46d043bdabc0bc855051736c01b X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YyIR5-0005eD-9l Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 11:26:49 -0000 --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
By the time a hard fork can happen, I expect av= erage block size will be above 500K.

Yes, possibly.
=C2=A0
Would you support a rule that was "larger of 1MB or 2x ave= rage size" ? That is strictly better than the situation we're in t= oday.

It is, but on= ly 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 sho= uldn't be artificially throttling organic growth of the network, especi= ally not by accident.

IMO it'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.

But I can get b= ehind a 20mb limit (or 20mb+N) as it represents a reasonable compromise: th= e limit still exists, it's far below VISA capacity etc, but it should a= lso free up enough space that everyone can get back to what we should=C2=A0be focusing on, which is user growth!
--f46d043bdabc0bc855051736c01b--