From mboxrd@z Thu Jan 1 00:00:00 1970 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 1YqI3M-00052x-9e for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 09:25:12 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.177 as permitted sender) client-ip=209.85.212.177; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f177.google.com; Received: from mail-wi0-f177.google.com ([209.85.212.177]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqI3K-0002F5-Hz for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 09:25:12 +0000 Received: by wief7 with SMTP id f7so9111264wie.0 for ; Thu, 07 May 2015 02:25:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.105.193 with SMTP id go1mr4738498wib.92.1430990704539; Thu, 07 May 2015 02:25:04 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.90.114 with HTTP; Thu, 7 May 2015 02:25:04 -0700 (PDT) In-Reply-To: <554A91BE.6060105@bluematt.me> References: <554A91BE.6060105@bluematt.me> Date: Thu, 7 May 2015 11:25:04 +0200 X-Google-Sender-Auth: AY3fU2phLRIvyIfx90-jbiFoULA Message-ID: From: Mike Hearn To: Matt Corallo Content-Type: multipart/alternative; boundary=f46d041828009efea905157a7c29 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1YqI3K-0002F5-Hz 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 09:25:12 -0000 --f46d041828009efea905157a7c29 Content-Type: text/plain; charset=UTF-8 Hey Matt, OK, let's get started .... However, there hasnt been any discussion on this > mailing list in several years as far as I can tell. > Probably because this list is not a good place for making progress or reaching decisions. Those are triggered by pull requests (sometimes). If you're wondering "why now", that's probably my fault. A few days ago Wladimir posted a release timeline. I observed to Wladimir and Gavin in private that this timeline meant a change to the block size was unlikely to get into 0.11, leaving only 0.12, which would give everyone only a few months to upgrade in order to fork the chain by the end of the winter growth season. That seemed tight. Wladimir did not reply to this email, unfortunately. Perhaps he would like the issue to go away. It won't - if Bitcoin continues on its current growth trends it *will* run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window. > Certainly a consensus in this kind of technical community should be a > basic requirement for any serious commitment to blocksize increase. > I'm afraid I have come to disagree. I no longer believe this community can reach consensus on anything protocol related. Some of these arguments have dragged on for years. Consensus isn't even well defined - consensus of who? Anyone who shows up? And what happens when, inevitably, no consensus is reached? Stasis forever? > Long-term incentive compatibility requires that there be some fee > pressure, and that blocks be relatively consistently full or very nearly > full. I disagree. When the money supply eventually dwindles I doubt it will be fee pressure that funds mining, but as that's a long time in the future, it's very hard to predict what might happen. > What we see today are > transactions enjoying next-block confirmations with nearly zero pressure > to include any fee at all (though many do because it makes wallet code > simpler). > Many do because free transactions are broken - the relay limiter means whether a free transaction actually makes it across the network or not is basically pot luck and there's no way for a wallet to know, short of either trying it or actually receiving every single transaction and repeating the calculations. If free transactions weren't broken for all non-full nodes they'd probably be used a lot more. > This allows the well-funded Bitcoin ecosystem to continue building > systems which rely on transactions moving quickly into blocks while > pretending these systems scale. I have two huge problems with this line of thinking. Firstly, no, the "Bitcoin ecosystem" is not well funded. Blockstream might be, but significant numbers of users are running programs developed by tiny startups, or volunteers who don't have millions in venture capital to play with. Arm-twisting "the ecosystem" into developing complicated Rube Goldberg machines in double quick time, just to keep the Bitcoin show on the road, is in fact the opposite of decentralisation - it will effectively exclude anyone who isn't able to raise large amounts of corporate funding from writing code that uses the Bitcoin network. Decentralisation benefits from simplicity, and bigger blocks are (in Gavin's words) "the simplest thing that will work". My second problem is the claim that everyone is playing pretend about Bitcoin, except you guys. I would put it another way - I would say those people are building products and getting users, by making reasonable engineering tradeoffs and using systems that work. Yes, one day those systems might have to change. That's the nature of scaling. It's the nature of progress. But not today. Probably not tomorrow either. What I would like to see from Blockstream is a counter-proposal. So far you have made lots of vague comments that we all agree with - yes, decentralisation is good, yes some block size limit must exist, if only because computers are finite machines. What I don't see from you yet is a *specific and credible plan* that fits within the next 12 months and which allows Bitcoin to keep growing. Not some vague handwave like "let's all use the Lightning network" (which does not exist), or "let's do more research" (Gavin has done plenty of research), or "but what about the risks" (Bitcoin is full of risks). A plan, with dates attached, and a strong chance of actually being deployed in time. --f46d041828009efea905157a7c29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Matt,

OK, let's get started ...= .

However, there hasnt been any discussion on this
mailing list in several years as far as I can tell.
Probably because this list is not a good place for making prog= ress or reaching decisions. Those are triggered by pull requests (sometimes= ).

If you're wondering "why now", th= at's probably my fault. A few days ago Wladimir posted a release timeli= ne. I observed to Wladimir and Gavin in private that this timeline meant a = change to the block size was unlikely to get into 0.11, leaving only 0.12, = which would give everyone only a few months to upgrade in order to fork the= chain by the end of the winter growth season. That seemed tight.

Wladimir did not reply to this email, unfortunately. Perhap= s he would like the issue to go away. It won't - if Bitcoin continues o= n its current growth trends it will=C2=A0run out of capacity, almost= certainly by some time next year.

What we need to= see right now is leadership and a plan, that fits in the available time wi= ndow.
=C2=A0
Certainly a consensus in this = kind of=C2=A0technical community should be a basic requirement for any seri= ous=C2=A0commitment to blocksize increase.

<= div>I'm afraid I have come to disagree. I no longer believe this commun= ity can reach consensus on anything protocol related. Some of these argumen= ts have dragged on for years. Consensus isn't even well defined - conse= nsus of who? Anyone who shows up? And what happens when, inevitably, no con= sensus is reached? Stasis forever?
=C2=A0
= Long-term incentive compatibility requires=C2=A0that there be some fee pres= sure, and that blocks be relatively=C2=A0consistently full or very nearly f= ull.

I disagree. When the money supply eve= ntually dwindles I doubt it will be fee pressure that funds mining, but as = that's a long time in the future, it's very hard to predict what mi= ght happen.
=C2=A0
What we see today ar= e
transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code
simpler).

Many do because free transact= ions are broken - the relay limiter means whether a free transaction actual= ly makes it across the network or not is basically pot luck and there's= no way for a wallet to know, short of either trying it or actually receivi= ng every single transaction and repeating the calculations. If free transac= tions weren't broken for all non-full nodes they'd probably be used= a lot more.
=C2=A0
This allows the well-f= unded Bitcoin ecosystem to continue building
systems which rely on transactions moving quickly into blocks while
pretending these systems scale.

I have two = huge problems with this line of thinking.

Firstly,= no, the "Bitcoin ecosystem" is not well funded. Blockstream migh= t be, but significant numbers of users are running programs developed by ti= ny startups, or volunteers who don't have millions in venture capital t= o play with.=C2=A0

Arm-twisting "the ecosyste= m" into developing complicated Rube Goldberg machines in double quick = time, just to keep the Bitcoin show on the road, is in fact the opposite of= decentralisation - it will effectively exclude anyone who isn't able t= o raise large amounts of corporate funding from writing code that uses the = Bitcoin network. Decentralisation benefits from simplicity, and bigger bloc= ks are (in Gavin's words) "the simplest thing that will work"= .

My second problem is the claim that everyone is = playing pretend about Bitcoin, except you guys. I would put it another way = - I would say those people are building products and getting users, by maki= ng reasonable engineering tradeoffs and using systems that work. Yes, one d= ay those systems might have to change. That's the nature of scaling. It= 's the nature of progress. But not today. Probably not tomorrow either.=

What I would like to see from Blockstream is a co= unter-proposal. So far you have made lots of vague comments that we all agr= ee with - yes, decentralisation is good, yes some block size limit must exi= st, if only because computers are finite machines.=C2=A0

What I don't see from you yet is a specific and=C2=A0credible= =C2=A0plan=C2=A0that fits within the next 12 months and which allows Bi= tcoin to keep growing. Not some vague handwave like "let's all use= the Lightning network" (which does not exist), or "let's do = more research" (Gavin has done plenty of research), or "but what = about the risks" (Bitcoin is full of risks). A plan, with dates attach= ed, and a strong chance of actually being deployed in time.
--f46d041828009efea905157a7c29--