From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqNAd-0008Kn-PM for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 14:53:03 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.43 as permitted sender) client-ip=209.85.215.43; envelope-from=gavinandresen@gmail.com; helo=mail-la0-f43.google.com; Received: from mail-la0-f43.google.com ([209.85.215.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqNAb-0001ZG-Eq for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 14:53:03 +0000 Received: by laat2 with SMTP id t2so32521150laa.1 for ; Thu, 07 May 2015 07:52:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.205.69 with SMTP id le5mr3387649lbc.65.1431010375037; Thu, 07 May 2015 07:52:55 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Thu, 7 May 2015 07:52:54 -0700 (PDT) In-Reply-To: References: <554A91BE.6060105@bluematt.me> Date: Thu, 7 May 2015 10:52:54 -0400 Message-ID: From: Gavin Andresen To: Mike Hearn Content-Type: multipart/alternative; boundary=001a11c3c1be12fa1505157f1144 X-Spam-Score: -0.6 (/) 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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1YqNAb-0001ZG-Eq Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase 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: Thu, 07 May 2015 14:53:03 -0000 --001a11c3c1be12fa1505157f1144 Content-Type: text/plain; charset=UTF-8 For reference: the blog post that (re)-started this debate, and which links to individual issues, is here: http://gavinandresen.ninja/time-to-roll-out-bigger-blocks In it, I asked people to email me objections I might have missed. I would still appreciate it if people do that; it is impossible to keep up with this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and also have time to respond thoughtfully to the objections raised. I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs "THIS is how much transaction volume the main Bitcoin blockchain will be able to support over the next eleven years." I've been pretty clear on what I think is a reasonable compromise (a one-time increase scheduled for early next year), and I have tried to explain why I think it it is the right set of tradeoffs. There ARE tradeoffs here, and the hard question is what process do we use to decide those tradeoffs? How do we come to consensus? Is it worth my time to spend hours responding thoughtfully to every new objection raised here, or will the same thing happen that happened last year and the year before-- everybody eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and we're left with the status quo? I AM considering contributing some version of the bigger blocksize-limit hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a fast Internet connection, and assume Nelson's law to increase over time), and then encouraging merchants and exchanges and web wallets and individuals who think it strikes a reasonable balance to run it. And then, assuming it became a super-majority of nodes on the network, encourage miners to roll out a soft-fork to start producing bigger blocks and eventually trigger the hard fork. Because ultimately consensus comes down to what software people choose to run. -- -- Gavin Andresen --001a11c3c1be12fa1505157f1144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For reference: the blog post th= at (re)-started this debate, and which links to individual issues, is here:=
=C2=A0=C2=A0http://gavinandresen.ninja/time-to-= roll-out-bigger-blocks

In it, I asked people to email me objections I might h= ave missed. I would still appreciate it if people do that; it is impossible= to keep up with this mailing list, /r/bitcoin posts and comments, and #bit= coin-wizards and also have time to respond thoughtfully to the objections r= aised.

I would very much like to find some concrete course of action that we can = come to consensus on. Some compromise so we can tell entrepreneurs "TH= IS is how much transaction volume the main Bitcoin blockchain will be able = to support over the next eleven years."

I've been pretty cl= ear on what I think is a reasonable compromise (a one-time increase schedul= ed for early next year), and I have tried to explain why I think it it is t= he right set of tradeoffs.

There ARE tradeoffs here, and the hard question is wha= t process do we use to decide those tradeoffs?=C2=A0 How do we come to cons= ensus? Is it worth my time to spend hours responding thoughtfully to every = new objection raised here, or will the same thing happen that happened last= year and the year before-- everybody eventually gets tired of arguing ange= ls-dancing-on-the-head-of-a-pin, and we're left with the status quo?

I AM con= sidering contributing some version of the bigger blocksize-limit hard-fork = patch to the Bitcoin-Xt fork (probably =C2=A0"target a hobbyist with a= fast Internet connection, and assume Nelson's law to increase over tim= e), and then encouraging merchants and exchanges and web wallets and indivi= duals who think it strikes a reasonable balance to run it.

And then, assuming it= became a super-majority of nodes on the network, encourage miners to roll = out a soft-fork to start producing bigger blocks and eventually trigger the= hard fork.

Because ultimately consensus comes down to what software people choos= e to run.

--
--
Gavin Andresen

--001a11c3c1be12fa1505157f1144--