summaryrefslogtreecommitdiff
path: root/eb/0fb41c0fabff0209897d5bc91ba1705e674b45
blob: 9b05fdfeab59d7600758f0c81e03e2abeac54bd1 (plain)
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
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
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 56B56F41
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 18 Dec 2015 13:56:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
	[209.85.213.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F560A9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 18 Dec 2015 13:56:46 +0000 (UTC)
Received: by mail-ig0-f180.google.com with SMTP id to18so34938512igc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 18 Dec 2015 05:56:46 -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=hBC9c2CWrRz7l3842ujFw6ww41+qkHmHQrAa7VXzexg=;
	b=Pu6Pxpre7aSOe5Q8uYNcw3juA4nmg4ZfV9oyWIKNcHyK7HPgKKtTL+5b9/bsYUGyZW
	ChOaijOAMReafdd7BHQC7pwZ+4qwwHdBzL6iIhPcEc53PN07FiuDAxEzd2PHdWTdAbYT
	tWSasJUxMa+fmmET78dE/gXA3mtmvA/tGrMUFTw4nrGoqiEgj0yhqr0kXosaeMJc6n/s
	qDNACHwhCDnTXr9OXi/84dMeYkYlKvsJFp+2eM1UWMd/deBnDbRQkvOQNDOO+sNvfhAC
	Rcq9IqpeyGhjRwFsWlC6KX0NqwDa7VDM7hPZaHUp7gBS88iLtkcklNvzHT+lEbjkpY28
	qY2Q==
MIME-Version: 1.0
X-Received: by 10.50.111.193 with SMTP id ik1mr2957544igb.23.1450447005709;
	Fri, 18 Dec 2015 05:56:45 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Fri, 18 Dec 2015 05:56:45 -0800 (PST)
In-Reply-To: <CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
	<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
	<CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com>
	<CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com>
Date: Fri, 18 Dec 2015 08:56:45 -0500
Message-ID: <CADm_WcaxTmnAQR6+fejEEFB8bGQviHEE8_G5SQRygXOX1c6XSQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a9c148a7d3805272c8286
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: Fri, 18 Dec 2015 13:56:47 -0000

--047d7b3a9c148a7d3805272c8286
Content-Type: text/plain; charset=UTF-8

On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgarzik@gmail.com> wrote:
> >> 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.
> >
> > Diverging from the satoshi block size change plan[1] and current
> economics
> > would seem to require a high level of months-ahead communication to
> users.
>
> I don't see any plan, but will you say the same thing when the subsidy
>

Yes, I forgot the link:

[1] https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366



> dwindles, and mining income seems to become uncertain? It will equally
> be an economic change, which equally well will have been predictable,
> and it will equally well be treatable with a hardfork to increase the
> subsidy.
>

That is a red herring.  Nobody I know has proposed this, and I am opposed
to changing that fundamental.

It is well known that the 1M limit was never intended to stay, unlike 21M
coin limit etc.

1M was set high in the beginning because it is a DoS engineering limit, not
an [accidental] economic policy tool.




> But I am not against a block size increase hard fork. My talk on
> segregated witness even included proposed pursuing a hard fork at a
> slightly later stage.
>

Great!



> But what you're arguing for is that - despite being completely
> expected - blocks grew fuller, and people didn't adapt to block size
> pressure and a fee market, so the Core committee now needs to kick the
> can down the road, because we can't accept the risk of economic
> change. That sounds very much like a bailout to me.
>

I am arguing for continuing what we know works.  We are 100% certain
blocks-not-full-on-avg works, where a "buffer" of space exists between avg
block size and hard limit.

Any other avenue is by definition speculation and risk.  You _think_ you
know what a healthy fee market _should_ be.  Massive damage occurs to
bitcoin if you are wrong - and I listed several

vis expectation, there is clear consensus and expectation that block size
would increase, from 2010 onward.  It was always a question of _when_ not
if.

Sticking with 1M presents clear risk of (a) economic fracture and (b)
community fracture.  It quite clearly risks massive change to an unknown
system at an unknown, unpredictable date in the future.

BIP 102 presents an expected upgrade at a predictable date in the future.

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

<div dir=3D"ltr">On Fri, Dec 18, 2015 at 2:56 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><span class=3D"">On Fri, Dec 18=
, 2015 at 6:11 AM, Jeff Garzik &lt;<a href=3D"mailto:jgarzik@gmail.com">jga=
rzik@gmail.com</a>&gt; wrote:<br>
&gt;&gt; You present this as if the Bitcoin Core development team is in cha=
rge<br>
&gt;&gt; of deciding the network consensus rules, and is responsible for ma=
king<br>
&gt;&gt; changes to it in order to satisfy economic demand. If that is the<=
br>
&gt;&gt; case, Bitcoin has failed, in my opinion.<br>
&gt;<br>
&gt; Diverging from the satoshi block size change plan[1] and current econo=
mics<br>
&gt; would seem to require a high level of months-ahead communication to us=
ers.<br>
<br>
</span>I don&#39;t see any plan, but will you say the same thing when the s=
ubsidy<br></blockquote><div><br></div><div>Yes, I forgot the link:</div><di=
v><br></div><div>[1] <a href=3D"https://bitcointalk.org/index.php?topic=3D1=
347.msg15366#msg15366">https://bitcointalk.org/index.php?topic=3D1347.msg15=
366#msg15366</a></div><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">
dwindles, and mining income seems to become uncertain? It will equally<br>
be an economic change, which equally well will have been predictable,<br>
and it will equally well be treatable with a hardfork to increase the<br>
subsidy.<br></blockquote><div><br></div><div>That is a red herring.=C2=A0 N=
obody I know has proposed this, and I am opposed to changing that fundament=
al.</div><div><br></div><div>It is well known that the 1M limit was never i=
ntended to stay, unlike 21M coin limit etc.</div><div><br></div><div>1M was=
 set high in the beginning because it is a DoS engineering limit, not an [a=
ccidental] economic policy tool.</div><div><br></div><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-s=
tyle:solid;padding-left:1ex">But I am not against a block size increase har=
d fork. My talk on<br>
segregated witness even included proposed pursuing a hard fork at a<br>
slightly later stage.<br></blockquote><div><br></div><div>Great!</div><div>=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex">But what you&#39;re arguing for=
 is that - despite being completely<br>
expected - blocks grew fuller, and people didn&#39;t adapt to block size<br=
>
pressure and a fee market, so the Core committee now needs to kick the<br>
can down the road, because we can&#39;t accept the risk of economic<br>
change. That sounds very much like a bailout to me.<br></blockquote><div><b=
r></div><div>I am arguing for continuing what we know works.=C2=A0 We are 1=
00% certain blocks-not-full-on-avg works, where a &quot;buffer&quot; of spa=
ce exists between avg block size and hard limit.</div><div><br></div><div>A=
ny other avenue is by definition speculation and risk.=C2=A0 You _think_ yo=
u know what a healthy fee market _should_ be.=C2=A0 Massive damage occurs t=
o bitcoin if you are wrong - and I listed several=C2=A0<br></div><div><br><=
/div><div><div>vis expectation, there is clear consensus and expectation th=
at block size would increase, from 2010 onward.=C2=A0 It was always a quest=
ion of _when_ not if.</div><div><br></div></div><div><div>Sticking with 1M =
presents clear risk of (a) economic fracture and (b) community fracture.=C2=
=A0 It quite clearly risks massive change to an unknown system at an unknow=
n, unpredictable date in the future.<br></div><div><br></div></div><div>BIP=
 102 presents an expected upgrade at a predictable date in the future.</div=
><div><br></div><div></div></div></div><div class=3D"gmail_extra"><br></div=
></div>

--047d7b3a9c148a7d3805272c8286--