path: root/37/cb316eba5edb8b7eb7784006536cdc7615b853

Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 36FAE71F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 18:03:58 +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 CB26F1AE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 18:03:56 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so164725347wib.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 11:03:55 -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=ugMjmztXfyf2ydsmx+weGY6T0Qh7D9iQlEN9c/5uMo8=;
	b=Eo3xx598DZBE3xw185YvBfcqCIaMYU884pqx2xvfGcoxFzIVtJ0EOcbeuaSIRup2cE
	LPjiUckt179+JpHGC0KeYhn9hZukdDEGhLyZ3I/Ue3RCF1okrer+VT+jNKKjsGNr/bdw
	F+UIByyvW2d0lHdvHe74YzRt6RN8c/HyxgJ+z1ETmRzhM8C/JlJlj7J2ONUrUEz+CVPv
	QaTVkbwIaspclR8iXc3XmgLo6RrcBlht/SbIYwvaTBsTQx37Nx1I5PxTOb21D5KnqIT5
	Krwl6uPltYTkwIw1jMnTZEmsPpJpjy/mb7Qp2CxqiQAnOYWBiGzV9tawdv8YaArqAwcV
	+rwg==
MIME-Version: 1.0
X-Received: by 10.180.10.200 with SMTP id k8mr8859199wib.5.1437588235298; Wed,
	22 Jul 2015 11:03:55 -0700 (PDT)
Received: by 10.180.168.34 with HTTP; Wed, 22 Jul 2015 11:03:55 -0700 (PDT)
In-Reply-To: <CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
Date: Wed, 22 Jul 2015 14:03:55 -0400
Message-ID: <CAPWm=eW8RgrG1CMEAMN4GeiMjZecFvNtZB_Y4rZNeofWSD0=Wg@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c26458195162051b7a986b
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] 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 18:03:58 -0000

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

Jeff I respectively disagree with many of your points, but let me just
point out 2.

Over the last 6 years there may not have been fee pressure, but certainly
there was the expectation that it was going to happen.  Look at all the
work that has been put into fee estimation, why do that work if the
expectation was there would be no fee pressure?

I know you respect Pieter's work, so I don't want to twist your words, but
for the clarity of other people reading these posts, it sounds like you're
accusing Pieter and others of stonewalling size increases and not
participating in planning for them.  Without debate, no one has done more
for this project to make eventual size increases technically feasible than
Pieter.  We only have the privilege of even having this debate as a result
of his work.



On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">Jeff I respectively disagree with many of your points, but=
 let me just point out 2.<div><br></div><div>Over the last 6 years there ma=
y not have been fee pressure, but certainly there was the expectation that =
it was going to happen.=C2=A0 Look at all the work that has been put into f=
ee estimation, why do that work if the expectation was there would be no fe=
e pressure?</div><div><br></div><div>I know you respect Pieter&#39;s work, =
so I don&#39;t want to twist your words, but for the clarity of other peopl=
e reading these posts, it sounds like you&#39;re accusing Pieter and others=
 of stonewalling size increases and not participating in planning for them.=
=C2=A0 Without debate, no one has done more for this project to make eventu=
al size increases technically feasible than Pieter.=C2=A0 We only have the =
privilege of even having this debate as a result of his work.</div><div><br=
></div><div>=C2=A0=C2=A0</div></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik 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><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">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.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:=
<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span clas=
s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width: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 block space and the development of a fee market a change in pol=
icy compared to the past. I respectfully disagree with that. Bitcoin Core i=
s not running the Bitcoin economy, and its developers have no authority to =
set its rules. Change in economics is always happening, and should be expec=
ted. Worse, intervening 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></span><div>This completely =
ignores <i>reality</i>, what users have experienced for the past ~6 years.<=
/div><div><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 traff=
ic bursts, fee pressure has been largely absent.</div><div><br></div><div>M=
oving to a new economic policy where fee pressure is consistently present i=
s radically different from what users, markets, and software have experienc=
ed and <i>lived.</i></div><div><br></div><div>Analysis such as [1][2] and m=
ore shows that users will hit a &quot;painful&quot; &quot;wall&quot; and ma=
rket disruption will occur - eventually settling to a new equilibrium after=
 a period 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-=
bulletin" target=3D"_blank">http://hashingit.com/analysis/34-bitcoin-traffi=
c-bulletin</a></div><div>[2]=C2=A0<a href=3D"http://gavinandresen.ninja/why=
-increasing-the-max-block-size-is-urgent" target=3D"_blank">http://gavinand=
resen.ninja/why-increasing-the-max-block-size-is-urgent</a></div><div><br><=
/div><div>First, users &amp; market are forced through this period of chaos=
 by &quot;let a fee market develop&quot; as the whole market changes to a r=
adically different economic policy, once the 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 be increased eventually.=C2=A0 Wh=
at happens at that point?</div><div><br></div><div>Answer - Users &amp; mar=
ket are forced through a second period of chaos and disruption as the fee m=
arket 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 b=
lock size debate, and really has no idea that the new &quot;let a fee marke=
t develop&quot; Bitcoin Core policy is going to <i>raise fees</i>=C2=A0on t=
hem.</div><div><br></div><div>It is clear that</div><div>- &quot;let the fe=
e market develop, Right Now&quot; has not been thought through</div><div>- =
Users are not prepared for a brand new economic policy</div><div>- Users ar=
e unaware that a brand new economic policy will be foisted upon them</div><=
span class=3D""><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(204,204,204);border-left-style:solid;padding-left:1ex"><p dir=3D"=
ltr">So to point out what I consider obvious: if Bitcoin requires central c=
ontrol over its rules by a group of developers, it is completely uninterest=
ing to me. Consensus changes should be done using consensus, and the defaul=
t in case of controversy is no change.</p></blockquote><div><br></div></spa=
n><div>False.</div><div><br></div><div>All that has to do be done to change=
 bitcoin to a new economic policy - not seen in the entire 6 year history o=
f bitcoin - is to stonewall work on block size.</div><div><br></div><div>Cl=
osing size increase PRs and failing to participate in planning for a block =
size increase accomplishes your stated goal of changing bitcoin to a new ec=
onomic policy.</div><div><br></div><div>&quot;no [code] change&quot;... cha=
nges bitcoin to a brand new economic policy, picking economic winners &amp;=
 losers.=C2=A0 Some businesses will be priced out of bitcoin, etc.</div><di=
v><br></div><div>Stonewalling size increase changes is just as much as a Be=
n Bernanke/FOMC move as increasing the hard limit by hard fork.</div><span =
class=3D""><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(204,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></span><div>Actually you are.</d=
iv><div><br></div><div>When size increase progress gets frozen out of Bitco=
in Core, that just <i>increases</i>=C2=A0the chances that progress must be =
made through a contentious hard fork.</div><div><br></div><div>Further, it =
increases the market disruption users will experience, as described above.<=
/div><div><br></div><div>Think about the users.=C2=A0 Please.</div><div><br=
></div></div><br></div></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>

--001a11c26458195162051b7a986b--