path: root/97/589f6e8b28a0c5bc64f2064e2db5b1340c72f0

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EAD7E83D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 26 Jun 2015 17:57:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
	[209.85.212.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 922F1108
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 26 Jun 2015 17:57:43 +0000 (UTC)
Received: by wicnd19 with SMTP id nd19so51423215wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 26 Jun 2015 10:57:42 -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=lzBbkp05tjyQIkoof6ITb04h/H0Ni9xth1xx1okJdqg=;
	b=dN5fZZA5hSJbz42KMJzR5bqRZpI4Kz5qDEK3QWt7HvRPqEYVACRmTdL065nHguf/2P
	46acSu2+aI9soCyvL3CL6YAxGhTEuohuS1M3H7wlS0/hLQ7y+8Wjd7eIcki2IgerWhPf
	clcNxXizktvnuumXAEttr/nlYdWlPgB/KNJUMWdw6dij2c8+rwmLfrDezqOEKB4YbGaO
	kXph9FRKPWPBhksHihSDzl9Ko+t5z25jR5BicXUItmBjXL9eyY4sihC2MpIBtzNjF2Ec
	mOftdhCK+VTKH70hDYiD6ogrm7FL7GhQWoCLOWOVneGM1Pj6v4bv6L2KmGupW3PHQJVo
	/wkg==
MIME-Version: 1.0
X-Received: by 10.180.211.106 with SMTP id nb10mr6848560wic.33.1435341462226; 
	Fri, 26 Jun 2015 10:57:42 -0700 (PDT)
Received: by 10.28.140.196 with HTTP; Fri, 26 Jun 2015 10:57:42 -0700 (PDT)
In-Reply-To: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
Date: Fri, 26 Jun 2015 10:57:42 -0700
Message-ID: <CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2669cfcce8905196f79aa
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 17:57:45 -0000

--001a11c2669cfcce8905196f79aa
Content-Type: text/plain; charset=UTF-8

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

--001a11c2669cfcce8905196f79aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It is not &quot;fear&quot; of fee pressure.<br><div><br></=
div><div>1) Blocks are mostly not-full on average.</div><div><br></div><div=
>2) Absent long blocks 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 fee pressure is a delta, a change from years-long bitcoi=
n economic policy.=C2=A0 Each time we approach the soft limit, Bitcoin Core=
 increases the soft limit to prevent &quot;full&quot; blocks.=C2=A0 Mike He=
arn et. al. lobbies miners to upgrade.</div><div><br></div><div>(note - thi=
s is not an endorsement of these actions - it is a neutral observation)</di=
v><div><br></div><div>4) Inaction leads to consistent fee pressure as the m=
onths tick on and system volume grows; thus, inaction leads to economic pol=
icy change.</div><div><br></div><div>5) Economic policy change leads to mar=
ket and software disruption.=C2=A0 The market and software - notably wallet=
s - is not prepared for this.</div><div><br></div><div>6) If you want to ch=
ange economic policy, that&#39;s fine.=C2=A0 But be honest and admit you ar=
e arguing for a change, a delta from current market expectations and behavi=
or.</div><div><br></div><div>7) It is critical to first deal with what _is_=
, not what you wish the world to be.=C2=A0 You want a fee market to develop=
.=C2=A0 There is nothing wrong with that desire.=C2=A0 It remains a delta f=
rom where we are today, 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_quote">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"_blan=
k">pieter.wuille@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div><div><div><div><div><div><div><div>Hello=
 all,<br><br></div>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 class=3D"HO=
EnZb"><font color=3D"#888888"><br><br>-- <br></font></span></div><span clas=
s=3D"HOEnZb"><font color=3D"#888888">Pieter<br><br></font></span></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>

--001a11c2669cfcce8905196f79aa--