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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 022478D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 18:52:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com
[209.85.213.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95491179
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 18:52:29 +0000 (UTC)
Received: by igbpg9 with SMTP id pg9so17575764igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Aug 2015 11:52:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=KdoUIddzmc64r7ynHXtzbdKlW2HGs+x6CC101ljMa6s=;
b=QbEQKZ61q+66bsglKe9ntvOyg1DoxDpJ3J94DEvkszRkp4c0IdaAMqHoJPbPAeTnBM
XdBPYP7+/6pGoLwlMME3FTLtiDQMC0+YsDNvg9Y3fZzWxhe0iHTNVbKCo346ES8xtz7m
5ldxrOiLWY9wu4IWl0ROGnMQu/ne43Q5Qn5JZYwk1h0oohIWKVUz4JDzypQdDJXRq2gs
T2E5JbHIiPlxEsVau/yxkBoYL0Ug2skyMj4nSvhxM1XqYVvpaeX5C3MyoxZk6N/f1WXz
NFE+zgkXaehoPoiJezSbqMzVq6OZk9+wvZLBOeMAC5VFdZcNS8GZQJBOOj4ixnQ2fH+L
4q/A==
MIME-Version: 1.0
X-Received: by 10.50.93.69 with SMTP id cs5mr3124932igb.4.1438887148996; Thu,
06 Aug 2015 11:52:28 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Thu, 6 Aug 2015 11:52:28 -0700 (PDT)
In-Reply-To: <CALgxB7vqA=o1L0aftMtzNYC_OYJcVw6vuqUeB3a2F6d+VuoJkA@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>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
<CA+BnGuFNOjzLaiPPnUSi-rkU94UMgmP30Si8N3oBSYG0q8j-_w@mail.gmail.com>
<CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@mail.gmail.com>
<CABsx9T22KUcbRb4ZfRDikbxK05pqWY1=uvYo10toWA-JwGa-PQ@mail.gmail.com>
<CAPg+sBg-KN5=A5_Fx3fo0dcD6mAdMUXBMNzW52SkQsRbADTmSg@mail.gmail.com>
<CABsx9T0QP3bmUkOSaD9X7zhcV3BNwT3xFZcsZnk+JL5oz-EfsA@mail.gmail.com>
<CAPg+sBi-Ls3Kuk=KE5EApqCh8amkGTUEs9a-jh--vVXs4PtxCQ@mail.gmail.com>
<CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com>
<CABsx9T1tujBCwydDC_q6d=qV1DiA0PE=fMHCpAJVjv84rx_RSw@mail.gmail.com>
<CAPg+sBhn-Gw7x6RNCo39b_GoS+BmSa0bckjaJGz-uK1QEwp4zQ@mail.gmail.com>
<CALgxB7vqA=o1L0aftMtzNYC_OYJcVw6vuqUeB3a2F6d+VuoJkA@mail.gmail.com>
Date: Thu, 6 Aug 2015 20:52:28 +0200
Message-ID: <CAPg+sBj1qCRvtZ2F1v_1JUTqwws6JOmi+8BYKVoCWPRBSs-Y=g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Michael Naber <mickeybob@gmail.com>
Content-Type: multipart/alternative; boundary=089e01537ed8634fab051ca905b5
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] Fwd: 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: Thu, 06 Aug 2015 18:52:30 -0000
--089e01537ed8634fab051ca905b5
Content-Type: text/plain; charset=UTF-8
On Thu, Aug 6, 2015 at 8:43 PM, Michael Naber <mickeybob@gmail.com> wrote:
> How many nodes are necessary to ensure sufficient network reliability?
> Ten, a hundred, a thousand? At what point do we hit the point of
> diminishing returns, where adding extra nodes starts to have negligible
> impact on the overall reliability of the system?
>
It's not about reliability. There are plenty of nodes currently for
synchronization and other network functions.
It's about reduction of trust. Running a full node and using it verify your
transactions is how you get personal assurance that everyone on the network
is following the rules. And if you don't do so yourself, the knowledge that
others are using full nodes and relying on them is valuable. Someone just
running 1000 nodes in a data center and not using them for anything does
not do anything for this, it's adding network capacity without use.
That doesn't mean that the full node count (or the reachable full node
count even) are meaningless numbers. They are an indication of how hard it
is (for various reasons) to run/use a full node, and thus provide feedback.
But they are not the goal, just an indicator.
--
Pieter
--089e01537ed8634fab051ca905b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Aug 6, 2015 at 8:43 PM, Michael Naber <span dir=3D=
"ltr"><<a href=3D"mailto:mickeybob@gmail.com" target=3D"_blank">mickeybo=
b@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">How many n=
odes are necessary to ensure sufficient network reliability? Ten, a hundred=
, a thousand? At what point do we hit the point of diminishing returns, whe=
re adding extra nodes starts to have negligible impact on the overall relia=
bility of the system?=C2=A0</div></blockquote><div><br></div><div>It's =
not about reliability. There are plenty of nodes currently for synchronizat=
ion and other network functions.<br><br></div><div>It's about reduction=
of trust. Running a full node and using it verify your transactions is how=
you get personal assurance that everyone on the network is following the r=
ules. And if you don't do so yourself, the knowledge that others are us=
ing full nodes and relying on them is valuable. Someone just running 1000 n=
odes in a data center and not using them for anything does not do anything =
for this, it's adding network capacity without use.<br><br></div><div>T=
hat doesn't mean that the full node count (or the reachable full node c=
ount even) are meaningless numbers. They are an indication of how hard it i=
s (for various reasons) to run/use a full node, and thus provide feedback. =
But they are not the goal, just an indicator.<br><br>-- <br></div><div>Piet=
er<br><br></div></div></div></div>
--089e01537ed8634fab051ca905b5--
|
