1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
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"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">p=
ieter.wuille@gmail.com</a>></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>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> 2) If block size stays at 1M, the Bitcoin Core developer team should s=
ign a<br>
> collective note stating their desire to transition to a new economic p=
olicy,<br>
> that of "healthy fee market" and strongly urge users to exam=
ine their fee<br>
> policies, wallet software, transaction volumes and other possible User=
<br>
> 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--
|
