summaryrefslogtreecommitdiff
path: root/c9/af1e63387dc2c348e8f208f0a114619654b157
blob: af972ff858cdd9a7e15697d89a85efd066f3e595 (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
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 81066B73
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 21:42:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
	[209.85.213.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 329D7106
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 21:42:33 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id s68so70869660vke.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 14:42:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=C3Fti1YEZakq95NUxELikPyhpE2RiH5Bgp+cqs2VTNw=;
	b=bY9DgjkAgOYkifpvWH0j0HAzhDnpj4qJzqWidt986rhft9l0M7DYxG9tM1Cm7Tu4gt
	MhHQidhkSqwcQS69v/HTy7Oc2rfm31LsnZDM5Mg4BFVhk72yt5YxihXC59IWfLYHEX/h
	t1XS61CRVAndwcz2c0PVu0huyvOWxhD9pce9dR2uB/DrsO13YYqCGM5wcqR2pdCiqbAx
	pfCADLRcxLYbXl4GT1E5dVcyFW/RDIqRUzx9g+zgfbAPtv+rohrDd4SnEPQ9CgRPY1JL
	vmvV4g23QkeH5Zdpg/cX9vZfn9ZVowe2my76BSQKJa+F9Q0zrLT55iCwF91ZTcarF9H8
	RrVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=C3Fti1YEZakq95NUxELikPyhpE2RiH5Bgp+cqs2VTNw=;
	b=Cyx31Hu7djF90j/5JLlpn3jfMzZgIa+r0w1K3/h6xiz0qVUXXVOjDYtQxdtjAHn349
	r9OAowMRv4qY0dNB//8aCy5f1easHH1tt8t7RoPd9RBWh0G39Py6DEaDNV48JUC9cJSV
	L/Gt+83/s+QKWlN4Hhx5dV2Ctd/ExLgOszTBftfdVYJDjT7vs7iP4ISKghfZ5ryHWrHD
	Bkysw/9PXCC8gj/VUPcUrsTbOelJqaEKZbKxc2nxpYOygPW6fW4/tRdKb45Gi3wEanui
	dkjnGyItIkfN/hQDYf/0+b/FWz1n6jffrm/7P3ZZXdldnhD/0QOXUqZWlrvybTwzLOIf
	g1XA==
X-Gm-Message-State: AFeK/H2CgB4TePW32uZn+wm+vNjbTEOSQSYBdIgLak86JH17nfKqrlh3or+Jx3rF131qrhSovR9sjcRpkHyP8A==
X-Received: by 10.176.84.209 with SMTP id q17mr1084013uaa.129.1490910152070;
	Thu, 30 Mar 2017 14:42:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Thu, 30 Mar 2017 14:42:31 -0700 (PDT)
In-Reply-To: <CAFVRnypMev625j6htvpC+xJo3y5VgWednOBaRhqtuiMKKNPFsw@mail.gmail.com>
References: <CY4PR18MB135053B235C734A3D8D9C13BCD350@CY4PR18MB1350.namprd18.prod.outlook.com>
	<42619430.6XQoorDgjR@strawberry>
	<CAFVRnypMev625j6htvpC+xJo3y5VgWednOBaRhqtuiMKKNPFsw@mail.gmail.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Thu, 30 Mar 2017 14:42:31 -0700
Message-ID: <CAD1TkXtHpb+aZhYufLRhDAy9=K9H+DZdDjounPubUuR9idVT3w@mail.gmail.com>
To: David Vorick <david.vorick@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f403045e20e201a066054bf9925b
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 30 Mar 2017 22:03:55 +0000
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Thu, 30 Mar 2017 21:42:34 -0000

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

> There have been attacks demonstrated where a malicious miner with
sufficient hashrate can leverage large blocks to exacerbate selfish mining.

Can you give me a link to this?  Having done a lot of mining, I really
really doubt this.  I'm assuming the theory relies upon propagation times
and focuses on small miners versus large ones, but that's wrong.
Propagation times don't affect small miners disproportionately, though they
might affect small POOLS disproportionately, that isn't the same thing at
all.  No miner since at least 2014 has operated a full node directly with
each miner - it is incredibly impractical to do so.  They retrieve only the
merkle root hash and other parameters from the stratum server, which is a
very small packet and does not increase with the size of the blocks.  If
they really want to select which transactions to include, some pools offer
options of that sort(or can, I believe) but almost no one does.  If they
don't like how their pool picks transactions, they'll use a different pool,
that simple.

If there's some other theory about a miner exploiting higher blocksizes
selfishly then I'd love to read up on it to understand it.  If what
you/others actually meant by that was smaller "pools," that's a much much
smaller problem.  Pools don't earn major profits and generally are at the
mercy of their miners if they make bad choices or can't fix low
performance.  For pools, block propagation time was a major major issue
even before blocks were full, and latency + packet loss between mining
units and the pool is also a big concern.  I was seeing occasional block
propagation delays(over a minute) on a fiber connection in 2013/4 due to
minute differences in peering.  If a pool can't afford enough bandwidth to
keep propagation times down, they can't be a pool.  Bigger blocksizes will
make it so they even more totally-can't-be-a-pool, but they already can't
be a pool, so who cares.  Plus, compact blocks should have already solve
nearly all of this problem as I understand it.

So definitely want to know more if I'm misunderstanding the attack vector.

> We already know that large empty blocks (rather, blocks with fake
transactions) can be leveraged in ways that both damages the network and
increases miner profits.

Maybe you're meaning an attack where other pools get stuck on validation
due to processing issues?  This is also a nonissue.  The smallest viable
pool has enough difficulties with other, non-hardware related issues that
buying the largest, beefiest standard processor available with ample RAM
won't even come up on the radar.  No one cares about $600 in hardware
versus $1000 in hardware when it takes you 6 weeks to get your peering and
block propagation configuration just right and another 6 months to convince
miners to substantially use your pool.

If you meant miners and not pools, that's also wrong.  Mining hardware
doesn't validate blocks anymore, it hasn't been practical for years.  They
only get the merkle root hash of the valid transaction set.  The pool
handles the rest.

> In general, fear of other currencies passing Bitcoin is unsubstantiated.
Bitcoin has by far the strongest development team, and also is by far the
most decentralized.

Markets only care a little bit what your development team is like.
Ethereum has Vitalik, who is an incredibly smart and respectable dude,
while BU absolutely hates the core developers right now.  Markets are more
likely to put more faith in a single leader than core right now if that
comparison was really made.

"Most decentralized" is nearly impossible to quantify, and has almost no
value to speculators.  Since all of these markets are highly speculative,
they only care about future demand.  Future demand relies upon future use.
Unsubstantiated?  Ethereum is already 28% of Bitcoin by cap and 24% by
trading.  Four months ago that was 4%.  Their transaction volume also
doubled.  What world are you living in?

> A coin like ethereum may even be able to pass Bitcoin in market cap. But
that's okay. Ethereum has very different properties and it's not something
I would trust as a tool to provide me with political sovereignty.

Well great, I guess so long as you're ok with it we'll just roll with it.
Wait, no.  If Bitcoin loses its first-mover network effect, a small cadre
of die-hard libertarians are not going to be able to keep it from becoming
a page in the history books.  Die hard libertarians can barely keep a voice
in the U.S. congress - neither markets nor day-to-day users particularly
care about the philosophy, they care about what it can do for them.

> Ethereum passing Bitcoin in market cap does not mean that it has proved
superior to Bitcoin.

The markets have literally told us why Ethereum is shooting up.  Its
because the Bitcoin community has fractured around a debate with nearly no
progress on a solution for the last 3 years, and especially because BU
appears to be strong enough to think they can fork and the markets know
full well what a contentious fork will do to Bitcoin's near-term future.

> It could just mean that enterprises are really excited about permissioned
blockchains.

Then it would have happened not when the BU situation imploded but when
Microsoft announced they were working with Ethereum on things like that.
No one cared about Microsoft's announcement.  You don't seriously believe
what you're saying, do you?

> That's not interesting to me at any market cap.

I agree with you, but Bitcoin becoming a page in the history books because
a few die-hard libertarians didn't think price or adoption was important is
a big, big concern, especially when they almost have veto power.  Markets
don't care about philosophy, they care about future value.  Bitcoin has
value because we think it may be the most useful new innovation in the
future.  If we screw that future usefulness up, philosophy gives us no more
value than Friendster has today.

On Thu, Mar 30, 2017 at 4:19 AM, David Vorick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > What we want is a true fee-market where the miner can decide to make a
> block
> > smaller to get people to pay more fees, because if we were to go to 16M=
B
> > blocks in one go, the cost of the miner would go up, but his reward
> based on
> > fees will go down!
> > A block so big that 100% of the transactions will always be mined in th=
e
> > next block will just cause a large section of people to no longer feel
> the
> > need to pay fees.
>
> > As such I don=E2=80=99t fear the situation where the block size limit g=
oes up a
> lot
> > in one go, because it is not in anyone=E2=80=99s interest to make the a=
ctual
> block
> > size follow.
>
> There have been attacks demonstrated where a malicious miner with
> sufficient hashrate can leverage large blocks to exacerbate selfish minin=
g.
> Adversarial behaviors from miners need to be considered, it's not safe to
> simply assume that a miner won't have reasons to attack the network. We
> already know that large empty blocks (rather, blocks with fake
> transactions) can be leveraged in ways that both damages the network and
> increases miner profits.
>
> In general, fear of other currencies passing Bitcoin is unsubstantiated.
> Bitcoin has by far the strongest development team, and also is by far the
> most decentralized. To the best of my knowledge, Bitcoin is the only
> cryptocurrency out there that is both not-dead and also lacks a strong
> central leadership.
>
> A coin like ethereum may even be able to pass Bitcoin in market cap. But
> that's okay. Ethereum has very different properties and it's not somethin=
g
> I would trust as a tool to provide me with political sovereignty. Ethereu=
m
> passing Bitcoin in market cap does not mean that it has proved superior t=
o
> Bitcoin. It could just mean that enterprises are really excited about
> permissioned blockchains. That's not interesting to me at any market cap.
>
> Bitcoin's core value add is and should continue to be decentralization an=
d
> trustlessness. Nobody is remotely close to competing with Bitcoin on thos=
e
> fronts, and in my mind that's far more important than any of the other
> mania anyway.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-family:sans-serif;font-size:=
13.696px">There have been attacks demonstrated where a malicious miner with=
 sufficient hashrate can leverage large blocks to exacerbate selfish mining=
.<br><br>Can you give me a link to this?=C2=A0 Having done a lot of mining,=
 I really really doubt this.=C2=A0 I&#39;m assuming the theory relies upon =
propagation times and focuses on small miners versus large ones, but that&#=
39;s wrong.=C2=A0 Propagation times don&#39;t affect small miners dispropor=
tionately, though they might affect small POOLS disproportionately, that is=
n&#39;t the same thing at all.=C2=A0 No miner since at least 2014 has opera=
ted a full node directly with each miner - it is incredibly impractical to =
do so.=C2=A0 They retrieve only the merkle root hash and other parameters f=
rom the stratum server, which is a very small packet and does not increase =
with the size of the blocks.=C2=A0 If they really want to select which tran=
sactions to include, some pools offer options of that sort(or can, I believ=
e) but almost no one does.=C2=A0 If they don&#39;t like how their pool pick=
s transactions, they&#39;ll use a different pool, that simple.<br><br>If th=
ere&#39;s some other theory about a miner exploiting higher blocksizes self=
ishly then I&#39;d love to read up on it to understand it.=C2=A0 If what yo=
u/others actually meant by that was smaller &quot;pools,&quot; that&#39;s a=
 much much smaller problem.=C2=A0 Pools don&#39;t earn major profits and ge=
nerally are at the mercy of their miners if they make bad choices or can&#3=
9;t fix low performance.=C2=A0 For pools, block propagation time was a majo=
r major issue even before blocks were full, and latency + packet loss betwe=
en mining units and the pool is also a big concern.=C2=A0 I was seeing occa=
sional block propagation delays(over a minute) on a fiber connection in 201=
3/4 due to minute differences in peering.=C2=A0 If a pool can&#39;t afford =
enough bandwidth to keep propagation times down, they can&#39;t be a pool.=
=C2=A0 Bigger blocksizes will make it so they even more totally-can&#39;t-b=
e-a-pool, but they already can&#39;t be a pool, so who cares.=C2=A0 Plus, c=
ompact blocks should have already solve nearly all of this problem as I und=
erstand it.<br><br>So definitely want to know more if I&#39;m misunderstand=
ing the attack vector.<br><br>&gt;=C2=A0</span><span style=3D"font-family:s=
ans-serif;font-size:13.696px">We already know that large empty blocks (rath=
er, blocks with fake transactions) can be leveraged in ways that both damag=
es the network and increases miner profits.</span><div><span style=3D"font-=
family:sans-serif;font-size:13.696px"><br>Maybe you&#39;re meaning an attac=
k where other pools get stuck on validation due to processing issues?=C2=A0=
 This is also a nonissue.=C2=A0 The smallest viable pool has enough difficu=
lties with other, non-hardware related issues that buying the largest, beef=
iest standard processor available with ample RAM won&#39;t even come up on =
the radar.=C2=A0 No one cares about $600 in hardware versus $1000 in hardwa=
re when it takes you 6 weeks to get your peering and block propagation conf=
iguration just right and another 6 months to convince miners to substantial=
ly use your pool.<br><br>If you meant miners and not pools, that&#39;s also=
 wrong.=C2=A0 Mining hardware doesn&#39;t validate blocks anymore, it hasn&=
#39;t been practical for years.=C2=A0 They only get the merkle root hash of=
 the valid transaction set.=C2=A0 The pool handles the rest.<br><br>&gt;=C2=
=A0</span><span style=3D"font-family:sans-serif;font-size:13.696px">In gene=
ral, fear of other currencies passing Bitcoin is unsubstantiated. Bitcoin h=
as by far the strongest development team, and also is by far the most decen=
tralized.<br><br>Markets only care a little bit what your development team =
is like.=C2=A0 Ethereum has Vitalik, who is an incredibly smart and respect=
able dude, while BU absolutely hates the core developers right now.=C2=A0 M=
arkets are more likely to put more faith in a single leader than core right=
 now if that comparison was really made.<br><br>&quot;Most decentralized&qu=
ot; is nearly impossible to quantify, and has almost no value to speculator=
s.=C2=A0 Since all of these markets are highly speculative, they only care =
about future demand.=C2=A0 Future demand relies upon future use.=C2=A0 Unsu=
bstantiated?=C2=A0 Ethereum is already 28% of Bitcoin by cap and 24% by tra=
ding.=C2=A0 Four months ago that was 4%.=C2=A0 Their transaction volume als=
o doubled.=C2=A0 What world are you living in?</span></div><div><span style=
=3D"font-family:sans-serif;font-size:13.696px"><br></span></div><div><span =
style=3D"font-family:sans-serif;font-size:13.696px">&gt;=C2=A0</span><span =
style=3D"font-family:sans-serif;font-size:13.696px">A coin like ethereum ma=
y even be able to pass Bitcoin in market cap. But that&#39;s okay. Ethereum=
 has very different properties and it&#39;s not something I would trust as =
a tool to provide me with political sovereignty.<br><br>Well great, I guess=
 so long as you&#39;re ok with it we&#39;ll just roll with it.=C2=A0 Wait, =
no.=C2=A0 If Bitcoin loses its first-mover network effect, a small cadre of=
 die-hard libertarians are not going to be able to keep it from becoming a =
page in the history books.=C2=A0 Die hard libertarians can barely keep a vo=
ice in the U.S. congress - neither markets nor day-to-day users particularl=
y care about the philosophy, they care about what it can do for them.</span=
></div><div><span style=3D"font-family:sans-serif;font-size:13.696px"><br><=
/span></div><div><span style=3D"font-family:sans-serif;font-size:13.696px">=
&gt;=C2=A0</span><span style=3D"font-family:sans-serif;font-size:13.696px">=
Ethereum passing Bitcoin in market cap does not mean that it has proved sup=
erior to Bitcoin.</span><span style=3D"font-family:sans-serif;font-size:13.=
696px">=C2=A0<br><br>The markets have literally told us why Ethereum is sho=
oting up.=C2=A0 Its because the Bitcoin community has fractured around a de=
bate with nearly no progress on a solution for the last 3 years, and especi=
ally because BU appears to be strong enough to think they can fork and the =
markets know full well what a contentious fork will do to Bitcoin&#39;s nea=
r-term future.<br><br>&gt;=C2=A0</span><span style=3D"font-family:sans-seri=
f;font-size:13.696px">It could just mean that enterprises are really excite=
d about permissioned blockchains.<br><br>Then it would have happened not wh=
en the BU situation imploded but when Microsoft announced they were working=
 with Ethereum on things like that.=C2=A0 No one cared about Microsoft&#39;=
s announcement.=C2=A0 You don&#39;t seriously believe what you&#39;re sayin=
g, do you?<br><br>&gt;=C2=A0</span><span style=3D"font-family:sans-serif;fo=
nt-size:13.696px">That&#39;s not interesting to me at any market cap.<br><b=
r>I agree with you, but Bitcoin becoming a page in the history books becaus=
e a few die-hard libertarians didn&#39;t think price or adoption was import=
ant is a big, big concern, especially when they almost have veto power.=C2=
=A0 Markets don&#39;t care about philosophy, they care about future value.=
=C2=A0 Bitcoin has value because we think it may be the most useful new inn=
ovation in the future.=C2=A0 If we screw that future usefulness up, philoso=
phy gives us no more value than Friendster has today.</span></div></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Mar 30, 2017=
 at 4:19 AM, David Vorick via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"auto"><span class=3D""><div class=3D"gmail_extra" dir=
=3D"auto">&gt;=C2=A0<span style=3D"font-family:sans-serif;font-size:13.696p=
x">What we want is a true fee-market where the miner can decide to make a b=
lock</span></div><span style=3D"font-family:sans-serif;font-size:13.696px">=
&gt; smaller to get people to pay more fees, because if we were to go to 16=
MB</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span styl=
e=3D"font-family:sans-serif;font-size:13.696px">&gt; blocks in one go, the =
cost of the miner would go up, but his reward based on</span><br style=3D"f=
ont-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-s=
erif;font-size:13.696px">&gt; fees will go down!</span><br style=3D"font-fa=
mily:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;f=
ont-size:13.696px">&gt; A block so big that 100% of the transactions will a=
lways be mined in the</span><br style=3D"font-family:sans-serif;font-size:1=
3.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">&gt; nex=
t block will just cause a large section of people to no longer feel the</sp=
an><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"f=
ont-family:sans-serif;font-size:13.696px">&gt; need to pay fees.</span><br =
style=3D"font-family:sans-serif;font-size:13.696px"><br style=3D"font-famil=
y:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font=
-size:13.696px">&gt; As such I don=E2=80=99t fear the situation where the b=
lock size limit goes up a lot</span><br style=3D"font-family:sans-serif;fon=
t-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">=
&gt; in one go, because it is not in anyone=E2=80=99s interest to make the =
actual block</span><br style=3D"font-family:sans-serif;font-size:13.696px">=
<span style=3D"font-family:sans-serif;font-size:13.696px">&gt; size follow.=
</span><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-size:13=
.696px"><br></span></div></span><div dir=3D"auto"><span style=3D"font-famil=
y:sans-serif;font-size:13.696px">There have been attacks demonstrated where=
 a malicious miner with sufficient hashrate can leverage large blocks to ex=
acerbate selfish mining. Adversarial behaviors from miners need to be consi=
dered, it&#39;s not safe to simply assume that a miner won&#39;t have reaso=
ns to attack the network. We already know that large empty blocks (rather, =
blocks with fake transactions) can be leveraged in ways that both damages t=
he network and increases miner profits.</span></div><div dir=3D"auto"><span=
 style=3D"font-family:sans-serif;font-size:13.696px"><br></span></div><div =
dir=3D"auto"><span style=3D"font-family:sans-serif;font-size:13.696px">In g=
eneral, fear of other currencies passing Bitcoin is unsubstantiated. Bitcoi=
n has by far the strongest development team, and also is by far the most de=
centralized. To the best of my knowledge, Bitcoin is the only cryptocurrenc=
y out there that is both not-dead and also lacks a strong central leadershi=
p.</span></div><div dir=3D"auto"><span style=3D"font-family:sans-serif;font=
-size:13.696px"><br></span></div><div dir=3D"auto"><span style=3D"font-fami=
ly:sans-serif;font-size:13.696px">A coin like ethereum may even be able to =
pass Bitcoin in market cap. But that&#39;s okay. Ethereum has very differen=
t properties and it&#39;s not something I would trust as a tool to provide =
me with political sovereignty. Ethereum passing Bitcoin in market cap does =
not mean that it has proved superior to Bitcoin. It could just mean that en=
terprises are really excited about permissioned blockchains. That&#39;s not=
 interesting to me at any market cap.</span></div><div dir=3D"auto"><span s=
tyle=3D"font-family:sans-serif;font-size:13.696px"><br></span></div><div di=
r=3D"auto"><font face=3D"sans-serif"><span style=3D"font-size:13.696px">Bit=
coin&#39;s core value add is and should continue to be decentralization and=
 trustlessness. Nobody is remotely close to competing with Bitcoin on those=
 fronts, and in my mind that&#39;s far more important than any of the other=
 mania anyway.</span></font></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--f403045e20e201a066054bf9925b--