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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
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 BD3DDACB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 18:05:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
[209.85.212.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A7898196
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 18:05:31 +0000 (UTC)
Received: by wicgi11 with SMTP id gi11so24484775wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 11:05:30 -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=FYVF0Uq/Eo5OMf06/D8UJeQp8MV5Jafgq2WG1iOAzIw=;
b=P8Mpq+Yxv7JQhZW4N8uGJWWi+rdvmUqaJvFJqcKv4iUOXz1CAHyRR1/AwuyF5PLKig
RAk4Gp4hDB8Jh01I9XbdsV6Z9j7k0cPdYHHiHEZoAEjvybA2sDJN/c2nvYLtv4HszgGh
Pc4oWt7u2WsAFzd9VEcCEZP1cXEys7XP+i6jVNRp2TJiAF6w+uN1Ec0Ttu07eRrhrybg
S7jbQIJsKZzLRP+gk8metzm01qL33WfeJWciwB/JzEJYAd00PGXUOpCEvx47UViYtIbw
gyjMTaRPooVWqsEYxRrzW+y7D3m0aAuhoUmXq+TvPYy1pKadbcEIyE1RPxjPjrsBISaM
dOoQ==
MIME-Version: 1.0
X-Received: by 10.180.228.6 with SMTP id se6mr6891991wic.33.1435341930482;
Fri, 26 Jun 2015 11:05:30 -0700 (PDT)
Received: by 10.28.140.196 with HTTP; Fri, 26 Jun 2015 11:05:30 -0700 (PDT)
In-Reply-To: <CAPg+sBiPH_j+FJRuvBG6yWbPkC8-4gnC3UrJgw15apfB+DBxAw@mail.gmail.com>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
<558D6E26.4000004@bitcoins.info>
<CAPg+sBiPH_j+FJRuvBG6yWbPkC8-4gnC3UrJgw15apfB+DBxAw@mail.gmail.com>
Date: Fri, 26 Jun 2015 11:05:30 -0700
Message-ID: <CADm_WcYKkrPO-9tiz8d2FFeLk4K7gSgVJG+4PXysi+n8LtXkYw@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a1135e398e5d24005196f95a8
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 18:05:32 -0000
--001a1135e398e5d24005196f95a8
Content-Type: text/plain; charset=UTF-8
On Fri, Jun 26, 2015 at 8:24 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> On Fri, Jun 26, 2015 at 5:22 PM, Milly Bitcoin <milly@bitcoins.info>
> wrote:
>
>> >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...
>>
>> Yes. I think people/businesses want some kind of assurance that there is
>> a path to get things done when needed rather than immediate changes. Since
>> there is currently no clear path/schedule to get any changes accomplished
>> they gets anxious.
>>
>
> I think you just proved my point by saying "when needed".
>
Proposing inaction is not the way you convince people that bitcoin can
scale.
People and businesses cannot perform any capacity planning and future
projections under the proposal of "economic change through inaction."
There will be no growth, by your argument, until there is fee pressure.
And what happens then?
a) Block size limit increases, disrupting and rebooting the fee market.
or
b) You argue that fees have taken care of the capacity.
Waiting until blocks are full before taking action produces even more
disruption and market-unpredictable behavior than today.
I understand you want a fee market to develop, and increasing the block
size limit retards/prevents that. The fact remains that that is a _major_
change to economic policy that creates a _more_ unpredictable system.
Who knows when Pieter will agree that a fee market is healthy? And at that
time, once blocks are full, changing the block size limit then will produce
even more disruption, going from
little pressure -> lots of pressure -> little pressure
Inaction produces fee pressure produces volatility. And makes it more
difficult for system users to perform capacity planning.
I see a lot of microscopic fee analysis - economically insignificant for at
least 12 months to come - and very little holistic analysis from people
arguing that inaction is the best course.
--001a1135e398e5d24005196f95a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jun 26, 2015 at 8:24 AM, 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"><div dir=3D"ltr">=
<span class=3D"">On Fri, Jun 26, 2015 at 5:22 PM, Milly Bitcoin <span dir=
=3D"ltr"><<a href=3D"mailto:milly@bitcoins.info" target=3D"_blank">milly=
@bitcoins.info</a>></span> wrote:<br></span><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
span>>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...<br>
<br></span>
Yes.=C2=A0 I think people/businesses want some kind of assurance that there=
is a path to get things done when needed rather than immediate changes.=C2=
=A0 Since there is currently no clear path/schedule to get any changes acco=
mplished they gets anxious.<br></blockquote><div><br></div></span><div>I th=
ink you just proved my point by saying "when needed".<span class=
=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div></div></div></d=
iv></blockquote><div><br></div><div>Proposing inaction is not the way you c=
onvince people that bitcoin can scale.</div><div><br></div><div>People and =
businesses cannot perform any capacity planning and future projections unde=
r the proposal of "economic change through inaction."</div><div><=
br></div><div>There will be no growth, by your argument, until there is fee=
pressure.=C2=A0 And what happens then?</div><div><br></div><div>a) Block s=
ize limit increases, disrupting and rebooting the fee market.</div><div>=C2=
=A0 =C2=A0 =C2=A0 or</div><div>b) You argue that fees have taken care of th=
e capacity.</div><div><br></div><div>Waiting until blocks are full before t=
aking action produces even more disruption and market-unpredictable behavio=
r than today.</div><div><br></div><div>I understand you want a fee market t=
o develop, and increasing the block size limit retards/prevents that.=C2=A0=
The fact remains that that is a _major_ change to economic policy that cre=
ates a _more_ unpredictable system.</div><div><br></div><div>Who knows when=
Pieter will agree that a fee market is healthy?=C2=A0 And at that time, on=
ce blocks are full, changing the block size limit then will produce even mo=
re disruption, going from</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 little pressure -> lots of pressure -> little press=
ure</div><div><br></div><div>Inaction produces fee pressure produces volati=
lity.=C2=A0 And makes it more difficult for system users to perform capacit=
y planning.</div><div><br></div><div>I see a lot of microscopic fee analysi=
s - economically insignificant for at least 12 months to come - and very li=
ttle holistic analysis from people arguing that inaction is the best course=
.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br=
></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br=
></div><div><br></div></div></div></div>
--001a1135e398e5d24005196f95a8--
|
