path: root/11/10609ead754253797381d60141338ec6fad3af

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&#39;m generally not too worried. Either fees increase=
 and they get paid, and we&#39;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&#39;s sad, but it is inevitable at any size: some uses fit, some don&#3=
9;t.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
<div class=3D"gmail_quote">On Jun 26, 2015 7:57 PM, &quot;Jeff Garzik&quot;=
 &lt;<a href=3D"mailto:jgarzik@gmail.com">jgarzik@gmail.com</a>&gt; 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 &quot;fear&quot; 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 &quot;full&quot; 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&#39;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">&lt;<=
a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@g=
mail.com</a>&gt;</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&#39;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&#39;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>&gt; 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>=
&gt; 2. Average transaction fee paid will rise<br>&gt; 3. People or applica=
tions unwilling or unable to pay the rising fees will stop submitting trans=
actions<br>&gt; 4. People and businesses will shelve plans to use Bitcoin, =
stunting growth and adoption<br><br></div>Is
 it fair to summarize this as &quot;Some use cases won&#39;t fit any more, =
people
 will decide to no longer use the blockchain for these purposes, and the
 fees will adapt.&quot;?<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&#39;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&#39;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 &quot;organic&quot; 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&#39;t increase. However, in my opinion, we should do it because we=
=20
believe it increases utility and understand the risks; not because we&#39;r=
e
 afraid of what might happen if we don&#39;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--