Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YzPu6-0007nm-5O for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 13:37:22 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.179 as permitted sender) client-ip=209.85.217.179; envelope-from=gavinandresen@gmail.com; helo=mail-lb0-f179.google.com; Received: from mail-lb0-f179.google.com ([209.85.217.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YzPu2-00004y-7A for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 13:37:22 +0000 Received: by lbbqq2 with SMTP id qq2so84470322lbb.3 for ; Mon, 01 Jun 2015 06:37:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.199.133 with SMTP id jk5mr21580820lbc.32.1433165831781; Mon, 01 Jun 2015 06:37:11 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Mon, 1 Jun 2015 06:37:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jun 2015 09:37:11 -0400 Message-ID: From: Gavin Andresen To: =?UTF-8?B?SsOpcsO0bWUgTGVnb3VwaWw=?= Content-Type: multipart/alternative; boundary=001a11c264be4ec4db051774ec6f 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 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YzPu2-00004y-7A Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step 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 13:37:22 -0000 --001a11c264be4ec4db051774ec6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RE: going to the public: I started pushing privately for SOMETHING, ANYTHING to be done, or at the very least for there to be some coherent plan besides "wait and see" back in February. As for it being unhealthy for me to write the code that I think should be written and asking people to run it: Ok. What would you suggest I do? I believe scaling up is the number one priority right now. I think core devs SHOULD be taking time to solve it, because I think the uncertainty of how it will be solved (or if it will be solved) is bad for Bitcoin. I think working on things like fixing transaction malleability is great... but the reason to work on that is to enable smart contracts and all sorts of other interesting new uses of the blockchain. But if we're stuck with 1MB blocks then there won't be room for all of those interesting new uses on the blockchain. Others disagree, and have the advantage of status-quo : if nothing is done, they get what they want. Based on some comments I've seen, I think there is also concern that "my own personal network/computer connection might not be able to handle more transaction volume." That is NOT a good reason to limit scalability, but I think it is clouding the judgement of many of the core contributors who started contributing as a spare-time hobby from their homes (where maybe they have crappy DSL connections). RE: decentralization: I think this is a red-herring. I'll quote something I said on reddit yesterday: "I don't believe a 20MB max size will increase centralization to any significant degree. See http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-cen= tralized and http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners And I think we will have a lot LESS centralization of payments via services like Coinbase (or hubs in some future StrawPay/Lightning network) if the bitcoin network can directly handle more payment volume. The centralization trade-offs seems very clear to me, and I think the "big blocks mean more centralized" arguments are either just wrong or are exaggerated or ignore the tradeoff with payment centralization (I think that is a lot more important for privacy and censorship resistance)." RE: incentives for off-chain solutions: I'll quote myself again from http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea : "The =E2=80=9Clayer 2=E2=80=9D services that are being built on top of the = blockchain are absolutely necessary to get nearly instant real-time payments, micropayments and high volume machine-to-machine payments, to pick just three examples. The ten-minute settlement time of blocks on the network is not fast enough for those problems, and it will be the ten minute block interval that drives development of those off-chain innovations more than the total number of transactions supported." On Mon, Jun 1, 2015 at 8:45 AM, J=C3=A9r=C3=B4me Legoupil wrote: > If during the "1MB bumpy period" something goes wrong, consensus among th= e > community would be reached easily if necessary. > That is the problem: this will be a "frog in boiling water" problem. I believe there will be no sudden crisis-- instead, transactions will just get increasingly unreliable and expensive, driving more and more people away from Bitcoin towards... I don't know what. Some less expensive, more reliable, probably more-centralized solution. The Gavin 20MB proposal is compromising Bitcoin's long-term security in an > irreversible way, for gaining short-term better user experience. > If by long-term security you mean "will transaction fees be high enough to pay for enough hashing power to secure the network if there are bigger blocks" I've written about that: http://gavinandresen.ninja/block-size-and-miner-fees-again If you mean something else, then please be specific. --=20 -- Gavin Andresen --001a11c264be4ec4db051774ec6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RE: going to the public:

I started push= ing privately for SOMETHING, ANYTHING to be done, or at the very least for = there to be some coherent plan besides "wait and see" back in Feb= ruary.

As for it being unhealthy for me to write t= he code that I think should be written and asking people to run it:

Ok. What would you suggest I do? I believe scaling up is = the number one priority right now. I think core devs SHOULD be taking time = to solve it, because I think the uncertainty of how it will be solved (or i= f it will be solved) is bad for Bitcoin.

I think w= orking on things like fixing transaction malleability is great... but the r= eason to work on that is to enable smart contracts and all sorts of other i= nteresting new uses of the blockchain. But if we're stuck with 1MB bloc= ks then there won't be room for all of those interesting new uses on th= e blockchain.

Others disagree, and have the advant= age of status-quo : if nothing is done, they get what they want.
=
Based on some comments I've seen, I think there is also = concern that "my own personal network/computer connection might not be= able to handle more transaction volume." That is NOT a good reason to= limit scalability, but I think it is clouding the judgement of many of the= core contributors who started contributing as a spare-time hobby from thei= r homes (where maybe they have crappy DSL connections).


RE: decentralization:

I think= this is a red-herring. I'll quote something I said on reddit yesterday= :

"I don't believe a 20MB max size will increa= se centralization to any significant degree.

See http://gavinandresen.ninja/are-bigger-bloc= ks-better-for-bigger-miners

And I think we will have a lot LESS = centralization of payments via services like Coinbase (or hubs in some futu= re StrawPay/Lightning network) if the bitcoin network can directly handle m= ore payment volume.

The centralization trade-offs seems very clear t= o me, and I think the "big blocks mean more centralized" argument= s are either just wrong or are exaggerated or ignore the tradeoff with paym= ent centralization (I think that is a lot more important for privacy and ce= nsorship resistance)."


RE: incentive= s for off-chain solutions:

I'll quote myself again from=C2=A0ht= tp://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea :

"The =E2=80=9Clayer 2=E2=80=9D services that are being built on= top of the blockchain are absolutely necessary to get nearly instant real-= time payments, micropayments and high volume machine-to-machine payments, t= o pick just three examples. The ten-minute settlement time of blocks on the= network is not fast enough for those problems, and it will be the ten minu= te block interval that drives development of those off-chain innovations mo= re than the total number of transactions supported."

On Mon, Jun 1, 2015 at 8:45 AM, J=C3=A9r=C3=B4me Legoupil <jjlegoupil= @gmail.com> wrote:
If during the "= ;1MB bumpy period" something goes wrong, consensus among the community= would be reached easily if necessary.
That is the problem: this will be a "frog in boiling water= " problem. I believe there will be no sudden crisis-- instead, transac= tions will just get increasingly unreliable and expensive, driving more and= more people away from Bitcoin towards... I don't know what. Some less = expensive, more reliable, probably more-centralized solution.
The Gavin 20MB proposal is compromising Bitcoin's long-term security in an= =20 irreversible way, for gaining short-term better user experience.
=

If by long-term security you mean &q= uot;will transaction fees be high enough to pay for enough hashing power to= secure the network if there are bigger blocks" I've written about= that:=C2=A0http://gavinandresen.ninja/block-size-and-miner-fees-again


If you mean something else, then please= be specific.

--
--
Gavin Andresen
--001a11c264be4ec4db051774ec6f--