summaryrefslogtreecommitdiff
path: root/3d/b2beea067009b049f180d732bba458626be220
blob: 181fe5276439bd00e72d3ae23aae5d8f9da5d65a (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
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
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 <jim@ergophobia.org>) id 1YxAFX-0007jK-5b
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 08:30:11 +0000
X-ACL-Warn: 
Received: from mail-wi0-f179.google.com ([209.85.212.179])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YxAFU-0004G4-D8
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 08:30:11 +0000
Received: by wichy4 with SMTP id hy4so72118411wic.1
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 26 May 2015 01:30:02 -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=tnuAhuRWFvOaD39f8FrEq9cyNdi90o809u8zZLLWQBY=;
	b=WPDpa2QvTuFqAE72StS0rPHwAYuWvCLwAHyx6Tq+WxqWwl8cEzJfqV4cDvVSM0L6rZ
	DbMWpKWQQFTZ0D33wssCMuu3k0Hv2Fcnqkr0TxUldZoiJzvm4Uw0gj8m6CuA9CZVoi/v
	FC96U+x7X5vz+WQgUu9Ah5kcgt2BmfkBuwaSpBIH47NwRxb3ZNI8E+DMkzZKgCyRik1Q
	JSHscN4STOAwwU8Hvl9E6qsp6uUBd3XanLslH8TyyWHr7yhR073+LD1Xc4BWxIA4q1s5
	56HjIYmDpRIfoa4UOYAaxZlhlNrbpdPVSyfi+1u6EaynIe+86P8A+GrQ0pP57zdUsKO+
	Fv7Q==
X-Gm-Message-State: ALoCoQnFly4c75KcA7MLKSRTbFnPouFXAbZxXjRwYEh9nuiJZwcCbW2AwHOeBjWk2g+ZTHHXYCTs
X-Received: by 10.180.107.138 with SMTP id hc10mr38531256wib.2.1432629002308; 
	Tue, 26 May 2015 01:30:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.246.69 with HTTP; Tue, 26 May 2015 01:29:31 -0700 (PDT)
In-Reply-To: <CANJO25LfwscmT06gwk3D==+=Cj6eBt9dUCHwyrGAs6U9Eoi5Uw@mail.gmail.com>
References: <BAY403-EAS63EE0AAE718842E0E3EFD6C2CC0@phx.gbl>
	<CANe1mWw-yJv=1_aLc+T8Mq1XgUv8VeDxHee-hVzQNH0hFs1ryg@mail.gmail.com>
	<CANe1mWw2os6GUbRiyegn=Z+2ZM_J8x76rD4uh_0C3z+ix8aK+A@mail.gmail.com>
	<CANJO25LfwscmT06gwk3D==+=Cj6eBt9dUCHwyrGAs6U9Eoi5Uw@mail.gmail.com>
From: Jim Phillips <jim@ergophobia.org>
Date: Tue, 26 May 2015 03:29:31 -0500
Message-ID: <CANe1mWzK-8PM-7tPKGhEUAYmC058QXge7Ncz+uCX_h9Xbxon_g@mail.gmail.com>
To: gabe appleton <gappleto97@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f235739c721580516f7ee72
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.0 T_REMOTE_IMAGE         Message contains an external image
	0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YxAFU-0004G4-D8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
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: Tue, 26 May 2015 08:30:11 -0000

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

I think all the suggestions recommending cutting the block time down also
suggest reducing the rewards to compensate.

--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>

*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*

On Tue, May 26, 2015 at 12:43 AM, gabe appleton <gappleto97@gmail.com>
wrote:

> Sync time wouldn't be longer compared to 20MB, it would (eventually) be
> longer under either setup.
>
> Also, and this is probably a silly concern, but wouldn't changing block
> time change the supply curve? If we cut the rate in half or a power of tw=
o,
> that affects nothing, but if we want to keep it in round numbers, we need
> to do it by 10, 5, or 2. I feel like most people would bank for 10 or 5,
> both of which change the supply curve due to truncation.
>
> Again, it's a trivial concern, but probably one that should be addressed.
> On May 25, 2015 11:52 PM, "Jim Phillips" <jim@ergophobia.org> wrote:
>
>> Incidentally, even once we have the "Internet of Things" brought on by
>> 21, Inc. or whoever beats them to it, I would expect the average home to
>> have only a single full node "hub" receiving the blockchain and
>> broadcasting transactions created by all the minor SPV connected devices
>> running within the house. The in-home full node would be peered with hig=
h
>> bandwidth full-node relays running at the ISP or in the cloud. There are
>> more than enough ISPs and cloud compute providers in the world such that
>> there should be no concern at all about centralization of relays. Full
>> nodes could some day become as ubiquitous on the Internet as authoritati=
ve
>> DNS servers. And just like DNS servers, if you don't trust the nodes you=
r
>> ISP creates or it's too slow or censors transactions, there's nothing
>> preventing you from peering with nodes hosted by the Googles or OpenDNSs
>> out there, or running your own if you're really paranoid and have a few
>> extra bucks for a VPS.
>>
>> --
>> *James G. Phillips IV*
>> <https://plus.google.com/u/0/113107039501292625391/posts>
>> <http://www.linkedin.com/in/ergophobe>
>>
>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>> immortals." -- David Ogilvy*
>>
>>  *This message was created with 100% recycled electrons. Please think
>> twice before printing.*
>>
>> On Mon, May 25, 2015 at 10:23 PM, Jim Phillips <jim@ergophobia.org>
>> wrote:
>>
>>> I don't see how the fact that my 2Mbps connection causes me to not be a
>>> very good relay has any bearing on whether or not the network as a whol=
e
>>> would be negatively impacted by a 20MB block. My inability to rapidly
>>> propagate blocks doesn't really harm the network. It's only if MOST rel=
ays
>>> are as slow as mine that it creates an issue. I'm one node in thousands
>>> (potentially tens or hundreds of thousands if/when Bitcoin goes
>>> mainstream). And I'm an individual. There's no reason at all for me to =
run
>>> a full node from my home, except to have my own trusted and validated c=
opy
>>> of the blockchain on a computer I control directly. I don't need to act=
 as
>>> a relay for that and as long as I can download blocks faster than they =
are
>>> created I'm fine. Also, I can easily afford a VPS server or several to =
run
>>> full nodes as relays if I am feeling altruistic. It's actually cheaper =
for
>>> me to lease a VPS than to keep my own home PC on 24/7, which is why I h=
ave
>>> 2 of them.
>>>
>>> And as a business, the cost of a server and bandwidth to run a full nod=
e
>>> is a drop in the bucket. I'm involved in several projects where we have
>>> full nodes running on leased servers with multiple 1Gbps connections. I=
t's
>>> an almost zero cost. Those nodes could handle 20MB blocks today without
>>> thinking about it, and I'm sure our nodes are just a few amongst thousa=
nds
>>> just like them. I'm not at all concerned about the network being too
>>> centralized.
>>>
>>> What concerns me is the fact that we are using edge cases like my home
>>> PC as a lame excuse to debate expanding the capacity of the network.
>>>
>>> --
>>> *James G. Phillips IV*
>>> <https://plus.google.com/u/0/113107039501292625391/posts>
>>> <http://www.linkedin.com/in/ergophobe>
>>>
>>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>>> immortals." -- David Ogilvy*
>>>
>>>  *This message was created with 100% recycled electrons. Please think
>>> twice before printing.*
>>>
>>> On Mon, May 25, 2015 at 10:02 PM, Thy Shizzle <thyshizzle@outlook.com>
>>> wrote:
>>>
>>>>  Indeed Jim, your internet connection makes a good reason why I don't
>>>> like 20mb blocks (right now). It would take you well over a minute to
>>>> download the block before you could even relay it on, so much slow dow=
n in
>>>> propagation! Yes I do see how decreasing the time to create blocks is =
a bit
>>>> of a band-aid fix, and to use tge term I've seen mentioned here "kicki=
ng
>>>> the can down the road" I agree that this is doing this, however as you=
 say
>>>> bandwidth is our biggest enemy right now and so hopefully by the time =
we
>>>> exceed the capacity gained by the decrease in block time, we can then =
look
>>>> to bump up block size because hopefully 20mbps connections will be bas=
eline
>>>> by then etc.
>>>>  ------------------------------
>>>> From: Jim Phillips <jim@ergophobia.org>
>>>> Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:53 PM
>>>> To: Thy Shizzle <thyshizzle@outlook.com>
>>>> Cc: Mike Hearn <mike@plan99.net>; Bitcoin Dev
>>>> <bitcoin-development@lists.sourceforge.net>
>>>>
>>>> Subject: Re: [Bitcoin-development] No Bitcoin For You
>>>>
>>>>  Frankly I'm good with either way. I'm definitely in favor of faster
>>>> confirmation times.
>>>>
>>>>  The important thing is that we need to increase the amount of
>>>> transactions that get into blocks over a given time frame to a point t=
hat
>>>> is in line with what current technology can handle. We can handle WAY =
more
>>>> than we are doing right now. The Bitcoin network is not currently Disk=
,
>>>> CPU, or RAM bound.. Not even close. The metric we're closest to being
>>>> restricted by would be Network bandwidth. I live in a developing count=
ry.
>>>> 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps
>>>> connections are affordable). That equates to about 17MB per minute, or=
 170x
>>>> more capacity than what I need to receive a full copy of the blockchai=
n if
>>>> I only talk to one peer. If I relay to say 10 peers, I can still handl=
e 17x
>>>> larger block sizes on a slow 2Mbps connection.
>>>>
>>>>  Also, even if we reduce the difficulty so that we're doing 1MB blocks
>>>> every minute, that's still only 10MB every 10 minutes. Eventually we'r=
e
>>>> going to have to increase that, and we can only reduce the confirmatio=
n
>>>> period so much. I think someone once said 30 seconds or so is about th=
e
>>>> shortest period you can practically achieve.
>>>>
>>>>  --
>>>> *James G. Phillips IV*
>>>> <https://plus.google.com/u/0/113107039501292625391/posts>
>>>> <http://www.linkedin.com/in/ergophobe>
>>>>
>>>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>>>> immortals." -- David Ogilvy *
>>>>
>>>>   *This message was created with 100% recycled electrons. Please think
>>>> twice before printing.*
>>>>
>>>> On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle <thyshizzle@outlook.com>
>>>> wrote:
>>>>
>>>>  Nah don't make blocks 20mb, then you are slowing down block
>>>> propagation and blowing out conf tikes as a result. Just decrease the =
time
>>>> it takes to make a 1mb block, then you still see the same propagation =
times
>>>> today and just increase the transaction throughput.
>>>>  ------------------------------
>>>> From: Jim Phillips <jim@ergophobia.org>
>>>> Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM
>>>> To: Mike Hearn <mike@plan99.net>
>>>> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
>>>> Subject: Re: [Bitcoin-development] No Bitcoin For You
>>>>
>>>>
>>>> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike@plan99.net> wrote:
>>>>
>>>>   This meme about datacenter-sized nodes has to die. The Bitcoin wiki
>>>> is down right now, but I showed years ago that you could keep up with =
VISA
>>>> on a single well specced server with today's technology. Only people l=
iving
>>>> in a dreamworld think that Bitcoin might actually have to match that l=
evel
>>>> of transaction demand with today's hardware. As noted previously, "too=
 many
>>>> users" is simply not a problem Bitcoin has .... and may never have!
>>>>
>>>>
>>>>  ... And will certainly NEVER have if we can't solve the capacity
>>>> problem SOON.
>>>>
>>>>  In a former life, I was a capacity planner for Bank of America's
>>>> mid-range server group. We had one hard and fast rule. When you are
>>>> typically exceeding 75% of capacity on a given metric, it's time to ex=
pand
>>>> capacity. Period. You don't do silly things like adjusting the busines=
s
>>>> model to disincentivize use. Unless there's some flaw in the system an=
d
>>>> it's leaking resources, if usage has increased to the point where you =
are
>>>> at or near the limits of capacity, you expand capacity. It's as simple=
 as
>>>> that, and I've found that same rule fits quite well in a number of sys=
tems.
>>>>
>>>>  In Bitcoin, we're not leaking resources. There's no flaw. The system
>>>> is performing as intended. Usage is increasing because it works so wel=
l,
>>>> and there is huge potential for future growth as we identify more uses=
 and
>>>> attract more users. There might be a few technical things we can do to
>>>> reduce consumption, but the metric we're concerned with right now is h=
ow
>>>> many transactions we can fit in a block. We've broken through the 75%
>>>> marker and are regularly bumping up against the 100% limit.
>>>>
>>>>  It is time to stop debating this and take action to expand capacity.
>>>> The only questions that should remain are how much capacity do we add,=
 and
>>>> how soon can we do it. Given that most existing computer systems and
>>>> networks can easily handle 20MB blocks every 10 minutes, and given tha=
t
>>>> that will increase capacity 20-fold, I can't think of a single reason =
why
>>>> we can't go to 20MB as soon as humanly possible. And in a few years, w=
hen
>>>> the average block size is over 15MB, we bump it up again to as high as=
 we
>>>> can go then without pushing typical computers or networks beyond their
>>>> capacity. We can worry about ways to slow down growth without affectin=
g the
>>>> usefulness of Bitcoin as we get closer to the hard technical limits on=
 our
>>>> capacity.
>>>>
>>>>  And you know what else? If miners need higher fees to accommodate the
>>>> costs of bigger blocks, they can configure their nodes to only mine
>>>> transactions with higher fees.. Let the miners decide how to charge en=
ough
>>>> to pay for their costs. We don't need to cripple the network just for =
them.
>>>>
>>>>  --
>>>> *James G. Phillips IV*
>>>> <https://plus.google.com/u/0/113107039501292625391/posts>
>>>>
>>>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>>>> immortals." -- David Ogilvy *
>>>>
>>>>   *This message was created with 100% recycled electrons. Please think
>>>> twice before printing.*
>>>>
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------=
------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>

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

<div dir=3D"ltr">I think all the suggestions recommending cutting the block=
 time down also suggest reducing the rewards to compensate.</div><div class=
=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><div=
>--<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"https://plus.google.com=
/u/0/113107039501292625391/posts" style=3D"font-size:x-small" target=3D"_bl=
ank"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>=C2=
=A0<a href=3D"http://www.linkedin.com/in/ergophobe" target=3D"_blank"><img =
src=3D"http://developer.linkedin.com/sites/default/files/LinkedIn_Logo16px.=
png"></a></div></div><div><font size=3D"1"><i>&quot;Don&#39;t bunt. Aim out=
 of the ball park. Aim for the company of immortals.&quot; -- David Ogilvy<=
br></i></font><div><font size=3D"1"><br></font></div></div><div><font size=
=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fugue/16/leaf.png"=
>=C2=A0<em style=3D"background-color:rgb(255,255,255);font-family:verdana,g=
eneva,sans-serif;line-height:16px;color:green">This message was created wit=
h 100% recycled electrons. Please think twice before printing.</em></font><=
/div></div></div>
<br><div class=3D"gmail_quote">On Tue, May 26, 2015 at 12:43 AM, gabe apple=
ton <span dir=3D"ltr">&lt;<a href=3D"mailto:gappleto97@gmail.com" target=3D=
"_blank">gappleto97@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><p dir=3D"ltr">Sync time wouldn&#39;t be longer compared to 20MB=
, it would (eventually) be longer under either setup.</p>
<p dir=3D"ltr">Also, and this is probably a silly concern, but wouldn&#39;t=
 changing block time change the supply curve? If we cut the rate in half or=
 a power of two, that affects nothing, but if we want to keep it in round n=
umbers, we need to do it by 10, 5, or 2. I feel like most people would bank=
 for 10 or 5, both of which change the supply curve due to truncation.</p>
<p dir=3D"ltr">Again, it&#39;s a trivial concern, but probably one that sho=
uld be addressed.</p>
<div class=3D"gmail_quote"><div><div class=3D"h5">On May 25, 2015 11:52 PM,=
 &quot;Jim Phillips&quot; &lt;<a href=3D"mailto:jim@ergophobia.org" target=
=3D"_blank">jim@ergophobia.org</a>&gt; wrote:<br type=3D"attribution"></div=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"lt=
r">Incidentally, even once we have the &quot;Internet of Things&quot; broug=
ht on by 21, Inc. or whoever beats them to it, I would expect the average h=
ome to have only a single full node &quot;hub&quot; receiving the blockchai=
n and broadcasting transactions created by all the minor SPV connected devi=
ces running within the house. The in-home full node would be peered with hi=
gh bandwidth full-node relays running at the ISP or in the cloud. There are=
 more than enough ISPs and cloud compute providers in the world such that t=
here should be no concern at all about centralization of relays. Full nodes=
 could some day become as ubiquitous on the Internet as authoritative DNS s=
ervers. And just like DNS servers, if you don&#39;t trust the nodes your IS=
P creates or it&#39;s too slow or censors transactions, there&#39;s nothing=
 preventing you from peering with nodes hosted by the Googles or OpenDNSs o=
ut there, or running your own if you&#39;re really paranoid and have a few =
extra bucks for a VPS.<br><div class=3D"gmail_extra"><br clear=3D"all"><div=
><div><div>--<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"https://plus.=
google.com/u/0/113107039501292625391/posts" style=3D"font-size:x-small" tar=
get=3D"_blank"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.pn=
g"></a>=C2=A0<a href=3D"http://www.linkedin.com/in/ergophobe" target=3D"_bl=
ank"><img src=3D"http://developer.linkedin.com/sites/default/files/LinkedIn=
_Logo16px.png"></a></div></div><div><font size=3D"1"><i>&quot;Don&#39;t bun=
t. Aim out of the ball park. Aim for the company of immortals.&quot; -- Dav=
id Ogilvy<br></i></font><div><font size=3D"1"><br></font></div></div><div><=
font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fugue/16/=
leaf.png">=C2=A0<em style=3D"background-color:rgb(255,255,255);font-family:=
verdana,geneva,sans-serif;line-height:16px;color:green">This message was cr=
eated with 100% recycled electrons. Please think twice before printing.</em=
></font></div></div></div>
<br><div class=3D"gmail_quote">On Mon, May 25, 2015 at 10:23 PM, Jim Philli=
ps <span dir=3D"ltr">&lt;<a href=3D"mailto:jim@ergophobia.org" target=3D"_b=
lank">jim@ergophobia.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">I don&#39;t see how the fact that my 2Mbps connectio=
n causes me to not be a very good relay has any bearing on whether or not t=
he network as a whole would be negatively impacted by a 20MB block. My inab=
ility to rapidly propagate blocks doesn&#39;t really harm the network. It&#=
39;s only if MOST relays are as slow as mine that it creates an issue. I&#3=
9;m one node in thousands (potentially tens or hundreds of thousands if/whe=
n Bitcoin goes mainstream). And I&#39;m an individual. There&#39;s no reaso=
n at all for me to run a full node from my home, except to have my own trus=
ted and validated copy of the blockchain on a computer I control directly. =
I don&#39;t need to act as a relay for that and as long as I can download b=
locks faster than they are created I&#39;m fine. Also, I can easily afford =
a VPS server or several to run full nodes as relays if I am feeling altruis=
tic. It&#39;s actually cheaper for me to lease a VPS than to keep my own ho=
me PC on 24/7, which is why I have 2 of them.<div><br></div><div>And as a b=
usiness, the cost of a server and bandwidth to run a full node is a drop in=
 the bucket. I&#39;m involved in several projects where we have full nodes =
running on leased servers with multiple 1Gbps connections. It&#39;s an almo=
st zero cost. Those nodes could handle 20MB blocks today without thinking a=
bout it, and I&#39;m sure our nodes are just a few amongst thousands just l=
ike them. I&#39;m not at all concerned about the network being too centrali=
zed.</div><div><br></div><div>What concerns me is the fact that we are usin=
g edge cases like my home PC as a lame excuse to debate expanding the capac=
ity of the network.</div></div><div class=3D"gmail_extra"><span><br clear=
=3D"all"><div><div><div>--<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"=
https://plus.google.com/u/0/113107039501292625391/posts" style=3D"font-size=
:x-small" target=3D"_blank"><img src=3D"https://ssl.gstatic.com/images/icon=
s/gplus-16.png"></a>=C2=A0<a href=3D"http://www.linkedin.com/in/ergophobe" =
target=3D"_blank"><img src=3D"http://developer.linkedin.com/sites/default/f=
iles/LinkedIn_Logo16px.png"></a></div></div><div><font size=3D"1"><i>&quot;=
Don&#39;t bunt. Aim out of the ball park. Aim for the company of immortals.=
&quot; -- David Ogilvy<br></i></font><div><font size=3D"1"><br></font></div=
></div><div><font size=3D"1"><img src=3D"http://findicons.com/files/icons/1=
156/fugue/16/leaf.png">=C2=A0<em style=3D"background-color:rgb(255,255,255)=
;font-family:verdana,geneva,sans-serif;line-height:16px;color:green">This m=
essage was created with 100% recycled electrons. Please think twice before =
printing.</em></font></div></div></div>
<br></span><div><div><div class=3D"gmail_quote">On Mon, May 25, 2015 at 10:=
02 PM, Thy Shizzle <span dir=3D"ltr">&lt;<a href=3D"mailto:thyshizzle@outlo=
ok.com" target=3D"_blank">thyshizzle@outlook.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">



<div>
<div>
<div style=3D"font-family:Calibri,sans-serif;font-size:11pt">Indeed Jim, yo=
ur internet connection makes a good reason why I don&#39;t like 20mb blocks=
 (right now). It would take you well over a minute to download the block be=
fore you could even relay it on, so
 much slow down in propagation! Yes I do see how decreasing the time to cre=
ate blocks is a bit of a band-aid fix, and to use tge term I&#39;ve seen me=
ntioned here &quot;kicking the can down the road&quot; I agree that this is=
 doing this, however as you say bandwidth is our
 biggest enemy right now and so hopefully by the time we exceed the capacit=
y gained by the decrease in block time, we can then look to bump up block s=
ize because hopefully 20mbps connections will be baseline by then etc.</div=
>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">From:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:jim@ergophobia.org" target=3D"_blank">Jim Phillips</a></span><b=
r>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Sent:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">=E2=80=
=8E26/=E2=80=8E05/=E2=80=8E2015 12:53 PM</span><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">To:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:thyshizzle@outlook.com" target=3D"_blank">Thy Shizzle</a></span=
><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Cc:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:mike@plan99.net" target=3D"_blank">Mike Hearn</a>;
<a href=3D"mailto:bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin Dev</a></span><div><div><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Subject:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">Re: [B=
itcoin-development] No Bitcoin For You</span><br>
<br>
</div></div></div><div><div>
<div>
<div dir=3D"ltr">Frankly I&#39;m good with either way. I&#39;m definitely i=
n favor of faster confirmation times.=C2=A0
<div><br>
</div>
<div>The important thing is that we need to increase the amount of transact=
ions that get into blocks over a given time frame to a point that is in lin=
e with what current technology can handle. We can handle WAY more than we a=
re doing right now. The Bitcoin
 network is not currently Disk, CPU, or RAM bound.. Not even close. The met=
ric we&#39;re closest to being restricted by would be Network bandwidth. I =
live in a developing country. 2Mbps is a typical broadband speed here (alth=
ough 5Mbps and 10Mbps connections are
 affordable). That equates to about 17MB per minute, or 170x more capacity =
than what I need to receive a full copy of the blockchain if I only talk to=
 one peer. If I relay to say 10 peers, I can still handle 17x larger block =
sizes on a slow 2Mbps connection.
<div><br>
</div>
<div>Also, even if we reduce the difficulty so that we&#39;re doing 1MB blo=
cks every minute, that&#39;s still only 10MB every 10 minutes. Eventually w=
e&#39;re going to have to increase that, and we can only reduce the confirm=
ation period so much. I think someone once said
 30 seconds or so is about the shortest period you can practically achieve.=
</div>
</div>
</div>
<div><br clear=3D"all">
<div>
<div>
<div>--
<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"https://plus.google.com/u/=
0/113107039501292625391/posts" style=3D"font-size:x-small" target=3D"_blank=
"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>=C2=A0=
<a href=3D"http://www.linkedin.com/in/ergophobe" target=3D"_blank"><img src=
=3D"http://developer.linkedin.com/sites/default/files/LinkedIn_Logo16px.png=
"></a></div>
</div>
<div><font size=3D"1"><i>&quot;Don&#39;t bunt. Aim out of the ball park. Ai=
m for the company of immortals.&quot; -- David Ogilvy<br>
</i></font>
<div><font size=3D"1"><br>
</font></div>
</div>
<div><font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fug=
ue/16/leaf.png">=C2=A0<em style=3D"background-color:rgb(255,255,255);font-f=
amily:verdana,geneva,sans-serif;line-height:16px;color:green">This message =
was created with 100% recycled electrons.
 Please think twice before printing.</em></font></div>
</div>
</div>
<br>
<div>On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle <span dir=3D"ltr">
&lt;<a href=3D"mailto:thyshizzle@outlook.com" target=3D"_blank">thyshizzle@=
outlook.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div>
<div>
<div style=3D"font-family:Calibri,sans-serif;font-size:11pt">Nah don&#39;t =
make blocks 20mb, then you are slowing down block propagation and blowing o=
ut conf tikes as a result. Just decrease the time it takes to make a 1mb bl=
ock, then you still see the same propagation
 times today and just increase the transaction throughput.</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">From:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:jim@ergophobia.org" target=3D"_blank">Jim Phillips</a></span><b=
r>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Sent:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">=E2=80=
=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM</span><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">To:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:mike@plan99.net" target=3D"_blank">Mike Hearn</a></span><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Cc:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:bitcoin-development@lists.sourceforge.net" target=3D"_blank">Bi=
tcoin Dev</a></span><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Subject:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">Re: [B=
itcoin-development] No Bitcoin For You</span><br>
<br>
</div>
<div>
<div>
<div>
<div dir=3D"ltr">
<div><br>
<div>On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</s=
pan> wrote:</div>
<div><br>
<blockquote 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">
<div dir=3D"ltr">
<div>
<div>
<div>This meme about datacenter-sized nodes has to die. The Bitcoin wiki is=
 down right now, but I showed years ago that you could keep up with VISA on=
 a single well specced server with today&#39;s technology. Only people livi=
ng in a dreamworld think that Bitcoin
 might actually have to match that level of transaction demand with today&#=
39;s hardware. As noted previously, &quot;too many users&quot; is simply no=
t a problem Bitcoin has .... and may never have!</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<div>... And will certainly NEVER have if we can&#39;t solve the capacity p=
roblem SOON.=C2=A0</div>
<div><br>
</div>
<div>In a former life, I was a capacity planner for Bank of America&#39;s m=
id-range server group. We had one hard and fast rule. When you are typicall=
y exceeding 75% of capacity on a given metric, it&#39;s time to expand capa=
city. Period. You don&#39;t do silly things
 like adjusting the business model to disincentivize use. Unless there&#39;=
s some flaw in the system and it&#39;s leaking resources, if usage has incr=
eased to the point where you are at or near the limits of capacity, you exp=
and capacity. It&#39;s as simple as that, and
 I&#39;ve found that same rule fits quite well in a number of systems.=C2=
=A0</div>
<div><br>
</div>
<div>In Bitcoin, we&#39;re not leaking resources. There&#39;s no flaw. The =
system is performing as intended. Usage is increasing because it works so w=
ell, and there is huge potential for future growth as we identify more uses=
 and attract more users. There might be
 a few technical things we can do to reduce consumption, but the metric we&=
#39;re concerned with right now is how many transactions we can fit in a bl=
ock. We&#39;ve broken through the 75% marker and are regularly bumping up a=
gainst the 100% limit.</div>
<div><br>
</div>
<div>It is time to stop debating this and take action to expand capacity. T=
he only questions that should remain are how much capacity do we add, and h=
ow soon can we do it. Given that most existing computer systems and network=
s can easily handle 20MB blocks
 every 10 minutes, and given that that will increase capacity 20-fold, I ca=
n&#39;t think of a single reason why we can&#39;t go to 20MB as soon as hum=
anly possible. And in a few years, when the average block size is over 15MB=
, we bump it up again to as high as we can
 go then without pushing typical computers or networks beyond their capacit=
y. We can worry about ways to slow down growth without affecting the useful=
ness of Bitcoin as we get closer to the hard technical limits on our capaci=
ty.</div>
<div><br>
</div>
<div>And you know what else? If miners need higher fees to accommodate the =
costs of bigger blocks, they can configure their nodes to only mine transac=
tions with higher fees.. Let the miners decide how to charge enough to pay =
for their costs. We don&#39;t need to
 cripple the network just for them.</div>
<div><br clear=3D"all">
<div>
<div>
<div>--
<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"https://plus.google.com/u/=
0/113107039501292625391/posts" style=3D"font-size:x-small" target=3D"_blank=
"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>=C2=A0=
</div>
</div>
<div><font size=3D"1"><i>&quot;Don&#39;t bunt. Aim out of the ball park. Ai=
m for the company of immortals.&quot; -- David Ogilvy<br>
</i></font>
<div><font size=3D"1"><br>
</font></div>
</div>
<div><font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fug=
ue/16/leaf.png">=C2=A0<em style=3D"font-family:verdana,geneva,sans-serif;li=
ne-height:16px;color:green">This message was created with 100% recycled ele=
ctrons. Please think twice before printing.</em></font></div>
<div><font size=3D"1"><em style=3D"font-family:verdana,geneva,sans-serif;li=
ne-height:16px;color:green"><br>
</em></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div></div></div>

</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>
<br></div></div><span class=3D"">------------------------------------------=
------------------------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></span></blockquote></div>
</blockquote></div><br></div>

--e89a8f235739c721580516f7ee72--