summaryrefslogtreecommitdiff
path: root/1f/47c1d290db292fdb85faf8264d03042d18dc25
blob: a6ccdebe923b50e82dc2252ef46de334b0088958 (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
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
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1YynVU-0004VH-EU
	for bitcoin-development@lists.sourceforge.net;
	Sat, 30 May 2015 20:37:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.47 as permitted sender)
	client-ip=209.85.215.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f47.google.com; 
Received: from mail-la0-f47.google.com ([209.85.215.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YynVS-00033l-DP
	for bitcoin-development@lists.sourceforge.net;
	Sat, 30 May 2015 20:37:24 +0000
Received: by laat2 with SMTP id t2so77003913laa.1
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 30 May 2015 13:37:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.72.164 with SMTP id e4mr10617750lbv.113.1433018235914;
	Sat, 30 May 2015 13:37:15 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Sat, 30 May 2015 13:37:15 -0700 (PDT)
In-Reply-To: <556A1046.50807@bluematt.me>
References: <554BE0E1.5030001@bluematt.me>
	<CABsx9T2ysKj5HVbN_7_o33fMehs4KH6E_R583Mt_VPC4gDA0LQ@mail.gmail.com>
	<5568F567.3050608@bluematt.me>
	<CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
	<556A1046.50807@bluematt.me>
Date: Sat, 30 May 2015 16:37:15 -0400
Message-ID: <CABsx9T3qPiQ+PL3ZNT+QJzw4ALEzKjMjC4=uEKTG+4vVPdXr-g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=001a11c2b616e8919a0517528e30
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gavinandresen[at]gmail.com)
	-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: 1YynVS-00033l-DP
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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: Sat, 30 May 2015 20:37:24 -0000

--001a11c2b616e8919a0517528e30
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, May 30, 2015 at 3:32 PM, Matt Corallo <bitcoin-list@bluematt.me>
wrote:

> If, for example, the majority of miners are in China (they are), and
> there is really poor connectivity in and out of China (there is) and a
> miner naively optimizes for profit, they will create blocks which are
> large and take a while to relay out of China. By simple trial-and-error
> an individual large miner might notice that when they create larger
> blocks which fork off miners in other parts of the world, they get more
> income. Obviously forking off 50% of the network would be a rather
> extreme situation and assumes all kinds of simplified models, but it
> shows that the incentives here are very far from aligned, and your
> simplified good-behavior models are very far from convincing.
>

"good behavior" models? I intentionally modeled what should be a worst-case=
.

If you have a specific network topology you want to model, please email me
details and I'll see what worst case is. Or, even better, take my
simulation code and run it yourself (it's C++, easy to compile, easy to
modify if you think it is too simple).

I get frustrated with all of the armchair "but what if..."
how-many-miners-can-dance-on-the-head-of-a-pin arguments.



> >     I'll talk about transaction fees in a second, but there are several
> >     problems with this already. As pointed out in the original mail, gf=
w
> has
> >     already been known to interfere with Bitcoin P2P traffic. So now by
> >     "little" miners, you mean any miner who is not located in mainland
> >     China? Whats worse, the disadvantage is symmetric - little miners
> are at
> >     a disadvantage when *anyone* mines a bigger block


No, they're not. They are only at a disadvantage when THEY mine bigger
blocks.

I guess I wasn't clear in the "do bigger miners have an advantage" blog
post.


> ... I mentioned this in my
> original email as something which doesnt make me comfortable with 20MB
> blocks, but something which needs simulation and study, and might
> actually be just fine!
>

I spent last week doing simulation and study. Please, do your own
simulation and study if you don't trust my results. There are big
full-scale-bitcoin-network-simulations spinning up that should have results
in a month or two, also, but there will ALWAYS be "but we didn't think
about what if THIS happens" scenarios that can require more simulation and
study.


>
> > Do you have another explanation for why miners choose to leave
> > fee-paying transactions in their mempool and create small blocks?
>
> Defaults? Dumb designs? Most miners just use the default 750K blocks, as
> far as I can tell, other miners probably didnt see transactions relayed
> across several hops or so, and a select few miners are doing crazy
> things like making their blocks fit in a single packet to cross the gfw,
> but that is probably overkill and not well-researched.
>

Last night's transaction volume test shows that most miners do just go
along with defaults:
  http://bitcoincore.org/~gavin/sizes_358594.html

> I'm not suggesting that we increase the blocksize sufficiently such that
> > transaction fees are not the way in which miners make their money.
> >
> > I'm suggesting the blocksize be increased to 20MB (and then doubled
> > every couple of years).
>
> Do you have convincing evidence that at 20MB miners will be able to
> break even on transaction fees for a long time? (The answer is no
> because no one has any idea how bitcoin transaction volumes are going to
> scale, period.)
>


Mining is a competitive business, the marginal miner will ALWAYS be going
out of business.

That is completely independent of the block size, block subsidy, or
transaction fees.

The question is "will there be enough fee+subsidy revenue to make it
unprofitable for an attacker to buy or rent enough hashpower to
double-spend."

It is obvious to me that bigger blocks make it more likely the answer to
that question is "yes."



>
> > And "in which miners make their money" is the wrong metric-- we want
> > enough mining so the network to be "secure enough" against double-spend=
s.
>
> Sure, do you have a value of hashpower which is "secure enough" (which
> is a whole other rabbit hole to go down...).
>

Mike Hearn wrote about that just a couple days ago:
  https://medium.com/@octskyward/hashing-7d04a887acc8
(See "How much is too much" section)


> > Even if we end up in a world where only big companies can run full node=
s
> > (and I am NOT NOT NOT NOT NOT proposing any such thing), there is a
> > difference-- you don't need permission to "open up a bank" on the
> > Bitcoin network.
> >
>
> Oh? You mention at http://gavinandresen.ninja/bigger-blocks-another-way
> that "I struggle with wanting to stay true to Satoshi=E2=80=99s original =
vision
> of Bitcoin as a system that scales up to Visa-level transaction volume".
> That is in direct contradiction.
>

I have said repeatedly that if it was left completely up to me I would go
back to Satoshi's original "there is no consensus-level blocksize limit".

20MB is a compromise.

 > Ok, I wrote about that here:

> >
> > http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
> >
>
> "it is not a panacea", but everyone in the community seems to be taking
> it as one. You've claimed many times that many of the big
> webwallet/payment processors/etc have been coming to you and saying they
> need bigger block sizes to continue operating. In reality, they dont, it
> just makes it easier
>
>
... and now you're pissing me off. I have NEVER EVER said that they need
bigger blocks to continue operating. Please stop being overly dramatic.

They believe that bigger blocks are better for Bitcoin.

Brian Armstrong at Coinbase, in particular, said that smaller blocks drive
centralization towards services like Coinbase ("look ma! No blockchain
transaction!" <-- if you pay a Coinbase merchant from your Coinbase
wallet), but he supports bigger blocks because more transactions on our
existing decentralized network is better.

--=20
--
Gavin Andresen

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, May 30, 2015 at 3:32 PM, Matt Corallo <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bitcoin-list@bluematt.me" target=3D"_blank">bitcoin-list@bluematt.me=
</a>&gt;</span> wrote:<br><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">If, for example, the majority of=
 miners are in China (they are), and<br>
there is really poor connectivity in and out of China (there is) and a<br>
miner naively optimizes for profit, they will create blocks which are<br>
large and take a while to relay out of China. By simple trial-and-error<br>
an individual large miner might notice that when they create larger<br>
blocks which fork off miners in other parts of the world, they get more<br>
income. Obviously forking off 50% of the network would be a rather<br>
extreme situation and assumes all kinds of simplified models, but it<br>
shows that the incentives here are very far from aligned, and your<br>
simplified good-behavior models are very far from convincing.<br></blockquo=
te><div><br></div><div>&quot;good behavior&quot; models? I intentionally mo=
deled what should be a worst-case.</div><div><br></div><div>If you have a s=
pecific network topology you want to model, please email me details and I&#=
39;ll see what worst case is. Or, even better, take my simulation code and =
run it yourself (it&#39;s C++, easy to compile, easy to modify if you think=
 it is too simple).</div><div><br></div><div>I get frustrated with all of t=
he armchair &quot;but what if...&quot; how-many-miners-can-dance-on-the-hea=
d-of-a-pin arguments.</div><div><br></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><span class=3D"">
&gt;=C2=A0 =C2=A0 =C2=A0I&#39;ll talk about transaction fees in a second, b=
ut there are several<br>
&gt;=C2=A0 =C2=A0 =C2=A0problems with this already. As pointed out in the o=
riginal mail, gfw has<br>
&gt;=C2=A0 =C2=A0 =C2=A0already been known to interfere with Bitcoin P2P tr=
affic. So now by<br>
&gt;=C2=A0 =C2=A0 =C2=A0&quot;little&quot; miners, you mean any miner who i=
s not located in mainland<br>
&gt;=C2=A0 =C2=A0 =C2=A0China? Whats worse, the disadvantage is symmetric -=
 little miners are at<br>
&gt;=C2=A0 =C2=A0 =C2=A0a disadvantage when *anyone* mines a bigger block</=
span></blockquote><div><br></div><div>No, they&#39;re not. They are only at=
 a disadvantage when THEY mine bigger blocks.</div><div><br></div><div>I gu=
ess I wasn&#39;t clear in the &quot;do bigger miners have an advantage&quot=
; blog post.</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(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">...</=
span>=C2=A0I mentioned this in my<br>
original email as something which doesnt make me comfortable with 20MB<br>
blocks, but something which needs simulation and study, and might<br>
actually be just fine!<span class=3D""><br></span></blockquote><div><br></d=
iv><div>I spent last week doing simulation and study. Please, do your own s=
imulation and study if you don&#39;t trust my results. There are big full-s=
cale-bitcoin-network-simulations spinning up that should have results in a =
month or two, also, but there will ALWAYS be &quot;but we didn&#39;t think =
about what if THIS happens&quot; scenarios that can require more simulation=
 and study.</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(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D""><br>
&gt; Do you have another explanation for why miners choose to leave<br>
&gt; fee-paying transactions in their mempool and create small blocks?<br>
<br>
</span>Defaults? Dumb designs? Most miners just use the default 750K blocks=
, as<br>
far as I can tell, other miners probably didnt see transactions relayed<br>
across several hops or so, and a select few miners are doing crazy<br>
things like making their blocks fit in a single packet to cross the gfw,<br=
>
but that is probably overkill and not well-researched.<br></blockquote><div=
><br></div><div>Last night&#39;s transaction volume test shows that most mi=
ners do just go along with defaults:</div><div>=C2=A0=C2=A0<a href=3D"http:=
//bitcoincore.org/~gavin/sizes_358594.html">http://bitcoincore.org/~gavin/s=
izes_358594.html</a></div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">=
&gt; I&#39;m not suggesting that we increase the blocksize sufficiently suc=
h that<br>
&gt; transaction fees are not the way in which miners make their money.<br>
&gt;<br>
&gt; I&#39;m suggesting the blocksize be increased to 20MB (and then double=
d<br>
&gt; every couple of years).<br>
<br>
</span>Do you have convincing evidence that at 20MB miners will be able to<=
br>
break even on transaction fees for a long time? (The answer is no<br>
because no one has any idea how bitcoin transaction volumes are going to<br=
>
scale, period.)<br></blockquote><div><br></div><div><br></div><div>Mining i=
s a competitive business, the marginal miner will ALWAYS be going out of bu=
siness.<br></div><div><br></div><div>That is completely independent of the =
block size, block subsidy, or transaction fees.</div><div><br></div><div>Th=
e question is &quot;will there be enough fee+subsidy revenue to make it unp=
rofitable for an attacker to buy or rent enough hashpower to double-spend.&=
quot;</div><div><br></div><div>It is obvious to me that bigger blocks make =
it more likely the answer to that question is &quot;yes.&quot;</div><div><b=
r></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">
<span class=3D""><br>
&gt; And &quot;in which miners make their money&quot; is the wrong metric--=
 we want<br>
&gt; enough mining so the network to be &quot;secure enough&quot; against d=
ouble-spends.<br>
<br>
</span>Sure, do you have a value of hashpower which is &quot;secure enough&=
quot; (which<br>
is a whole other rabbit hole to go down...).<br></blockquote><div><br></div=
><div>Mike Hearn wrote about that just a couple days ago:</div><div>=C2=A0=
=C2=A0<a href=3D"https://medium.com/@octskyward/hashing-7d04a887acc8">https=
://medium.com/@octskyward/hashing-7d04a887acc8</a></div><div>(See &quot;How=
 much is too much&quot; section)</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><sp=
an class=3D"">&gt; Even if we end up in a world where only big companies ca=
n run full nodes<br>
&gt; (and I am NOT NOT NOT NOT NOT proposing any such thing), there is a<br=
>
&gt; difference-- you don&#39;t need permission to &quot;open up a bank&quo=
t; on the<br>
&gt; Bitcoin network.<br>
&gt;<br>
<br>
</span>Oh? You mention at <a href=3D"http://gavinandresen.ninja/bigger-bloc=
ks-another-way" target=3D"_blank">http://gavinandresen.ninja/bigger-blocks-=
another-way</a><br>
that &quot;I struggle with wanting to stay true to Satoshi=E2=80=99s origin=
al vision<br>
of Bitcoin as a system that scales up to Visa-level transaction volume&quot=
;.<br>
That is in direct contradiction.<br></blockquote><div><br></div><div>I have=
 said repeatedly that if it was left completely up to me I would go back to=
 Satoshi&#39;s original &quot;there is no consensus-level blocksize limit&q=
uot;.</div><div><br></div><div>20MB is a compromise.</div><div><br></div><d=
iv>=C2=A0&gt; Ok, I wrote about that here:</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"><span clas=
s=3D"">
&gt;<br>
&gt; <a href=3D"http://gavinandresen.ninja/it-must-be-done-but-is-not-a-pan=
acea" target=3D"_blank">http://gavinandresen.ninja/it-must-be-done-but-is-n=
ot-a-panacea</a><br>
&gt;<br>
<br>
</span>&quot;it is not a panacea&quot;, but everyone in the community seems=
 to be taking<br>
it as one. You&#39;ve claimed many times that many of the big<br>
webwallet/payment processors/etc have been coming to you and saying they<br=
>
need bigger block sizes to continue operating. In reality, they dont, it<br=
>
just makes it easier<br><br></blockquote><div>=C2=A0</div></div>... and now=
 you&#39;re pissing me off. I have NEVER EVER said that they need bigger bl=
ocks to continue operating. Please stop being overly dramatic.</div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">They believe that =
bigger blocks are better for Bitcoin.</div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">Brian Armstrong at Coinbase, in particular,=
 said that smaller blocks drive centralization towards services like Coinba=
se (&quot;look ma! No blockchain transaction!&quot; &lt;-- if you pay a Coi=
nbase merchant from your Coinbase wallet), but he supports bigger blocks be=
cause more transactions on our existing decentralized network is better.<br=
 clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature">--<br>G=
avin Andresen<br></div>
</div></div>

--001a11c2b616e8919a0517528e30--