From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqNLn-000164-Q6 for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 15:04:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.50 as permitted sender) client-ip=74.125.82.50; envelope-from=morcos@gmail.com; helo=mail-wg0-f50.google.com; Received: from mail-wg0-f50.google.com ([74.125.82.50]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqNLj-0004Ll-Oc for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 15:04:35 +0000 Received: by wgyo15 with SMTP id o15so46576528wgy.2 for ; Thu, 07 May 2015 08:04:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.197 with SMTP id e5mr7458234wiw.94.1431011065687; Thu, 07 May 2015 08:04:25 -0700 (PDT) Received: by 10.180.168.34 with HTTP; Thu, 7 May 2015 08:04:25 -0700 (PDT) In-Reply-To: References: <554A91BE.6060105@bluematt.me> Date: Thu, 7 May 2015 11:04:25 -0400 Message-ID: From: Alex Morcos To: Gavin Andresen Content-Type: multipart/alternative; boundary=f46d043be0ee3d728005157f3a85 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 (morcos[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: 1YqNLj-0004Ll-Oc 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 15:04:35 -0000 --f46d043be0ee3d728005157f3a85 Content-Type: text/plain; charset=UTF-8 That strikes me as a dangerous path forward. I don't actually think there is anything wrong with this: "everybody eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and we're left with the status quo" What gives Bitcoin value aren't its technical merits but the fact that people believe in it. The biggest risk here isn't that 20MB blocks will be bad or that 1MB blocks will be bad, but that by forcing a hard fork that isn't nearly universally agreed upon, we will be damaging that belief. If I strongly believed some hard fork would be better for Bitcoin, say permanent inflation of 1% a year to fund mining, and I managed to convince 80% of users, miners, businesses and developers to go along with me, I would still vote against doing it. Because that's not nearly universal agreement, and it changes what people chose to believe in without their consent. Forks should be hard, very hard. And both sides should recognize that belief in the value of Bitcoin might be a fragile thing. I'd argue that if we didn't force through a 20MB fork now, and we ran into major network difficulties a year from now and had no other technical solutions, that maybe we would get nearly universal agreement, and the businesses and users that were driven away by the unusable system would be a short term loss in value considerably smaller than the impairment we risk by forcing a change. On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen wrote: > 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 > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --f46d043be0ee3d728005157f3a85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That strikes me as a dangerous path forward.

I don't actually think there is anything wrong with this: "<= span style=3D"font-size:12.8000001907349px">everybody eventually gets tired= of arguing angels-dancing-on-the-head-of-a-pin, and we're left with the status quo"

=
What gives Bitcoin value = aren't its technical merits but the fact that people believe in it. =C2= =A0 The biggest risk here isn't that 20MB blocks will be bad or that 1M= B blocks will be bad, but that by forcing a hard fork that isn't nearly= universally agreed upon, we will be damaging that belief. =C2=A0 If I stro= ngly believed some hard fork would be better for Bitcoin, say permanent inf= lation of 1% a year to fund mining, and I managed to convince 80% of users,= miners, businesses and developers to go along with me, I would still vote = against doing it.=C2=A0 Because that's not nearly universal agreement, = and it changes what people chose to believe in without their consent. Forks= should be hard, very hard.=C2=A0 And both sides should recognize that beli= ef in the value of Bitcoin might be a fragile thing. =C2=A0 I'd argue t= hat if we didn't force through a 20MB fork now, and we ran into major n= etwork difficulties a year from now and had no other technical solutions, t= hat maybe we would get nearly universal agreement, and the businesses and u= sers that were driven away by the unusable system would be a short term los= s in value considerably smaller than the impairment we risk by forcing a ch= ange.



On Thu, M= ay 7, 2015 at 10:52 AM, Gavin Andresen <gavinandresen@gmail.com&= gt; wrote:
For reference: the blog post that (re)-started this de= bate, 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 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 raise= d.

I w= ould 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 i= s how much transaction volume the main Bitcoin blockchain will be able to s= upport over the next eleven years."

I've been pretty clear = on what I think is a reasonable compromise (a one-time increase scheduled f= or early next year), and I have tried to explain why I think it it is the r= ight set of tradeoffs.

There ARE tradeoffs here, and the hard question is what pr= ocess do we use to decide those tradeoffs?=C2=A0 How do we come to consensu= s? 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 yea= r and the year before-- everybody eventually gets tired of arguing angels-d= ancing-on-the-head-of-a-pin, and we're left with the status quo?
<= div class=3D"gmail_extra">
I AM conside= ring contributing some version of the bigger blocksize-limit hard-fork patc= h to the Bitcoin-Xt fork (probably =C2=A0"target a hobbyist with a fas= t Internet connection, and assume Nelson's law to increase over time), = and then encouraging merchants and exchanges and web wallets and individual= s who think it strikes a reasonable balance to run it.

And then, assuming it beca= me 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

=

-----------------------------------------------------------------------= -------
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
= _______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--f46d043be0ee3d728005157f3a85--