path: root/0c/3f395b69942d1bbe5a7183708307c5d25f5d5f

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 462F245E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 17:33:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com
	[209.85.220.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CACB7229
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 17:33:18 +0000 (UTC)
Received: by pacan13 with SMTP id an13so143184240pac.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 10:33:18 -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=JK3R5nyzU7qRUCplx2cqWU1CYTp7IkL8XqpA28I/zu8=;
	b=MPZ/8CJ7T2v86KW0J6riOkNtGGVPe6nQTOG1TB6oNeBOVbN+sn2C7CzcgTtwatwZtD
	geBGW/mG9lajhshCedoRFDbWm9SvWfpLezhsjcKS9j8xQ2zHSXV81TP4WFPwJUwiqZhQ
	lsx/U/nrtkGB4fOitKRiQryisBwUYDzjhCLvqMf1cbCEEDngDMUXbIKWheoZsJp9HIVg
	f0QH1C7mM/9tlB+KfzZ/ALHrt6yU+nIrUS2tT2XM1/IkfwTgu8mLC8+S/s007EwLuXw3
	Q/YXKZP+EtAaMuzAq1e2G1QJjoIFSn3g7j1XlyuSLuK7KfWAkjvaUhGUyV7p3R3/GnkT
	QnVA==
MIME-Version: 1.0
X-Received: by 10.70.126.193 with SMTP id na1mr8353966pdb.26.1437586398363;
	Wed, 22 Jul 2015 10:33:18 -0700 (PDT)
Received: by 10.79.38.79 with HTTP; Wed, 22 Jul 2015 10:33:18 -0700 (PDT)
In-Reply-To: <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
Date: Wed, 22 Jul 2015 10:33:18 -0700
Message-ID: <CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c30ea69bc9e5051b7a2ac8
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,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] Bitcoin Core and hard forks
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: Wed, 22 Jul 2015 17:33:20 -0000

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

On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Some people have called the prospect of limited block space and the
> development of a fee market a change in policy compared to the past. I
> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
> economy, and its developers have no authority to set its rules. Change in
> economics is always happening, and should be expected. Worse, intervening
> in consensus changes would make the ecosystem more dependent on the group
> taking that decision, not less.
>
>
This completely ignores *reality*, what users have experienced for the past
~6 years.

"Change in economics is always happening" does not begin to approach the
scale of the change.

For the entirety of bitcoin's history, absent long blocks and traffic
bursts, fee pressure has been largely absent.

Moving to a new economic policy where fee pressure is consistently present
is radically different from what users, markets, and software have
experienced and *lived.*

Analysis such as [1][2] and more shows that users will hit a "painful"
"wall" and market disruption will occur - eventually settling to a new
equilibrium after a period of chaos - when blocks are consistently full.

[1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
[2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent

First, users & market are forced through this period of chaos by "let a fee
market develop" as the whole market changes to a radically different
economic policy, once the network has never seen before.

Next, when blocks are consistently full, the past consensus was that block
size limit will be increased eventually.  What happens at that point?

Answer - Users & market are forced through a second period of chaos and
disruption as the fee market is rebooted *again* by changing the block size
limit.

The average user hears a lot of noise on both sides of the block size
debate, and really has no idea that the new "let a fee market develop"
Bitcoin Core policy is going to *raise fees* on them.

It is clear that
- "let the fee market develop, Right Now" has not been thought through
- Users are not prepared for a brand new economic policy
- Users are unaware that a brand new economic policy will be foisted upon
them



> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.
>

False.

All that has to do be done to change bitcoin to a new economic policy - not
seen in the entire 6 year history of bitcoin - is to stonewall work on
block size.

Closing size increase PRs and failing to participate in planning for a
block size increase accomplishes your stated goal of changing bitcoin to a
new economic policy.

"no [code] change"... changes bitcoin to a brand new economic policy,
picking economic winners & losers.  Some businesses will be priced out of
bitcoin, etc.

Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC
move as increasing the hard limit by hard fork.



> My personal opinion is that we - as a community - should indeed let a fee
> market develop, and rather sooner than later, and that "kicking the can
> down the road" is an incredibly dangerous precedent: if we are willing to
> go through the risk of a hard fork because of a fear of change of
> economics, then I believe that community is not ready to deal with change
> at all. And some change is inevitable, at any block size. Again, this does
> not mean the block size needs to be fixed forever, but its intent should be
> growing with the evolution of technology, not a panic reaction because a
> fear of change.
>
> But I am not in any position to force this view. I only hope that people
> don't think a fear of economic change is reason to give up consensus.
>

Actually you are.

When size increase progress gets frozen out of Bitcoin Core, that just
*increases* the chances that progress must be made through a contentious
hard fork.

Further, it increases the market disruption users will experience, as
described above.

Think about the users.  Please.

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

<div dir=3D"ltr">On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin=
-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</s=
pan> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><p dir=3D"ltr">Some people have called the prospect of limited b=
lock space and the development of a fee market a change in policy compared =
to the past. I respectfully disagree with that. Bitcoin Core is not running=
 the Bitcoin economy, and its developers have no authority to set its rules=
. Change in economics is always happening, and should be expected. Worse, i=
ntervening in consensus changes would make the ecosystem more dependent on =
the group taking that decision, not less.<br></p>
<p dir=3D"ltr"></p></blockquote><div><br></div><div>This completely ignores=
 <i>reality</i>, what users have experienced for the past ~6 years.</div><d=
iv><br></div><div>&quot;Change in economics is always happening&quot; does =
not begin to approach the scale of the change.</div><div><br></div><div>For=
 the entirety of bitcoin&#39;s history, absent long blocks and traffic burs=
ts, fee pressure has been largely absent.</div><div><br></div><div>Moving t=
o a new economic policy where fee pressure is consistently present is radic=
ally different from what users, markets, and software have experienced and =
<i>lived.</i></div><div><br></div><div>Analysis such as [1][2] and more sho=
ws that users will hit a &quot;painful&quot; &quot;wall&quot; and market di=
sruption will occur - eventually settling to a new equilibrium after a peri=
od of chaos - when blocks are consistently full.</div><div><br></div><div>[=
1]=C2=A0<a href=3D"http://hashingit.com/analysis/34-bitcoin-traffic-bulleti=
n">http://hashingit.com/analysis/34-bitcoin-traffic-bulletin</a></div><div>=
[2]=C2=A0<a href=3D"http://gavinandresen.ninja/why-increasing-the-max-block=
-size-is-urgent">http://gavinandresen.ninja/why-increasing-the-max-block-si=
ze-is-urgent</a></div><div><br></div><div>First, users &amp; market are for=
ced through this period of chaos by &quot;let a fee market develop&quot; as=
 the whole market changes to a radically different economic policy, once th=
e network has never seen before.</div><div><br></div><div>Next, when blocks=
 are consistently full, the past consensus was that block size limit will b=
e increased eventually.=C2=A0 What happens at that point?</div><div><br></d=
iv><div>Answer - Users &amp; market are forced through a second period of c=
haos and disruption as the fee market is rebooted <i>again</i> by changing =
the block size limit.</div><div><br></div><div>The average user hears a lot=
 of noise on both sides of the block size debate, and really has no idea th=
at the new &quot;let a fee market develop&quot; Bitcoin Core policy is goin=
g to <i>raise fees</i>=C2=A0on them.</div><div><br></div><div>It is clear t=
hat</div><div>- &quot;let the fee market develop, Right Now&quot; has not b=
een thought through</div><div>- Users are not prepared for a brand new econ=
omic policy</div><div>- Users are unaware that a brand new economic policy =
will be foisted upon them</div><div><br></div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><p dir=3D"ltr">So to point out what I consider obvious: if Bitcoin req=
uires central control over its rules by a group of developers, it is comple=
tely uninteresting to me. Consensus changes should be done using consensus,=
 and the default in case of controversy is no change.</p></blockquote><div>=
<br></div><div>False.</div><div><br></div><div>All that has to do be done t=
o change bitcoin to a new economic policy - not seen in the entire 6 year h=
istory of bitcoin - is to stonewall work on block size.</div><div><br></div=
><div>Closing size increase PRs and failing to participate in planning for =
a block size increase accomplishes your stated goal of changing bitcoin to =
a new economic policy.</div><div><br></div><div>&quot;no [code] change&quot=
;... changes bitcoin to a brand new economic policy, picking economic winne=
rs &amp; losers.=C2=A0 Some businesses will be priced out of bitcoin, etc.<=
/div><div><br></div><div>Stonewalling size increase changes is just as much=
 as a Ben Bernanke/FOMC move as increasing the hard limit by hard fork.</di=
v><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
<p dir=3D"ltr">My personal opinion is that we - as a community - should ind=
eed let a fee market develop, and rather sooner than later, and that &quot;=
kicking the can down the road&quot; is an incredibly dangerous precedent: i=
f we are willing to go through the risk of a hard fork because of a fear of=
 change of economics, then I believe that community is not ready to deal wi=
th change at all. And some change is inevitable, at any block size. Again, =
this does not mean the block size needs to be fixed forever, but its intent=
 should be growing with the evolution of technology, not a panic reaction b=
ecause a fear of change.<br></p>
<p dir=3D"ltr">But I am not in any position to force this view. I only hope=
 that people don&#39;t think a fear of economic change is reason to give up=
 consensus.</p></blockquote><div><br></div><div>Actually you are.</div><div=
><br></div><div>When size increase progress gets frozen out of Bitcoin Core=
, that just <i>increases</i>=C2=A0the chances that progress must be made th=
rough a contentious hard fork.</div><div><br></div><div>Further, it increas=
es the market disruption users will experience, as described above.</div><d=
iv><br></div><div>Think about the users.=C2=A0 Please.</div><div><br></div>=
</div><br></div></div>

--001a11c30ea69bc9e5051b7a2ac8--