Return-Path: <pieter.wuille@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 965FD83D for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 26 Jun 2015 18:12:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EAB70EB for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 26 Jun 2015 18:12:55 +0000 (UTC) Received: by wiga1 with SMTP id a1so24179144wig.0 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 26 Jun 2015 11:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9X8pMKad6/kBzspQPKtYhkqf1wasuz7+SyLSYh852/I=; b=g/lKDRIUNZhawCGvEAW+zWTGOtiUP4msG94ty383AwUjtvOO61LH4CAXcVMfYZ243s lzlsoGu1+kcWrBBLU9fx49vBQGHWxeBawXUMN2pdD2jyhSrbbdy5U+mdIZeopSfxefB7 6GBV8QrGyK9Wj+uCIFy5bDJERFY2yyQJ/gFksrshMmGy1XtzxjunnRsF6lKKj4AYzhIa EynuqQeKaYyzfPJ69FktbkeiSVW10kFMSJBr3Fy15+RIerD0rnpgCjeoxJ7D2LEe+0D0 l/SOnbDy/MO0hQ9P79Y7EG7nXRDVragIxQ8g+UxNL0xWZwq7CHtvE52TomryTxoUBesN xMsg== MIME-Version: 1.0 X-Received: by 10.194.112.3 with SMTP id im3mr5244534wjb.54.1435342374727; Fri, 26 Jun 2015 11:12:54 -0700 (PDT) Received: by 10.194.137.38 with HTTP; Fri, 26 Jun 2015 11:12:54 -0700 (PDT) Received: by 10.194.137.38 with HTTP; Fri, 26 Jun 2015 11:12:54 -0700 (PDT) In-Reply-To: <CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com> References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com> <CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com> Date: Fri, 26 Jun 2015 20:12:54 +0200 Message-ID: <CAPg+sBg=sn7djO_8H16NDg7S7m7_0eTcrgLVofMWQ2ANz+jw9w@mail.gmail.com> From: Pieter Wuille <pieter.wuille@gmail.com> To: Jeff Garzik <jgarzik@gmail.com> Content-Type: multipart/alternative; boundary=001a1130ce2260747205196fb01d X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] The need for larger blocks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Fri, 26 Jun 2015 18:12:57 -0000 --001a1130ce2260747205196fb01d Content-Type: text/plain; charset=UTF-8 I am not saying that economic change is what we want. Only that it is inevitable, independent of whether larger blocks happen or not. I am saying that acting because of fear of economic change is a bad reason. The reason for increase should be because of the higher utility. We need it at some point, but there should be no rush. I do understand that we want to avoid a *sudden* change in economic policy, but I'm generally not too worried. Either fees increase and they get paid, and we're good. But more likely is that some uses just move off-chain because the block chain does not offer what they need. That's sad, but it is inevitable at any size: some uses fit, some don't. -- Pieter On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote: > It is not "fear" of fee pressure. > > 1) Blocks are mostly not-full on average. > > 2) Absent long blocks and stress tests, there is little fee pressure above > the anti-spam relay fee metric, because of #1. > > 3) As such, inducing fee pressure is a delta, a change from years-long > bitcoin economic policy. Each time we approach the soft limit, Bitcoin > Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al. > lobbies miners to upgrade. > > (note - this is not an endorsement of these actions - it is a neutral > observation) > > 4) Inaction leads to consistent fee pressure as the months tick on and > system volume grows; thus, inaction leads to economic policy change. > > 5) Economic policy change leads to market and software disruption. The > market and software - notably wallets - is not prepared for this. > > 6) If you want to change economic policy, that's fine. But be honest and > admit you are arguing for a change, a delta from current market > expectations and behavior. > > 7) It is critical to first deal with what _is_, not what you wish the > world to be. You want a fee market to develop. There is nothing wrong > with that desire. It remains a delta from where we are today, and that is > critically relevant in a $3b+ market. > > > > > > > > > On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille@gmail.com> > wrote: > >> Hello all, >> >> here I'm going to try to address a part of the block size debate which >> has been troubling me since the beginning: the reason why people seem to >> want it. >> >> People say that larger blocks are necessary. In the long term, I agree - >> in the sense that systems that do not evolve tend to be replaced by other >> systems. This evolution can come in terms of layers on top of Bitcoin's >> blockchain, in terms of the technology underlying various aspects of the >> blockchain itself, and also in the scale that this technology supports. >> >> I do, however, fundamentally disagree that a fear for a change in >> economics should be considered to necessitate larger blocks. If it is, and >> there is consensus that we should adapt to it, then there is effectively no >> limit going forward. This is similar to how Congress voting to increase the >> copyright term retroactively from time to time is really no different from >> having an infinite copyright term in the first place. This scares me. >> >> Here is how Gavin summarizes the future without increasing block sizes in >> PR 6341: >> >> > 1. Transaction confirmation times for transactions with a given fee >> will rise; very-low-fee transactions will fail to get confirmed at all. >> > 2. Average transaction fee paid will rise >> > 3. People or applications unwilling or unable to pay the rising fees >> will stop submitting transactions >> > 4. People and businesses will shelve plans to use Bitcoin, stunting >> growth and adoption >> >> Is it fair to summarize this as "Some use cases won't fit any more, >> people will decide to no longer use the blockchain for these purposes, and >> the fees will adapt."? >> >> I think that is already happening, and will happen at any scale. I >> believe demand for payments in general is nearly infinite, and only a small >> portion of it will eventually fit on a block chain (independent of whether >> its size is limited by consensus rules or economic or technological means). >> Furthermore, systems that compete with Bitcoin in this space already offer >> orders of magnitude more capacity than we can reasonably achieve with any >> blockchain technology at this point. >> >> I don't know what subset of use cases Bitcoin will cater to in the long >> term. They have already changed - you see way less betting transactions >> these days than a few years ago for example - and they will keep changing, >> independent of what effective block sizes we end up with. I don't think we >> should be afraid of this change or try to stop it. >> >> If you look at graphs of block sizes over time (for example, >> http://rusty.ozlabs.org/?p=498), it seems to me that there is very >> little "organic" growth, and a lot of sudden changes (which could >> correspond to changing defaults in miner software, introduction of popular >> sites/services, changes in the economy). I think these can be seen as the >> economy changing to full up the available space, and I believe these will >> keep happening at any size effectively available. >> >> None of this is a reason why the size can't increase. However, in my >> opinion, we should do it because we believe it increases utility and >> understand the risks; not because we're afraid of what might happen if we >> don't hurry up. And from that point of view, it seems silly to make a huge >> increase at once... >> >> -- >> Pieter >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > --001a1130ce2260747205196fb01d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">I am not saying that economic change is what we want. Only t= hat it is inevitable, independent of whether larger blocks happen or not.</= p> <p dir=3D"ltr">I am saying that acting because of fear of economic change i= s a bad reason. The reason for increase should be because of the higher uti= lity. We need it at some point, but there should be no rush.</p> <p dir=3D"ltr">I do understand that we want to avoid a *sudden* change in e= conomic policy, but I'm generally not too worried. Either fees increase= and they get paid, and we're good. But more likely is that some uses j= ust move off-chain because the block chain does not offer what they need. T= hat's sad, but it is inevitable at any size: some uses fit, some don= 9;t.</p> <p dir=3D"ltr">-- <br> Pieter<br> </p> <div class=3D"gmail_quote">On Jun 26, 2015 7:57 PM, "Jeff Garzik"= <<a href=3D"mailto:jgarzik@gmail.com">jgarzik@gmail.com</a>> wrote:<= br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It = is not "fear" of fee pressure.<br><div><br></div><div>1) Blocks a= re mostly not-full on average.</div><div><br></div><div>2) Absent long bloc= ks and stress tests, there is little fee pressure above the anti-spam relay= fee metric, because of #1.</div><div><br></div><div>3) As such, inducing f= ee pressure is a delta, a change from years-long bitcoin economic policy.= =C2=A0 Each time we approach the soft limit, Bitcoin Core increases the sof= t limit to prevent "full" blocks.=C2=A0 Mike Hearn et. al. lobbie= s miners to upgrade.</div><div><br></div><div>(note - this is not an endors= ement of these actions - it is a neutral observation)</div><div><br></div><= div>4) Inaction leads to consistent fee pressure as the months tick on and = system volume grows; thus, inaction leads to economic policy change.</div><= div><br></div><div>5) Economic policy change leads to market and software d= isruption.=C2=A0 The market and software - notably wallets - is not prepare= d for this.</div><div><br></div><div>6) If you want to change economic poli= cy, that's fine.=C2=A0 But be honest and admit you are arguing for a ch= ange, a delta from current market expectations and behavior.</div><div><br>= </div><div>7) It is critical to first deal with what _is_, not what you wis= h the world to be.=C2=A0 You want a fee market to develop.=C2=A0 There is n= othing wrong with that desire.=C2=A0 It remains a delta from where we are t= oday, and that is critically relevant in a $3b+ market.</div><div><br></div= ><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div= ><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu= ote">On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <span dir=3D"ltr"><<= a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@g= mail.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"><div><div><div><div><div><div><div><div><div>Hello all,<br><br></d= iv>here I'm going to try to address a part of the block size debate which has been=20 troubling me since the beginning: the reason why people seem to want it.<br= ><br></div>People say that larger blocks are necessary. In the long term, I agree - in=20 the sense that systems that do not evolve tend to be replaced by other=20 systems. This evolution can come in terms of layers on top of Bitcoin's= =20 blockchain, in terms of the technology underlying various aspects of the blockchain itself, and also in the scale that this technology supports.<br= ><br></div>I do, however, fundamentally disagree that a fear for a change in=20 economics should be considered to necessitate larger blocks. If it is,=20 and there is consensus that we should adapt to it, then there is=20 effectively no limit going forward. This is similar to how Congress=20 voting to increase the copyright term retroactively from time to time is really no different from having an infinite copyright term in the first place. This scares me.<br><br></div>Here is how Gavin summarizes the futur= e without increasing block sizes in PR 6341:<br><br>> 1. Transaction con= firmation times for transactions with a given fee=20 will rise; very-low-fee transactions will fail to get confirmed at all.<br>= > 2. Average transaction fee paid will rise<br>> 3. People or applica= tions unwilling or unable to pay the rising fees will stop submitting trans= actions<br>> 4. People and businesses will shelve plans to use Bitcoin, = stunting growth and adoption<br><br></div>Is it fair to summarize this as "Some use cases won't fit any more, = people will decide to no longer use the blockchain for these purposes, and the fees will adapt."?<br><br></div>I think that is already happening, an= d=20 will happen at any scale. I believe demand for payments in general is=20 nearly infinite, and only a small portion of it will eventually fit on a block chain (independent of whether its size is limited by consensus=20 rules or economic or technological means). Furthermore, systems that=20 compete with Bitcoin in this space already offer orders of magnitude=20 more capacity than we can reasonably achieve with any blockchain=20 technology at this point.<br><br>I don't know what subset of use cases= =20 Bitcoin will cater to in the long term. They have already changed - you=20 see way less betting transactions these days than a few years ago for=20 example - and they will keep changing, independent of what effective=20 block sizes we end up with. I don't think we should be afraid of this= =20 change or try to stop it.<br><br></div>If you look at graphs of block sizes= over time (for example, <a href=3D"http://rusty.ozlabs.org/?p=3D498" targe= t=3D"_blank">http://rusty.ozlabs.org/?p=3D498</a>), it seems to me that there is very little "organic" growth, and a= lot of sudden changes (which could correspond to changing defaults in miner=20 software, introduction of popular sites/services, changes in the=20 economy). I think these can be seen as the economy changing to full up=20 the available space, and I believe these will keep happening at any size effectively available.<br><br></div>None of this is a reason why the=20 size can't increase. However, in my opinion, we should do it because we= =20 believe it increases utility and understand the risks; not because we'r= e afraid of what might happen if we don't hurry up. And from that point= =20 of view, it seems silly to make a huge increase at once...<span><font color= =3D"#888888"><br><br>-- <br></font></span></div><span><font color=3D"#88888= 8">Pieter<br><br></font></span></div> <br>_______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> <br></blockquote></div><br></div> </blockquote></div> --001a1130ce2260747205196fb01d--