summaryrefslogtreecommitdiff
path: root/10/959d7ff5bf415396b6160e9825e8c9a68e2256
blob: e54fc5044368c934ff65bfabd46d9b6cd0d3e478 (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
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F46283D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Aug 2015 11:04:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com
	[209.85.217.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 204EB153
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Aug 2015 11:04:25 +0000 (UTC)
Received: by lbbpo9 with SMTP id po9so3691658lbb.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 04 Aug 2015 04:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=R/qBeYmrL11QKFYWvNsi6EtK3AhFDV4nvdu4ra8hWa8=;
	b=lHHPDPK3Z2AtSPtMSDUxEILsG6MEIM3B+JfbVWlH4Qd359D+LZLfjKLfb8lL7CTSh5
	+mwiGAqEpDF5exjxGpLM1ckrJCdh8sguJweLPq71dHs2Y+ti0uWR3LREFDVjvdOWRbMg
	eCv+0cosiTG4WwRBI6KETdyFNSh8BIEmQ1Qr/j2P4xG0Sj4310p6XsBT+78pkbQehM6K
	FbCbNf/vbtJj5eU8ENSNh8HCkK0FLJeDZ4YOCWJA5xsuJpgQuDgBeLKrWEWdfV48epY4
	kX2gj7Wzj6O2W1Mr5XbBRiwnOY/WhxPTJsuJS3WTOCyCvue5fL/YKOG87HHkcBhEm/lQ
	Q/1A==
X-Received: by 10.112.161.40 with SMTP id xp8mr2628302lbb.71.1438686263219;
	Tue, 04 Aug 2015 04:04:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Tue, 4 Aug 2015 04:04:03 -0700 (PDT)
In-Reply-To: <CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
	<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
	<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
	<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
	<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
	<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
	<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
	<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
	<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Tue, 4 Aug 2015 12:04:03 +0100
Message-ID: <CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a11c25f52a99aa5051c7a3fab
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
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: Tue, 04 Aug 2015 11:04:27 -0000

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

Mike's position is that he wants the block size limit
to eventually be removed. That is of course an extreme view. Meanwhile,
your view that the block size should be artificially constrained below the
organic growth curve (in a way that will penalize a majority of existing
and future users) lies at the other extreme. The majority position lies
somewhere in between (i.e. a one-time increase to 8MB). This is the
position that ultimately matters.

If the block size is increased to 8MB and things get demonstrably a whole
lot worse, then you will have a solid leg to stand on. In that case we can
always do another hard fork later to reduce the block size back to
something smaller, and henceforth the block size will never be touched
again.

On 4 August 2015 at 11:35, Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> >> How more users or more nodes can bring more miners, or more importantl=
y,
> >> improve mining decentralization?
> >
> >
> > Because the bigger the ecosystem is the more interest there is in takin=
g
> > part?
>
> As explained by Venzen, this is a non-sequitur.
>
> > I mean, I guess I don't know how to answer your question.
>
> I don't know the answer either, that's fine. It's the opposite
> question that I've been insistently repeating and you've been
> (consciously or not) consistently evading.
> But that's also fine because I believe you finally answer it a few lines
> below.
>
> > When Bitcoin was
> > new it had almost no users and almost no miners. Now there are millions
> of
> > users and factories producing ASICs just for Bitcoin.
>
> The emergence of a btc price enabled the emergence of professional
> miners, which in turn enabled the emergence of sha256d-specialized
> hardware production companies.
> Nothing surprising there.
> By no means it consitutes an example of how a bigger consensus sizes
> can cause less mining centralization.
>
> > Surely the correlation is obvious?
>
> Correlation does not imply causation. I will better leave it at that...
>
> >> I'm sorry, but until there's a simulation that I can run with differen=
t
> >> sizes' testchains (for example using #6382) to somehow compare them, I
> will
> >> consider any value arbitrary.
> >
> >
> > Gavin did run simulations. 20mb isn't arbitrary, the process behind it
> was
> > well documented here:
> >
> >
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-c=
entralized
> >
> > I chose 20MB as a reasonable block size to target because 170 gigabytes
> per
> > month comfortably fits into the typical 250-300 gigabytes per month dat=
a
> > cap=E2=80=93 so you can run a full node from home on a =E2=80=9Cpretty =
good=E2=80=9D broadband
> plan.
> >
> > Did you think 20mb was picked randomly?
>
> No, I think 20 MB was chosen very optimistically, considering 3rd
> party services rates (not the same service as self-hosting) in the
> so-called "first world". And then 20 MB goes to 20 GB, again with
> optimistic and by no means scientific expectations.
>
> But where the number comes from it's not really what I'm demaning,
> what I want is some criterion that can tell you that a given size
> would be "too centralized" but another one isn't.
> I haven't read any analysis on why 8GB is a better option than 7GB and
> 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
> or 21 GB).
> A simulation test passing 20 GB but not 21 GB would make it far less
> arbitrary.
>
> >> Agreed on the first sentence, I'm just saying that the influence of
> >> the blocksize in that function is monotonic: with bigger sizes, equal
> >> or worse mining centralization.
> >
> >
> > I have a hard time agreeing with this because I've seen Bitcoin go from
> > blocks that were often empty to blocks that are often full, and in this
> time
> > the number of miners and hash power on the network has gone up a huge
> amount
> > too.
>
> I'm of course talking about consensus maximum blocksize, not about
> actual blocksize.
> Yes, again, when mining becomes profitable, economic actors tend to
> appear and get those profits.
> But don't confuse total hashrate improvements with an "increase in the
> number of miners" or with mining decentralization.
>
> > You can argue that a miner doesn't count if they pool mine. But if a
> miner
> > mines on a pool that uses exactly the same software and settings as the
> > miner would have done anyway, then it makes no difference. Miners can
> switch
> > between pools to find one that works the way they like, so whilst less
> > pooling or more decentralised pools would be nice (e.g.
> getblocktemplate),
> > and I've written about how to push it forward before, I still say there
> are
> > many more miners than in the past.
> >
> > If I had to pick between two changes to improve mining decentralisation=
:
> >
> > 1) Lower block size
>
> Finally, I think you finally answered my repetitive question here.
> If I say "Mike Hearn understands that the consensus block size maximum
> rule is a tool for limitting mining centralization" I'm not putting
> words in your mouth, right?
> I think many users advocating for an increase in the consensus limit
> don't understand this, which is extremely unfortunate for the debate.
>
> > 2) Finishing, documenting, and making the UX really slick for a
> > getblocktemplate based decentralised mining pool
> >
> > then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.
>
> Great! Maybe after 2 mining centralization improves so much that we're
> confortable not only not lowering it but rather increasing it.
>
> >> you should be consequently advocating for full removal of the limit
> rather
> >> than changes towards bigger arbitrary values.
> >
> >
> > I did toy with that idea a while ago. Of course there can not really be
> no
> > limit at all because the code assumes blocks fit into RAM/swap, and nod=
es
> > would just end up ignoring blocks they couldn't download in time anyway=
.
> > There is obviously a physical limit somewhere.
>
> Did the fact that you "understand that the consensus block size
> maximum rule is a tool for limitting mining centralization" influenced
> your rejection of that idea at all?
>
> > But it is easier to find common ground with others by compromising. Is
> 8mb
> > better than no limit? I don't know and I don't care much:  I think
> Bitcoin
> > adoption is a slow, hard process and we'll be lucky to increase average
> > usage 8x over the next couple of years. So if 8mb+ is better for others=
,
> > that's OK by me.
>
> The only way that "not caring much whther we have a consensus limit or
> not" and "understand that the consensus block size maximum rule is a
> tool for limitting mining centralization" at the same time is by not
> caring about mining centralization at all.
> Is that your position?
>
> If you don't care about having a limit but you don't want to limit
> transaction volume, then ++current_size will ALWAYs be your
> "compromise position" and no blocksize increase will ever be enough
> until the limit is completely removed.
> Is that your position?
>
> > Re: exchange profit. You can pick some other useful service provider if
> you
> > like. Payment processors or cold storage providers or the TREZOR
> > manufacturers or whoever.
>
> Yes, and I believe the same points stand.
>
> > My point is you can't have a tiny high-value-transactions only currency
> AND
> > all the useful infrastructure that the Bitcoin community is making. It'=
s
> a
> > contradiction. And without the infrastructure bitcoin ceases to be
> > interesting even to people who are willing to pay huge sums to use it.
>
> You keep talking about "high-value-transactions-only" like if
> non-urgent transaction fees rising from zero to, say, 1 satoshi, would
> automatically result in that "high-value-transactions-only" Bitcoin.
> Please, stop talking as if someone was proposing a
> "high-value-transactions-only" Bitcoin. That may happen but nobody
> really knows. If it happens it may not be bad thing necessarily (ie
> bitcoin microtransactions can still happen using trustless payment
> channels and x is still cheaper than x% for any transacted value
> higher than 100) but that's really not what we're talking about here
> so it seems distraction that can only help further polirizing this
> discussion.
>
> What we're talking about here is that hitting the limit would
> (hopefully) make miners start caring about fees. Enough that they stop
> being irrational about free transactions. If both things happen,
> non-urgent transaction fees will likely rise (as said, above zero).
>
> You think that would be a catastrophe for adoption and I disagree.
> But (as Pieter has repeatedly explained) for any size there will be
> use cases that will be eventually priced out.
> So when rising this consensus limit, not increasing centralization
> should be the priority and the potential impact in market fees a much
> more secondary concern.
> Do you agree with this?
>
> I'm sure there are many intermediate positions between "caring more
> about mining centralization than market fees when deciding about a
> consensus rule that limits mining centralization" and "not caring
> about mining centralization at all".
> I really don't want to put words in your mouth, but I honestly don't
> know what your position is.
> I don't really know how else can I ask the same question: you don't
> care the consensus maximum blocksize rule being here at all or not
> (you just said that).
> Is it because you don't think it limits mining centralization or
> because you don't care about limiting mining centralization with
> consensus rules at all?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Mike&#39;s position is that he wants the block size limit =
to=C2=A0eventually=C2=A0be=C2=A0removed. That is of course an extreme view.=
 Meanwhile, your view that the block size should be artificially constraine=
d below the organic growth curve (in a way that will penalize a majority of=
 existing and future users) lies at the other extreme. The majority positio=
n lies somewhere in between (i.e. a one-time increase to 8MB). This is the =
position that ultimately matters.<div><br></div><div>If the block size is i=
ncreased to 8MB and things get demonstrably a whole lot worse, then you wil=
l have a solid leg to stand on. In that case we can always do another hard =
fork later to reduce the block size back to something smaller, and hencefor=
th the block size will never be touched again.</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On 4 August 2015 at 11:35, Jorge T=
im=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Fri,=
 Jul 31, 2015 at 4:58 PM, Mike Hearn &lt;<a href=3D"mailto:hearn@vinumeris.=
com">hearn@vinumeris.com</a>&gt; wrote:<br>
&gt;&gt; How more users or more nodes can bring more miners, or more import=
antly,<br>
&gt;&gt; improve mining decentralization?<br>
&gt;<br>
&gt;<br>
&gt; Because the bigger the ecosystem is the more interest there is in taki=
ng<br>
&gt; part?<br>
<br>
</span>As explained by Venzen, this is a non-sequitur.<br>
<span class=3D""><br>
&gt; I mean, I guess I don&#39;t know how to answer your question.<br>
<br>
</span>I don&#39;t know the answer either, that&#39;s fine. It&#39;s the op=
posite<br>
question that I&#39;ve been insistently repeating and you&#39;ve been<br>
(consciously or not) consistently evading.<br>
But that&#39;s also fine because I believe you finally answer it a few line=
s below.<br>
<span class=3D""><br>
&gt; When Bitcoin was<br>
&gt; new it had almost no users and almost no miners. Now there are million=
s of<br>
&gt; users and factories producing ASICs just for Bitcoin.<br>
<br>
</span>The emergence of a btc price enabled the emergence of professional<b=
r>
miners, which in turn enabled the emergence of sha256d-specialized<br>
hardware production companies.<br>
Nothing surprising there.<br>
By no means it consitutes an example of how a bigger consensus sizes<br>
can cause less mining centralization.<br>
<span class=3D""><br>
&gt; Surely the correlation is obvious?<br>
<br>
</span>Correlation does not imply causation. I will better leave it at that=
...<br>
<span class=3D""><br>
&gt;&gt; I&#39;m sorry, but until there&#39;s a simulation that I can run w=
ith different<br>
&gt;&gt; sizes&#39; testchains (for example using #6382) to somehow compare=
 them, I will<br>
&gt;&gt; consider any value arbitrary.<br>
&gt;<br>
&gt;<br>
&gt; Gavin did run simulations. 20mb isn&#39;t arbitrary, the process behin=
d it was<br>
&gt; well documented here:<br>
&gt;<br>
&gt; <a href=3D"http://gavinandresen.ninja/does-more-transactions-necessari=
ly-mean-more-centralized" rel=3D"noreferrer" target=3D"_blank">http://gavin=
andresen.ninja/does-more-transactions-necessarily-mean-more-centralized</a>=
<br>
&gt;<br>
&gt; I chose 20MB as a reasonable block size to target because 170 gigabyte=
s per<br>
&gt; month comfortably fits into the typical 250-300 gigabytes per month da=
ta<br>
&gt; cap=E2=80=93 so you can run a full node from home on a =E2=80=9Cpretty=
 good=E2=80=9D broadband plan.<br>
&gt;<br>
&gt; Did you think 20mb was picked randomly?<br>
<br>
</span>No, I think 20 MB was chosen very optimistically, considering 3rd<br=
>
party services rates (not the same service as self-hosting) in the<br>
so-called &quot;first world&quot;. And then 20 MB goes to 20 GB, again with=
<br>
optimistic and by no means scientific expectations.<br>
<br>
But where the number comes from it&#39;s not really what I&#39;m demaning,<=
br>
what I want is some criterion that can tell you that a given size<br>
would be &quot;too centralized&quot; but another one isn&#39;t.<br>
I haven&#39;t read any analysis on why 8GB is a better option than 7GB and<=
br>
9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB<br>
or 21 GB).<br>
A simulation test passing 20 GB but not 21 GB would make it far less arbitr=
ary.<br>
<span class=3D""><br>
&gt;&gt; Agreed on the first sentence, I&#39;m just saying that the influen=
ce of<br>
&gt;&gt; the blocksize in that function is monotonic: with bigger sizes, eq=
ual<br>
&gt;&gt; or worse mining centralization.<br>
&gt;<br>
&gt;<br>
&gt; I have a hard time agreeing with this because I&#39;ve seen Bitcoin go=
 from<br>
&gt; blocks that were often empty to blocks that are often full, and in thi=
s time<br>
&gt; the number of miners and hash power on the network has gone up a huge =
amount<br>
&gt; too.<br>
<br>
</span>I&#39;m of course talking about consensus maximum blocksize, not abo=
ut<br>
actual blocksize.<br>
Yes, again, when mining becomes profitable, economic actors tend to<br>
appear and get those profits.<br>
But don&#39;t confuse total hashrate improvements with an &quot;increase in=
 the<br>
number of miners&quot; or with mining decentralization.<br>
<span class=3D""><br>
&gt; You can argue that a miner doesn&#39;t count if they pool mine. But if=
 a miner<br>
&gt; mines on a pool that uses exactly the same software and settings as th=
e<br>
&gt; miner would have done anyway, then it makes no difference. Miners can =
switch<br>
&gt; between pools to find one that works the way they like, so whilst less=
<br>
&gt; pooling or more decentralised pools would be nice (e.g. getblocktempla=
te),<br>
&gt; and I&#39;ve written about how to push it forward before, I still say =
there are<br>
&gt; many more miners than in the past.<br>
&gt;<br>
&gt; If I had to pick between two changes to improve mining decentralisatio=
n:<br>
&gt;<br>
&gt; 1) Lower block size<br>
<br>
</span>Finally, I think you finally answered my repetitive question here.<b=
r>
If I say &quot;Mike Hearn understands that the consensus block size maximum=
<br>
rule is a tool for limitting mining centralization&quot; I&#39;m not puttin=
g<br>
words in your mouth, right?<br>
I think many users advocating for an increase in the consensus limit<br>
don&#39;t understand this, which is extremely unfortunate for the debate.<b=
r>
<span class=3D""><br>
&gt; 2) Finishing, documenting, and making the UX really slick for a<br>
&gt; getblocktemplate based decentralised mining pool<br>
&gt;<br>
&gt; then I&#39;d pick (2) in a heartbeat. I think it&#39;d be a lot more e=
ffective.<br>
<br>
</span>Great! Maybe after 2 mining centralization improves so much that we&=
#39;re<br>
confortable not only not lowering it but rather increasing it.<br>
<span class=3D""><br>
&gt;&gt; you should be consequently advocating for full removal of the limi=
t rather<br>
&gt;&gt; than changes towards bigger arbitrary values.<br>
&gt;<br>
&gt;<br>
&gt; I did toy with that idea a while ago. Of course there can not really b=
e no<br>
&gt; limit at all because the code assumes blocks fit into RAM/swap, and no=
des<br>
&gt; would just end up ignoring blocks they couldn&#39;t download in time a=
nyway.<br>
&gt; There is obviously a physical limit somewhere.<br>
<br>
</span>Did the fact that you &quot;understand that the consensus block size=
<br>
maximum rule is a tool for limitting mining centralization&quot; influenced=
<br>
your rejection of that idea at all?<br>
<span class=3D""><br>
&gt; But it is easier to find common ground with others by compromising. Is=
 8mb<br>
&gt; better than no limit? I don&#39;t know and I don&#39;t care much:=C2=
=A0 I think Bitcoin<br>
&gt; adoption is a slow, hard process and we&#39;ll be lucky to increase av=
erage<br>
&gt; usage 8x over the next couple of years. So if 8mb+ is better for other=
s,<br>
&gt; that&#39;s OK by me.<br>
<br>
</span>The only way that &quot;not caring much whther we have a consensus l=
imit or<br>
not&quot; and &quot;understand that the consensus block size maximum rule i=
s a<br>
tool for limitting mining centralization&quot; at the same time is by not<b=
r>
caring about mining centralization at all.<br>
Is that your position?<br>
<br>
If you don&#39;t care about having a limit but you don&#39;t want to limit<=
br>
transaction volume, then ++current_size will ALWAYs be your<br>
&quot;compromise position&quot; and no blocksize increase will ever be enou=
gh<br>
until the limit is completely removed.<br>
Is that your position?<br>
<span class=3D""><br>
&gt; Re: exchange profit. You can pick some other useful service provider i=
f you<br>
&gt; like. Payment processors or cold storage providers or the TREZOR<br>
&gt; manufacturers or whoever.<br>
<br>
</span>Yes, and I believe the same points stand.<br>
<span class=3D""><br>
&gt; My point is you can&#39;t have a tiny high-value-transactions only cur=
rency AND<br>
&gt; all the useful infrastructure that the Bitcoin community is making. It=
&#39;s a<br>
&gt; contradiction. And without the infrastructure bitcoin ceases to be<br>
&gt; interesting even to people who are willing to pay huge sums to use it.=
<br>
<br>
</span>You keep talking about &quot;high-value-transactions-only&quot; like=
 if<br>
non-urgent transaction fees rising from zero to, say, 1 satoshi, would<br>
automatically result in that &quot;high-value-transactions-only&quot; Bitco=
in.<br>
Please, stop talking as if someone was proposing a<br>
&quot;high-value-transactions-only&quot; Bitcoin. That may happen but nobod=
y<br>
really knows. If it happens it may not be bad thing necessarily (ie<br>
bitcoin microtransactions can still happen using trustless payment<br>
channels and x is still cheaper than x% for any transacted value<br>
higher than 100) but that&#39;s really not what we&#39;re talking about her=
e<br>
so it seems distraction that can only help further polirizing this<br>
discussion.<br>
<br>
What we&#39;re talking about here is that hitting the limit would<br>
(hopefully) make miners start caring about fees. Enough that they stop<br>
being irrational about free transactions. If both things happen,<br>
non-urgent transaction fees will likely rise (as said, above zero).<br>
<br>
You think that would be a catastrophe for adoption and I disagree.<br>
But (as Pieter has repeatedly explained) for any size there will be<br>
use cases that will be eventually priced out.<br>
So when rising this consensus limit, not increasing centralization<br>
should be the priority and the potential impact in market fees a much<br>
more secondary concern.<br>
Do you agree with this?<br>
<br>
I&#39;m sure there are many intermediate positions between &quot;caring mor=
e<br>
about mining centralization than market fees when deciding about a<br>
consensus rule that limits mining centralization&quot; and &quot;not caring=
<br>
about mining centralization at all&quot;.<br>
I really don&#39;t want to put words in your mouth, but I honestly don&#39;=
t<br>
know what your position is.<br>
I don&#39;t really know how else can I ask the same question: you don&#39;t=
<br>
care the consensus maximum blocksize rule being here at all or not<br>
(you just said that).<br>
Is it because you don&#39;t think it limits mining centralization or<br>
because you don&#39;t care about limiting mining centralization with<br>
consensus rules at all?<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--001a11c25f52a99aa5051c7a3fab--