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 ) 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 ; 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: References: <554A91BE.6060105@bluematt.me> From: Jeff Garzik Date: Thu, 7 May 2015 11:09:18 -0400 Message-ID: To: Alex Morcos 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 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: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 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 > 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
100% agree, RE hard forks should be hard.

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.


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 th= is: "everybody eventually= gets tired of arguing angels-dancing-on-the-head-of-a-pin, and we're left with the status quo= "

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.


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:
=C2=A0=C2=A0http://gavinandresen.ninja/time-to-roll-out-= bigger-blocks

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.

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."

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.

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?

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.

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= .

Beca= use ultimately consensus comes down to what software people choose to run.<= /div>

--
--
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-de= velopment



-----------------------------------------------------------------------= -------
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




--
Jeff Garzik
Bitcoin core developer and open source evangelis= t
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--047d7b33d812e8888405157f4cba--