Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <jgarzik@bitpay.com>) id 1YqNQo-0001QI-OV for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 15:09:46 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.214.177 as permitted sender) client-ip=209.85.214.177; envelope-from=jgarzik@bitpay.com; helo=mail-ob0-f177.google.com; Received: from mail-ob0-f177.google.com ([209.85.214.177]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqNQm-0004sq-9D for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 15:09:46 +0000 Received: by obfe9 with SMTP id e9so33659377obf.1 for <bitcoin-development@lists.sourceforge.net>; Thu, 07 May 2015 08:09:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FpIQmLBozQhDqTZkHT2kdgRhlq2lueqXNm8cthiRhR0=; b=RoBNvR51k6LZlmejWyTJueCbkpUNycbPb6anGoufWbNrou1YiDzXzRSbb0lD9+iDf1 /GsioIarDqE80wChXsYIFlCfvypJbjjHzFPBal1bUJdngOG0km+gNYlsPeYcyXQ1PCtG 2hueu68JvkfAYySwdTBhouALXbU7HXEQx51Lrtpj2p1zMGVRHFtGFI3NKPHpKrNU5q+m ZxVFx5WEOftkhCNoLP1CJe1MVIjRlTfDARsLlbbuxpjM7om9IzcSH2J7AofuH0m5iKE6 aXMAKwzXI2lfJKlOJjbpfIQhJayihYrQt3XpS8Jhq4+nMxo73FPeKqxPI8BcK74ymwYO bakQ== X-Gm-Message-State: ALoCoQnmzEM9hY7ORtaOx6sqzWvOoOLGkRMUbmqgcQ7+yi+joog9R0qK3Ov8T8FXLq69OE+klEvH X-Received: by 10.60.92.131 with SMTP id cm3mr3552151oeb.23.1431011378881; Thu, 07 May 2015 08:09:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.108.149 with HTTP; Thu, 7 May 2015 08:09:18 -0700 (PDT) In-Reply-To: <CAPWm=eUFe7dKJCLeNACZ4n9vw0Xj9rHVM_RRLSczGXNU-ShR2w@mail.gmail.com> References: <554A91BE.6060105@bluematt.me> <CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com> <CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com> <CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com> <CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com> <CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com> <CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com> <CAPWm=eUFe7dKJCLeNACZ4n9vw0Xj9rHVM_RRLSczGXNU-ShR2w@mail.gmail.com> From: Jeff Garzik <jgarzik@bitpay.com> Date: Thu, 7 May 2015 11:09:18 -0400 Message-ID: <CAJHLa0MB8Hh-7np8EpFMj0jioNpxH_D-C=KZrt_Ri6p_Bovc5w@mail.gmail.com> To: Alex Morcos <morcos@gmail.com> Content-Type: multipart/alternative; boundary=047d7b33d812e8888405157f4cba 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 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: 1YqNQm-0004sq-9D Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> Subject: Re: [Bitcoin-development] Block Size Increase X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Thu, 07 May 2015 15:09:46 -0000 --047d7b33d812e8888405157f4cba Content-Type: text/plain; charset=UTF-8 100% agree, RE hard forks should be hard. However, it is the paradox of growth, morale and adoption that bitcoin might never reach the point where it is saturated & expensive to the point where larger blocks are demanded by 95%+... simply because people and companies chose not to adopt bitcoin in the first place due to an unmoving, [perceived | real] scalability roadblock. On Thu, May 7, 2015 at 11:04 AM, Alex Morcos <morcos@gmail.com> wrote: > 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 <gavinandresen@gmail.com> > 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 >> >> > > > ------------------------------------------------------------------------------ > 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 > > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --047d7b33d812e8888405157f4cba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>100% agree, RE hard forks should be hard.<br><br></di= v>However, it is the paradox of growth, morale and adoption that bitcoin mi= ght never reach the point where it is saturated & expensive to the poin= t where larger blocks are demanded by 95%+...=C2=A0 simply because people a= nd companies chose not to adopt bitcoin in the first place due to an unmovi= ng, [perceived | real] scalability roadblock.<br><br></div><div class=3D"gm= ail_extra"><br><div class=3D"gmail_quote">On Thu, May 7, 2015 at 11:04 AM, = Alex Morcos <span dir=3D"ltr"><<a href=3D"mailto:morcos@gmail.com" targe= t=3D"_blank">morcos@gmail.com</a>></span> wrote:<br><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"><div dir=3D"ltr">That strikes me as a dangerous path forward.<di= v><br></div><div>I don't actually think there is anything wrong with th= is: "<span style=3D"font-size:12.8000001907349px">everybody eventually= gets tired of arguing angels-dancing-on-the-head-of-</span><span style=3D"= font-size:12.8000001907349px">a-pin, and we're left with the status quo= "</span></div><div><span style=3D"font-size:12.8000001907349px"><br></= span></div><div><span style=3D"font-size:12.8000001907349px">What gives Bit= coin 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 1MB blocks will be bad, but that by forcing a hard fork that isn&#= 39;t nearly universally agreed upon, we will be damaging that belief. =C2= =A0 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 woul= d still vote against doing it.=C2=A0 Because that's not nearly universa= l agreement, and it changes what people chose to believe in without their c= onsent. Forks should be hard, very hard.=C2=A0 And both sides should recogn= ize that belief in the value of Bitcoin might be a fragile thing. =C2=A0 I&= #39;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 bus= inesses and users that were driven away by the unusable system would be a s= hort term loss in value considerably smaller than the impairment we risk by= forcing a change.</span></div><div><span style=3D"font-size:12.80000019073= 49px"><br></span></div><div><span style=3D"font-size:12.8000001907349px"><b= r></span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te"><div><div class=3D"h5">On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen = <span dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target=3D"= _blank">gavinandresen@gmail.com</a>></span> wrote:<br></div></div><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div class= =3D"gmail_extra">For reference: the blog post that (re)-started this debate= , and which links to individual issues, is here:</div><div class=3D"gmail_e= xtra">=C2=A0=C2=A0<a href=3D"http://gavinandresen.ninja/time-to-roll-out-bi= gger-blocks" target=3D"_blank">http://gavinandresen.ninja/time-to-roll-out-= bigger-blocks</a></div><div class=3D"gmail_extra"><br></div><div class=3D"g= mail_extra">In it, I asked people to email me objections I might have misse= d. 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-wiza= rds and also have time to respond thoughtfully to the objections raised.</d= iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I would = very much like to find some concrete course of action that we can come to c= onsensus on. Some compromise so we can tell entrepreneurs "THIS is how= much transaction volume the main Bitcoin blockchain will be able to suppor= t over the next eleven years."<br><br>I've been pretty clear on wh= at I think is a reasonable compromise (a one-time increase scheduled for ea= rly next year), and I have tried to explain why I think it it is the right = set of tradeoffs.</div><div class=3D"gmail_extra"><br></div><div class=3D"g= mail_extra">There ARE tradeoffs here, and the hard question is what process= do we use to decide those tradeoffs?=C2=A0 How do we come to consensus? Is= it worth my time to spend hours responding thoughtfully to every new objec= tion raised here, or will the same thing happen that happened last year and= the year before-- everybody eventually gets tired of arguing angels-dancin= g-on-the-head-of-a-pin, and we're left with the status quo?</div><div c= lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I AM considering = 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 Int= ernet connection, and assume Nelson's law to increase over time), and t= hen encouraging merchants and exchanges and web wallets and individuals who= think it strikes a reasonable balance to run it.</div><div class=3D"gmail_= extra"><br></div><div class=3D"gmail_extra">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= .</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Beca= use ultimately consensus comes down to what software people choose to run.<= /div><span><font color=3D"#888888"><div class=3D"gmail_extra"><div><br></di= v>-- <br><div>--<br>Gavin Andresen<br></div><div><br></div> </div></font></span></div> <br></div></div><span class=3D"">------------------------------------------= ------------------------------------<br> One dashboard for servers and applications across Physical-Virtual-Cloud<br= > Widest out-of-the-box monitoring support with 50+ applications<br> Performance metrics, stats and reports that give you Actionable Insights<br= > Deep dive visibility with transaction tracing using APM Insight.<br> <a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target= =3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>= _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= nk">Bitcoin-development@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> <br></span></blockquote></div><br></div> <br>-----------------------------------------------------------------------= -------<br> One dashboard for servers and applications across Physical-Virtual-Cloud<br= > Widest out-of-the-box monitoring support with 50+ applications<br> Performance metrics, stats and reports that give you Actionable Insights<br= > Deep dive visibility with transaction tracing using APM Insight.<br> <a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target= =3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>= _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= pment@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> <br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail= _signature">Jeff Garzik<br>Bitcoin core developer and open source evangelis= t<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" targe= t=3D"_blank">https://bitpay.com/</a></div> </div> --047d7b33d812e8888405157f4cba--