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
|
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 29EC4AB9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 10:13:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com
[209.85.128.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3FC1ECB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 10:13:20 +0000 (UTC)
Received: by mail-wr0-f174.google.com with SMTP id k6so47637703wre.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 03:13:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:references:from:cc:to:message-id:date:user-agent
:mime-version:in-reply-to;
bh=3L2TwgI2uPbZNHsPxgBhWxETVN2SmQJ3oDwRE+lzHtI=;
b=pw+xXi20jIZrjwZ8q+k8fTCHLmIFilP4mGNfpM7VRI5ZPjwQgDVFJiVpgkfj9+8eIo
xeqqmKAMxGc5XeOKTjMeWkzs1iGpDNhJ0j0sXA6th480VHR2vw68DMfxoVbmIJHTnqRw
fBc0AB+nUXPAf3Qv3aN2q92WCMwed2dM2A8R+X5Q8lfM+ywfTXAp/Hb75xZTUgdvwH0C
KsRnqWaCZ6UGr4SsX1LKGpslY44Dn2hqft65USTDRjAEZfY+r8t5UiDSoBCkD8tHS8PU
U9USvoJJcvQyFTvDDVoB7ITv3qyEKjPG1Z0li0aE/t314Devd16sOXGHbD6KxcqYx6oM
jmMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:references:from:cc:to:message-id:date
:user-agent:mime-version:in-reply-to;
bh=3L2TwgI2uPbZNHsPxgBhWxETVN2SmQJ3oDwRE+lzHtI=;
b=RlddM7LQhjER6GtDyQWuoy4GNBZSS4+VBnrdsm638vj1TBpIrzcAMu5BPmyyANsZ0X
au90MQ7qszQVvAzVsIAQIXoyyn5opbxMiynKrCuNhn7IiQTwQ33jw2njZWeq2sRs4ibG
RkMMPx8vb62Yc4gVwczBb/nruUHblLzXd16fP7zzksOqa2eTbB1h7vevTEt5rnZgU/Nc
QGdyGIUxpyckX62aeentOMYdL6FYyyMhS1kC4SG/MRqXLDksbPYKANx61qFt58mTw8Rv
GJ7CXYQKpNY3Bi/WqqXEZbW0EDXUgohuLToeCsPfmrqiqYv0K2PiTgTpbd/iIxWkLzIQ
UbyQ==
X-Gm-Message-State: AFeK/H1ItTzrZhviELZZkrp85wn9cIxNQhzBydNXU62ueLcnKWVygR1U7psaG54KTUgIQA==
X-Received: by 10.28.208.7 with SMTP id h7mr2688840wmg.79.1490868798778;
Thu, 30 Mar 2017 03:13:18 -0700 (PDT)
Received: from [192.168.1.10] (ANice-654-1-52-124.w83-201.abo.wanadoo.fr.
[83.201.223.124]) by smtp.googlemail.com with ESMTPSA id
35sm2192380wrn.9.2017.03.30.03.13.17
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 30 Mar 2017 03:13:17 -0700 (PDT)
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
<CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com>
<CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com>
<f61153c3-9afb-5cee-2c6b-70d67208f015@gmail.com>
<CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
<CAFVRnyqxQhu0c-ACfzR5=Z=C1SbR70jrfCaCeEdfSJASSnzpqw@mail.gmail.com>
<CAD1TkXtze_TVegXz4AeJCxK59+cuwRQ=w4upzX+HoQ90Py52OA@mail.gmail.com>
<2349f523-942c-ffb9-7af2-5cc81264888f@gmail.com>
<CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <a0d956d5-6d12-e378-74db-1aae3674d5a3@gmail.com>
Date: Thu, 30 Mar 2017 12:13:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------CF4283CBB91CFAD0868118FF"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,
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
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 10:13:22 -0000
This is a multi-part message in MIME format.
--------------CF4283CBB91CFAD0868118FF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Apparently we will not get an understanding and we will probably be told
soon that this is going off topic, so short answer
Eh --> No, maybe you would like to quote Mozilla or the W3C too, all of
those organizations are financed by the big companies and are promoting
their interests (specs, DRM, etc), then would you really trust them?
A full node does not have to validate all tx and blocks, I am not aware
of any P2P system organized with peers and intermediate nodes (with no
incentive) that did survive (diaspora for example), and the most famous
one (who btw is handling much more traffic than what you describe) is
doing well because there is an intrinsic incentive for the users, see my
comment here
https://ec.europa.eu/futurium/en/content/final-report-next-generation-internet-consultation,
surprising to see that nobody raised those issues during the consultation
Paradoxally crypto currencies allow now to reward/sustain other systems,
then probably they should concentrate first on how to reward/sustain
themselves, different ideas have surfaced to reward the full nodes but
still seem very far to materialize
Coming back again to the subject, does anyone have any idea of who are
behind the existing full nodes and how to rank them according to their
participation to the network? Up to now there has been quasi no
discussion about what are the plans for the full nodes which tends to
suggest that this is obvious
Le 30/03/2017 à 03:14, Jared Lee Richardson a écrit :
> > I have heard such theory before, it's a complete mistake to think
> that others would run full nodes to protect their business and then yours,
>
> It is a complete mistake to think that others would create a massive
> website to share huge volumes of information without any charges or
> even any advertising revenue.
>
> https://en.wikipedia.org/wiki/List_of_most_popular_websites
>
> Wikipedia, 5th largest website. Well, I guess there's some exceptions
> to the complete mistake, eh?
>
> Relying on other nodes to provide verification for certain types of
> transactions is completely acceptable. If I'm paying a friend $100,
> or paying my landlord $500, that's almost certainly totally fine.
> There's nothing that says SPV nodes can't source verifications from
> multiple places to prevent one source from being compromised. There's
> also some proposed ideas for fraud proofs that could be added, though
> I'm not familiar with how they work. If verification was a highly in
> demand service, but full nodes were expensive, companies would spring
> up that offered to verify transactions for a miniscule fee per month.
> They couldn't profit from 100 customers, but they could profit from
> 10,000 customers, and their reputation and business would rely on
> trustworthy verification services.
>
> I certainly wouldn't suggest any of those things for things like
> million dollar purchase, or a purchase where you don't know the seller
> and have no recourse if something goes wrong, or a purchase where
> failure to complete has life-altering consequences. Those
> transactions are the vast minority of transactions, but they need the
> additional security of full-node verification. Why is it unreasonable
> to ask them to pay for it, but not also ask other people who really
> don't need that security to pay for it? If a competing blockchain
> successfully offers both high security and low-fee users exactly what
> that particular user needs, they have a major advantage against one
> that only caters to one group or the other.
>
> > Running a full node is trivial and not expensive for people who know
> how to do it, even with much bigger blocks,
>
> This logic does not hold against the scale of the numbers. Worldwide
> 2015 transaction volume was 426 billion and is growing by almost 10%
> per year. In Bitcoin terms, that's 4.5 GB blocks, and approximately
> $30,000 in bandwidth a month just to run a pruning node. And there's
> almost no limit to the growth - 426 billion transactions is despite
> the fact that the majority of humans on earth are unbanked and did not
> add a single transaction to that number.
>
> I don't believe the argument that Bitcoin can serve all humans on
> earth is any more valid than the argument that any computer hardware
> should be able to run a node. Low node operational costs mean a
> proportional penalty to Bitcoin's usability, adoption, and price. Low
> transaction fee costs mean a proportional high node operational cost,
> and therefore possibly represent node vulnerabilities or verification
> insecurities.
>
> There's a balancing point in the middle somewhere that achieves the
> highest possible Bitcoin usability without putting the network at
> risk, and providing layers of security only for the transactions that
> truly need it and can justify the cost of such security.
>
>
>
> On Wed, Mar 29, 2017 at 3:33 PM, Aymeric Vitte <vitteaymeric@gmail.com
> <mailto:vitteaymeric@gmail.com>> wrote:
>
> I have heard such theory before, it's a complete mistake to think
> that others would run full nodes to protect their business and
> then yours, unless it is proven that they are decentralized and
> independent
>
> Running a full node is trivial and not expensive for people who
> know how to do it, even with much bigger blocks, assuming that the
> full nodes are still decentralized and that they don't have to
> fight against big nodes who would attract the traffic first
>
> I have posted many times here a small proposal, that exactly
> describes what is going on now, yes miners are nodes too... it's
> disturbing to see that despite of Tera bytes of BIPs, papers, etc
> the current situation is happening and that all the supposed
> decentralized system is biased by centralization
>
> Do we know what majority controls the 6000 full nodes?
>
>
> Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit :
>> > Perhaps you are fortunate to have a home computer that has more
>> than a single 512GB SSD. Lots of consumer hardware has that
>> little storage.
>>
>> That's very poor logic, sorry. Restricted-space SSD's are not a
>> cost-effective hardware option for running a node. Keeping
>> blocksizes small has significant other costs for everyone.
>> Comparing the cost of running a node under arbitrary conditons A,
>> B, or C when there are far more efficient options than any of
>> those is a very bad way to think about the costs of running a
>> node. You basically have to ignore the significant consequences
>> of keeping blocks small.
>>
>> If node operational costs rose to the point where an entire wide
>> swath of users that we do actually need for security purposes
>> could not justify running a node, that's something important for
>> consideration. For me, that translates to modern hardware that's
>> relatively well aligned with the needs of running a node -
>> perhaps budget hardware, but still modern - and above-average
>> bandwidth caps.
>>
>> You're free to disagree, but your example only makes sense to me
>> if blocksize caps didn't have serious consequences. Even if
>> those consequences are just the threat of a contentious fork by
>> people who are mislead about the real consequences, that threat
>> is still a consequence itself.
>>
>> On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>
>> Perhaps you are fortunate to have a home computer that has
>> more than a single 512GB SSD. Lots of consumer hardware has
>> that little storage. Throw on top of it standard consumer
>> usage, and you're often left with less than 200 GB of free
>> space. Bitcoin consumes more than half of that, which feels
>> very expensive, especially if it motivates you to buy another
>> drive.
>>
>> I have talked to several people who cite this as the primary
>> reason that they are reluctant to join the full node club.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
> --
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> <https://github.com/Ayms/zcash-wallets>
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> <https://github.com/Ayms/bitcoin-wallets>
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> <https://github.com/Ayms/torrent-live>
> node-Tor : https://www.github.com/Ayms/node-Tor
> <https://www.github.com/Ayms/node-Tor>
> GitHub : https://www.github.com/Ayms
>
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
--------------CF4283CBB91CFAD0868118FF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Apparently we will not get an understanding and we will probably
be told soon that this is going off topic, so short answer</p>
<p>Eh --> No, maybe you would like to quote Mozilla or the W3C
too, all of those organizations are financed by the big companies
and are promoting their interests (specs, DRM, etc), then would
you really trust them?</p>
<p>A full node does not have to validate all tx and blocks, I am not
aware of any P2P system organized with peers and intermediate
nodes (with no incentive) that did survive (diaspora for example),
and the most famous one (who btw is handling much more traffic
than what you describe) is doing well because there is an
intrinsic incentive for the users, see my comment here
<a class="moz-txt-link-freetext" href="https://ec.europa.eu/futurium/en/content/final-report-next-generation-internet-consultation">https://ec.europa.eu/futurium/en/content/final-report-next-generation-internet-consultation</a>,
surprising to see that nobody raised those issues during the
consultation</p>
<p>Paradoxally crypto currencies allow now to reward/sustain other
systems, then probably they should concentrate first on how to
reward/sustain themselves, different ideas have surfaced to reward
the full nodes but still seem very far to materialize<br>
</p>
<p>Coming back again to the subject, does anyone have any idea of
who are behind the existing full nodes and how to rank them
according to their participation to the network? Up to now there
has been quasi no discussion about what are the plans for the full
nodes which tends to suggest that this is obvious<br>
</p>
<br>
<div class="moz-cite-prefix">Le 30/03/2017 à 03:14, Jared Lee
Richardson a écrit :<br>
</div>
<blockquote
cite="mid:CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com"
type="cite">
<div dir="ltr">> <span style="font-size:12.8px">I have heard
such theory before, it's a complete mistake to think that
others would run full nodes to protect their business and then
yours,<br>
<br>
It is a complete mistake to think that others would create a
massive website to share huge volumes of information without
any charges or even any advertising revenue.<br>
<br>
</span>
<div><span style="font-size:12.8px"><a moz-do-not-send="true"
href="https://en.wikipedia.org/wiki/List_of_most_popular_websites">https://en.wikipedia.org/wiki/List_of_most_popular_websites</a><br>
</span><br>
Wikipedia, 5th largest website. Well, I guess there's some
exceptions to the complete mistake, eh?</div>
<div><br>
</div>
<div>Relying on other nodes to provide verification for certain
types of transactions is completely acceptable. If I'm paying
a friend $100, or paying my landlord $500, that's almost
certainly totally fine. There's nothing that says SPV nodes
can't source verifications from multiple places to prevent one
source from being compromised. There's also some proposed
ideas for fraud proofs that could be added, though I'm not
familiar with how they work. If verification was a highly in
demand service, but full nodes were expensive, companies would
spring up that offered to verify transactions for a miniscule
fee per month. They couldn't profit from 100 customers, but
they could profit from 10,000 customers, and their reputation
and business would rely on trustworthy verification services.<br>
<br>
I certainly wouldn't suggest any of those things for things
like million dollar purchase, or a purchase where you don't
know the seller and have no recourse if something goes wrong,
or a purchase where failure to complete has life-altering
consequences. Those transactions are the vast minority of
transactions, but they need the additional security of
full-node verification. Why is it unreasonable to ask them to
pay for it, but not also ask other people who really don't
need that security to pay for it? If a competing blockchain
successfully offers both high security and low-fee users
exactly what that particular user needs, they have a major
advantage against one that only caters to one group or the
other.<br>
<br>
> <span style="font-size:12.8px">Running a full node is
trivial and not expensive for people who know how to do it,
even with much bigger blocks,<br>
<br>
This logic does not hold against the scale of the numbers.
Worldwide 2015 transaction volume was 426 billion and is
growing by almost 10% per year. In Bitcoin terms, that's
4.5 GB blocks, and approximately $30,000 in bandwidth a
month just to run a pruning node. And there's almost no
limit to the growth - 426 billion transactions is despite
the fact that the majority of humans on earth are unbanked
and did not add a single transaction to that number.</span></div>
<div><span style="font-size:12.8px"><br>
</span></div>
<div><span style="font-size:12.8px">I don't believe the argument
that Bitcoin can serve all humans on earth is any more valid
than the argument that any computer hardware should be able
to run a node. Low node operational costs mean a
proportional penalty to Bitcoin's usability, adoption, and
price. Low transaction fee costs mean a proportional high
node operational cost, and therefore possibly represent node
vulnerabilities or verification insecurities.<br>
<br>
</span></div>
<div><span style="font-size:12.8px">There's a balancing point in
the middle somewhere that achieves the highest possible
Bitcoin usability without putting the network at risk, and
providing layers of security only for the transactions that
truly need it and can justify the cost of such security.</span></div>
<div><span style="font-size:12.8px"><br>
<br>
</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 29, 2017 at 3:33 PM,
Aymeric Vitte <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:vitteaymeric@gmail.com" target="_blank">vitteaymeric@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>I have heard such theory before, it's a complete
mistake to think that others would run full nodes to
protect their business and then yours, unless it is
proven that they are decentralized and independent</p>
<p>Running a full node is trivial and not expensive for
people who know how to do it, even with much bigger
blocks, assuming that the full nodes are still
decentralized and that they don't have to fight against
big nodes who would attract the traffic first<br>
</p>
<p>I have posted many times here a small proposal, that
exactly describes what is going on now, yes miners are
nodes too... it's disturbing to see that despite of Tera
bytes of BIPs, papers, etc the current situation is
happening and that all the supposed decentralized system
is biased by centralization</p>
<p>Do we know what majority controls the 6000 full nodes?</p>
<div>
<div class="h5"> <br>
<div class="m_5062382881877176539moz-cite-prefix">Le
29/03/2017 à 22:32, Jared Lee Richardson via
bitcoin-dev a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">> <span style="font-size:12.8px">Perhaps
you are fortunate to have a home computer that
has more than a single 512GB SSD. Lots of
consumer hardware has that little storage.</span><br>
<br>
<span style="font-size:12.8px">That's very poor
logic, sorry. Restricted-space SSD's are not a
cost-effective hardware option for running a
node. Keeping blocksizes small has
significant other costs for everyone. Comparing
the cost of running a node under arbitrary
conditons A, B, or C when there are far more
efficient options than any of those is a very
bad way to think about the costs of running a
node. You basically have to ignore the
significant consequences of keeping blocks
small.<br>
<br>
If node operational costs rose to the point
where an entire wide swath of users that we do
actually need for security purposes could not
justify running a node, that's something
important for consideration. For me, that
translates to modern hardware that's relatively
well aligned with the needs of running a node -
perhaps budget hardware, but still modern - and
above-average bandwidth caps.</span>
<div><span style="font-size:12.8px"><br>
</span></div>
<div><span style="font-size:12.8px">You're free to
disagree, but your example only makes sense to
me if blocksize caps didn't have serious
consequences. Even if those consequences are
just the threat of a contentious fork by
people who are mislead about the real
consequences, that threat is still a
consequence itself.</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 29, 2017 at
9:18 AM, David Vorick via bitcoin-dev <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="auto">
<div>
<div class="gmail_extra">Perhaps you are
fortunate to have a home computer that
has more than a single 512GB SSD. Lots
of consumer hardware has that little
storage. Throw on top of it standard
consumer usage, and you're often left
with less than 200 GB of free space.
Bitcoin consumes more than half of that,
which feels very expensive, especially
if it motivates you to buy another
drive.</div>
</div>
<div class="gmail_extra" dir="auto"><br>
</div>
<div class="gmail_extra" dir="auto">I have
talked to several people who cite this as
the primary reason that they are reluctant
to join the full node club.</div>
</div>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset
class="m_5062382881877176539mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
bitcoin-dev mailing list
<a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>
<a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a>
</pre>
</blockquote>
</div></div><span class=""><pre class="m_5062382881877176539moz-signature" cols="72">--
Zcash wallets made simple: <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets" target="_blank">https://github.com/Ayms/zcash-<wbr>wallets</a>
Bitcoin wallets made simple: <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets" target="_blank">https://github.com/Ayms/<wbr>bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="http://peersm.com/getblocklist" target="_blank">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="http://peersm.com/findmyass" target="_blank">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="http://torrent-live.org" target="_blank">http://torrent-live.org</a>
Peersm : <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="http://www.peersm.com" target="_blank">http://www.peersm.com</a>
torrent-live: <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live" target="_blank">https://github.com/Ayms/<wbr>torrent-live</a>
node-Tor : <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor" target="_blank">https://www.github.com/Ayms/<wbr>node-Tor</a>
GitHub : <a moz-do-not-send="true" class="m_5062382881877176539moz-txt-link-freetext" href="https://www.github.com/Ayms" target="_blank">https://www.github.com/Ayms</a></pre>
</span></div>
</blockquote></div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre></body></html>
--------------CF4283CBB91CFAD0868118FF--
|
