Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YzRin-0004Ug-Bk for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 15:33:49 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.170 as permitted sender) client-ip=209.85.212.170; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f170.google.com; Received: from mail-wi0-f170.google.com ([209.85.212.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YzRim-00071I-AI for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 15:33:49 +0000 Received: by wicmx19 with SMTP id mx19so74747061wic.0 for ; Mon, 01 Jun 2015 08:33:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.157.168 with SMTP id wn8mr41359456wjb.79.1433172822312; Mon, 01 Jun 2015 08:33:42 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.143.9 with HTTP; Mon, 1 Jun 2015 08:33:41 -0700 (PDT) In-Reply-To: References: <554BE0E1.5030001@bluematt.me> Date: Mon, 1 Jun 2015 17:33:41 +0200 X-Google-Sender-Auth: zbR6ZOy4lHiBmFzagG9kNqTNRsw Message-ID: From: Mike Hearn To: Chun Wang <1240902@gmail.com> Content-Type: multipart/alternative; boundary=089e0122e968f9ce9b0517768c4a 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: 1YzRim-00071I-AI Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements 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: Mon, 01 Jun 2015 15:33:49 -0000 --089e0122e968f9ce9b0517768c4a Content-Type: text/plain; charset=UTF-8 I'm OK with a smaller size + a formula that ramps it up over time. We are far from having enough demand to fill 10MB blocks, let alone 20MB today. To put it in perspective, to be feeling squeezed inside 10MB within two years, we would need to double usage five times. I wish I knew a way to make that happen. So the chances of us going to 20MB blocks full of real transactions any time soon is close to zero short of some amazing killer app that takes the world by storm (in which case: yay, nice problem to have). As long as capacity significantly outpaces organic growth, we should avoid problems. The reason to pick 20MB then is merely one of expedience: we have to pick a number, 20 is tested and seems to work, and we don't want to get caught by surprise if demand does outstrip expectations. Still, I question the underlying logic. We have no idea what connectivity into China will look like a few years from now: it's seems to be a function of politics rather than hardware trends. It might go down rather than up. So 10 vs 20 feels a bit arbitrary. We can't let the Chinese government dictate how Bitcoin is used, that would never be accepted by the rest of the world. But if we optimistically assume things don't get worse, and 10 == more acceptance, then alright - it should make no difference in practice. --089e0122e968f9ce9b0517768c4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm OK with a smaller size + a formula that ramps it u= p over time. We are far=C2=A0from having enough demand to fill 10MB blocks,= let alone 20MB today.

To put it in perspective, to be f= eeling squeezed inside 10MB within two years, we would need to double usage= five times. I wish I knew a way to make that happen. So the chances of us = going to 20MB blocks full of real transactions any time soon is close to ze= ro short of some amazing killer app that takes the world by storm (in which= case: yay, nice problem to have). As long as capacity significantly outpac= es organic growth, we should avoid problems.

The r= eason to pick 20MB then is merely one of expedience: we have to pick a numb= er, 20 is tested and seems to work, and we don't want to get caught by = surprise if demand does outstrip expectations.

Still, I question the underlying logic. We have no idea what connect= ivity into China will look like a few years from now: it's seems to be = a function of politics rather than hardware trends. It might go down rather= than up. So 10 vs 20 feels a bit arbitrary. We can't let the Chinese g= overnment dictate how Bitcoin is used, that would never be accepted by the = rest of the world. But if we optimistically assume things don't get wor= se, and 10 =3D=3D more acceptance, then alright - it should make no differe= nce in practice.

--089e0122e968f9ce9b0517768c4a--