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
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1Z4K8U-0003jB-51
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 02:28:30 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.218.42 as permitted sender)
client-ip=209.85.218.42; envelope-from=jgarzik@bitpay.com;
helo=mail-oi0-f42.google.com;
Received: from mail-oi0-f42.google.com ([209.85.218.42])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4K8S-0004oB-8N
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 02:28:30 +0000
Received: by oial131 with SMTP id l131so16947112oia.3
for <bitcoin-development@lists.sourceforge.net>;
Sun, 14 Jun 2015 19:28:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=cTJ5kZBJeDDoeM1gBKdfuVj0AZtlokcnYXQfui/KjD0=;
b=K2YK6OcVudVVzjYtL+sy18Wwk9CDiaT9j19jM495U9QysT+6cmD98QwMNJyHetmlSh
V4wTrmt1Dkb3/LmjmoAZfFmjVbcoTkEORG/ivoRteoIvAq/rtHkqLvmc5Z+KJYh4rvq/
4jdrPs120AlgrJn98G6MUwcN1I0MKbSbJpCmSRgoKbhUScfxECleXQ889i/9ANosakVD
XYYN3iQNx9PNp2cn20o1AV5mlCs6oB5Zc7R4m1bpNqYBrLoi7dB11TiVAYyb1QlhNDu2
cTdT8uJLhQmq1OuAbyVcx0dAM3EjMHoceaoncZmt1SaE7y6ROUbtNnfKeInkHF98C90F
wgSw==
X-Gm-Message-State: ALoCoQk0SugxfYHoCzCZsFqjHV9G5mov5GaliJDZT/gsSd2uZtFjQkeppfxv+OrO+IsWNfjOYuoa
X-Received: by 10.182.87.36 with SMTP id u4mr21697917obz.50.1434335302760;
Sun, 14 Jun 2015 19:28:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.108.149 with HTTP; Sun, 14 Jun 2015 19:28:02 -0700 (PDT)
In-Reply-To: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Sun, 14 Jun 2015 22:28:02 -0400
Message-ID: <CAJHLa0Mj7kAz4=yrZo=+nvoV97rF_xAvHGt+A3D2qE3P16zKBw@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=089e013d0ddc35d1e9051885362b
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z4K8S-0004oB-8N
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 02:28:30 -0000
--089e013d0ddc35d1e9051885362b
Content-Type: text/plain; charset=UTF-8
On Sun, Jun 14, 2015 at 5:23 PM, Adam Back <adam@cypherspace.org> wrote:
> Hi
>
> I made these comments elsewhere, but I think really we should be
> having these kind of conversations here rather than scattered around.
>
> These are about Jeff Garzik's outline draft BIP 100 I guess this is
> the latest draft: (One good thing about getting off SF would be
> finally JGarzik's emails actually not getting blocked!).
>
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>
> may have changed since the original [1]
>
> Over the original proposal:
>
> 1. there should be a hard cap, not indefinitely growing.
>
>
In the latest draft there is an explicit 32MB ceiling now.
Users will need to opt into growth beyond 32MB via a 2nd hard fork.
> 2. there should be a growth limiter (no more than X%/year)
>
>
As a general principle, this is an area of market disagreement, and should
not be our call. Encoding this into software veers into personal opinion
about what economic policy should be.
That said -- BIP 100, as a compromise, includes a growth limiter. Abrupt
change (1MB -> 32MB!) is awful on markets. Good policies include a
measured pace of transition from policy A to policy B. It gives the
community time to assess system effectiveness - while also allowing free
market input.
In the long run I hope the cap is removed (see below), and the intention is
to -slowly- and -transparently- move from the tightly controlled limit to
something the free market and users are choosing.
> 3. I think the miners should not be given a vote that has no costs to
> cast, because their interests are not necessarily aligned with users
> or businesses.
>
> I think Greg Maxwell's difficulty adjust [2] is better here for that
> reason. It puts quadratic cost via higher difficulty for miners to
> vote to increase block-size, which miners can profitably do if there
> are transactions with fees available to justify it. There is also the
> growth limiter as part of Greg's proposal. [3]
>
>
"paying with difficulty" has severe negative elements that will likely
cause it never to be used:
- complex and difficult for miners to reason
- fails the opportunity cost test - dollar cost lost losing the block race
versus value gained by increasing block size
- inherently unpredictable in the short term - user experience is that it's
possibly difficult to see a gain in utility versus the revenue you are
giving up
- REQUIRES informal miner collusion - probably less transparent than BIP
100 - in order to solve the who-goes-first problem.
- net result: tough sell
Paying bitcoins to future miners makes a lot more sense. Initially I was a
fan of pay-with-diff, but freezing bitcoins (CLTV) or timelock'd
anyone-can-spend has much more clear incentives, if you want to go down
that road.
Problems with pay-to-increase-block-size:
- how much to pay? You are inherently setting your growth policy on top of
bitcoin by choosing a price here.
- another who-goes-first problem
Anyway, there is a natural equilibrium block size that the free market and
user choice will seek.
Related: There is a lot of naive "miner = max income = max block size"
reasoning going on, with regards to fees. This is defining the bounds of
an economically scarce resource. There are many reasons why a miner will
today, in the real world, limit their block size. WRT fee income, if block
size is too large the fee competition in the overall market is low-to-zero,
fee income rapidly collapses. Then factor in price and demand elasticity
on top of that.
Quite frankly, there seems to be a natural block size equilibrium ceiling,
and I worry about miners squeezing the market by maximizing their fee
income through constrained block sizes and competition at the low end.
This is of course already possible today - miners may openly or covertly
collude to keep the block size low.
> I think bitcoin will have to involve layering models that uplift
> security to higher layers, but preserve security assurances, and
> smart-contracts even, with protocols that improve the algorithmic
> complexity beyond O(n^2) in users, like lightning, and there are
> multiple other candidates with useful tradeoffs for various use-cases.
>
> One thing that is concerning is that few in industry seem inclined to
> take any development initiatives or even integrate a library. I
> suppose eventually that problem would self-correct as new startups
> would make a more scalable wallet and services that are layer2 aware
> and eat the lunch of the laggards. But it will be helpful if we
> expose companies to the back-pressure actually implied by an O(n^2)
> scaling protocol and don't just immediately increase the block-size to
> levels that are dangerous for decentralisation security, as an
> interventionist subsidy to save them having to do basic integration
> work. Otherwise I think whichever any kind of kick the can some 2-5
> years down the road we consider, we risk the whole saga repeating in a
> few years, when no algorithmic progress has been made and even more
> protocol inertia has set in.
>
> Adam
>
> [1] original proposal comments on reddit
>
> https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/
>
> [2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach
>
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html
>
> [3] growth limited proposal for flexcap by Greg Maxwell
>
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--089e013d0ddc35d1e9051885362b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Jun 14, 2015 at 5:23 PM, Adam Back <span dir=3D"lt=
r"><<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cyphe=
rspace.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
I made these comments elsewhere, but I think really we should be<br>
having these kind of conversations here rather than scattered around.<br>
<br>
These are about Jeff Garzik's outline draft BIP 100 I guess this is<br>
the latest draft:=C2=A0 (One good thing about getting off SF would be<br>
finally JGarzik's emails actually not getting blocked!).<br>
<br>
<a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf=
" rel=3D"noreferrer" target=3D"_blank">http://gtf.org/garzik/bitcoin/BIP100=
-blocksizechangeproposal.pdf</a><br>
<br>
may have changed since the original [1]<br>
<br>
Over the original proposal:<br>
<br>
1. there should be a hard cap, not indefinitely growing.<br>
<br></blockquote><div><br></div><div>In the latest draft there is an explic=
it 32MB ceiling now.</div><div><br></div><div>Users will need to opt into g=
rowth beyond 32MB via a 2nd hard fork.</div><div><br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
2. there should be=C2=A0 a growth limiter (no more than X%/year)<br>
<br></blockquote><div><br></div><div>As a general principle, this is an are=
a of market disagreement, and should not be our call.=C2=A0 Encoding this i=
nto software veers into personal opinion about what economic policy should =
be.</div><div><br></div><div>That said =C2=A0-- BIP 100, as a compromise, i=
ncludes a growth limiter.=C2=A0 Abrupt change (1MB -> 32MB!) is awful on=
markets.=C2=A0 Good policies include a measured pace of transition from po=
licy A to policy B.=C2=A0 It gives the community time to assess system effe=
ctiveness - while also allowing free market input.</div><div><br></div><div=
>In the long run I hope the cap is removed (see below), and the intention i=
s to -slowly- and -transparently- move from the tightly controlled limit to=
something the free market and users are choosing.</div><div><br></div><div=
><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. I think the miners should not be given a vote that has no costs to<br>
cast, because their interests are not necessarily aligned with users<br>
or businesses.<br>
<br>
I think Greg Maxwell's difficulty adjust [2] is better here for that<br=
>
reason.=C2=A0 It puts quadratic cost via higher difficulty for miners to<br=
>
vote to increase block-size, which miners can profitably do if there<br>
are transactions with fees available to justify it. There is also the<br>
growth limiter as part of Greg's proposal. [3]<br>
<br></blockquote><div><br></div><div>"paying with difficulty" has=
severe negative elements that will likely cause it never to be used:</div>=
<div>- complex and difficult for miners to reason</div><div>- fails the opp=
ortunity cost test - dollar cost lost losing the block race versus value ga=
ined by increasing block size</div><div>- inherently unpredictable in the s=
hort term - user experience is that it's possibly difficult to see a ga=
in in utility versus the revenue you are giving up</div><div>- REQUIRES inf=
ormal miner collusion - probably less transparent than BIP 100 - in order t=
o solve the who-goes-first problem.</div><div>- net result: tough sell</div=
><div><br></div><div>Paying bitcoins to future miners makes a lot more sens=
e.=C2=A0 Initially I was a fan of pay-with-diff, but freezing bitcoins (CLT=
V) or timelock'd anyone-can-spend has much more clear incentives, if yo=
u want to go down that road.</div><div><br></div><div>Problems with pay-to-=
increase-block-size:</div><div>- how much to pay?=C2=A0 You are inherently =
setting your growth policy on top of bitcoin by choosing a price here.</div=
><div>- another who-goes-first problem</div><div><br></div><div>Anyway, the=
re is a natural equilibrium block size that the free market and user choice=
will seek.</div><div><br></div><div>Related: =C2=A0There is a lot of naive=
"miner =3D max income =3D max block size" reasoning going on, wi=
th regards to fees.=C2=A0 This is defining the bounds of an economically sc=
arce resource.=C2=A0 There are many reasons why a miner will today, in the =
real world, limit their block size. WRT fee income, if block size is too la=
rge the fee competition in the overall market is low-to-zero, fee income ra=
pidly collapses.=C2=A0 Then factor in price and demand elasticity on top of=
that.</div><div><br></div><div>Quite frankly, there seems to be a natural =
block size equilibrium ceiling, and I worry about miners squeezing the mark=
et by maximizing their fee income through constrained block sizes and compe=
tition at the low end.=C2=A0 This is of course already possible today - min=
ers may openly or covertly collude to keep the block size low.</div><div><b=
r></div><div><br></div><div><br></div><div><br></div><div><br></div><div><b=
r></div><div><br></div><div><br></div><div><br></div><div><br></div><div><b=
r></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think bitcoin will have to involve layering models that uplift<br>
security to higher layers, but preserve security assurances, and<br>
smart-contracts even, with protocols that improve the algorithmic<br>
complexity beyond O(n^2) in users, like lightning, and there are<br>
multiple other candidates with useful tradeoffs for various use-cases.<br>
<br>
One thing that is concerning is that few in industry seem inclined to<br>
take any development initiatives or even integrate a library.=C2=A0 I<br>
suppose eventually that problem would self-correct as new startups<br>
would make a more scalable wallet and services that are layer2 aware<br>
and eat the lunch of the laggards.=C2=A0 But it will be helpful if we<br>
expose companies to the back-pressure actually implied by an O(n^2)<br>
scaling protocol and don't just immediately increase the block-size to<=
br>
levels that are dangerous for decentralisation security, as an<br>
interventionist subsidy to save them having to do basic integration<br>
work.=C2=A0 Otherwise I think whichever any kind of kick the can some 2-5<b=
r>
years down the road we consider, we risk the whole saga repeating in a<br>
few years, when no algorithmic progress has been made and even more<br>
protocol inertia has set in.<br>
<br>
Adam<br>
<br>
[1] original proposal comments on reddit<br>
<a href=3D"https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_s=
oft_fork_block_size_increase/" rel=3D"noreferrer" target=3D"_blank">https:/=
/www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_siz=
e_increase/</a><br>
<br>
[2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach<br>
<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourcefor=
ge.net/msg07599.html" rel=3D"noreferrer" target=3D"_blank">https://www.mail=
-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html</a><br=
>
<br>
[3] growth limited proposal for flexcap by Greg Maxwell<br>
<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourcefor=
ge.net/msg07620.html" rel=3D"noreferrer" target=3D"_blank">https://www.mail=
-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html</a><br=
>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature">Jeff Garzik<br>Bitcoin core developer and open source =
evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.co=
m/" target=3D"_blank">https://bitpay.com/</a></div>
</div></div>
--089e013d0ddc35d1e9051885362b--
|