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 DB126F1D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 21:08:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com
	[209.85.213.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44051148
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 21:08:30 +0000 (UTC)
Received: by mail-ig0-f179.google.com with SMTP id to4so84162793igc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 13:08:30 -0800 (PST)
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=rfMyoEGKYnaMOAxBqege4rRqKarLEKpRlpAJCQKuCaw=;
	b=kach7HakTWnN2gx9nUAyofzfg6Vb0ftqw0j3Xs45Wp40h4Iea5+ppKRM9eV8ODqX/O
	NinH+/fOeAJY2tu+EidtaiUNKHM7Ud8o+9Ug9tQf1iAHLpUbZ3BXlwIMHFJH4VvvZcAj
	fH+9F7WQEvaV3WN+SUJBywObaG0fP7VacN+QnChd8xIhbjizJvsy8YnqGni0jfWFF70A
	nro518G7L82ZRERnxBY7JkhOcTffk5JRlivQYjZH/OjGJe36Tah4dLkOz+X2pO5s2O7u
	eF3A01X8iKGPvuPohticK67pyij4RqnwfHnzO0jJthSY/nlLIsTs0A7rg+/rilnN3fbl
	KgBg==
MIME-Version: 1.0
X-Received: by 10.50.36.105 with SMTP id p9mr13334635igj.54.1450300109735;
	Wed, 16 Dec 2015 13:08:29 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Wed, 16 Dec 2015 13:08:29 -0800 (PST)
In-Reply-To: <CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
	<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
Date: Wed, 16 Dec 2015 16:08:29 -0500
Message-ID: <CADm_Wcae7OK7kyXkfh+7XFrc2WYsv7T1Va3_E=5om+XYrL9pOw@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=089e01176343dbd3a705270a4eb7
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 development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation &
 moral hazard
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, 16 Dec 2015 21:08:31 -0000

--089e01176343dbd3a705270a4eb7
Content-Type: text/plain; charset=UTF-8

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>

This circles back to Problem #1:   Avoidance of a choice is a still a
choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
Economic Change Event risk.

And #3:  If the likely predicted course is that Bitcoin Core will not
accept a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
term, the core dev team should communicate that position clearly to users
and media.

Hitting a Fee Event is market changing, potentially reshuffling economic
actors to a notable degree.  Maintaining a short term economic policy of
fixed 1M supply in the face of rising transaction volume carries risks that
should be analyzed and communicated.

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

<div dir=3D"ltr">On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <span dir=
=3D"ltr">&lt;<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">p=
ieter.wuille@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Dec=
 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; 2) If block size stays at 1M, the Bitcoin Core developer team should s=
ign a<br>
&gt; collective note stating their desire to transition to a new economic p=
olicy,<br>
&gt; that of &quot;healthy fee market&quot; and strongly urge users to exam=
ine their fee<br>
&gt; policies, wallet software, transaction volumes and other possible User=
<br>
&gt; impacting outcomes.<br>
<br>
</span>You present this as if the Bitcoin Core development team is in charg=
e<br>
of deciding the network consensus rules, and is responsible for making<br>
changes to it in order to satisfy economic demand. If that is the<br>
case, Bitcoin has failed, in my opinion.<br></blockquote><div><br></div><di=
v>This circles back to Problem #1: =C2=A0 Avoidance of a choice is a still =
a choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real=
 Economic Change Event risk.</div><div><br></div><div>And #3: =C2=A0If the =
likely predicted course is that Bitcoin Core will not accept a protocol cha=
nge changing MAX_BLOCK_SIZE via hard fork in the short term, the core dev t=
eam should communicate that position clearly to users and media.</div><div>=
<br></div><div>Hitting a Fee Event is market changing, potentially reshuffl=
ing economic actors to a notable degree.=C2=A0 Maintaining a short term eco=
nomic policy of fixed 1M supply in the face of rising transaction volume ca=
rries risks that should be analyzed and communicated.</div><div><br></div><=
div><br></div><div><br></div><div><br></div></div></div></div>

--089e01176343dbd3a705270a4eb7--