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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WX8kc-0008TK-5V
for bitcoin-development@lists.sourceforge.net;
Mon, 07 Apr 2014 12:34:10 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.171 as permitted sender)
client-ip=209.85.214.171; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f171.google.com;
Received: from mail-ob0-f171.google.com ([209.85.214.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WX8kb-0005ZI-Bm
for bitcoin-development@lists.sourceforge.net;
Mon, 07 Apr 2014 12:34:10 +0000
Received: by mail-ob0-f171.google.com with SMTP id wn1so6487273obc.16
for <bitcoin-development@lists.sourceforge.net>;
Mon, 07 Apr 2014 05:34:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.229.228 with SMTP id st4mr34678007oec.16.1396874044049;
Mon, 07 Apr 2014 05:34:04 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Mon, 7 Apr 2014 05:34:03 -0700 (PDT)
In-Reply-To: <CAPg+sBhL+Lr_noM7hVB4w-tvX0LLK2bKbQTzAw=4WswyxNGboQ@mail.gmail.com>
References: <CANEZrP2rgiQHpekEpFviJ22QsiV+s-F2pqosaZOA5WrRtJx5pg@mail.gmail.com>
<534297B8.4060506@gmail.com>
<CAPg+sBhL+Lr_noM7hVB4w-tvX0LLK2bKbQTzAw=4WswyxNGboQ@mail.gmail.com>
Date: Mon, 7 Apr 2014 14:34:03 +0200
X-Google-Sender-Auth: 82IpVrEHP4Haq83z3MVHSiBUKCk
Message-ID: <CANEZrP2bbFordbKdTWnMuCx0yQpL1D5-=_mK6VXPGB9ogDLDDw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11362fb0310f8904f673151a
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WX8kb-0005ZI-Bm
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?
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: Mon, 07 Apr 2014 12:34:10 -0000
--001a11362fb0310f8904f673151a
Content-Type: text/plain; charset=UTF-8
>
> In my opinion, the number of full nodes doesn't matter (as long as
> it's enough to satisfy demand by other nodes).
>
Correct. Still, a high number of nodes has a few other benefits:
1) The more nodes there are, the cheaper it should be to run each one,
given that the bandwidth and CPU for serving the chain will be spread over
more people.
2) It makes Bitcoin *seem* bigger, more robust and more decentralised,
because there are more people uniting to run it. So there's a psychological
benefit.
Also, we don't have a good way to measure capacity vs demand at the moment.
Whether we have enough capacity is rather a shot in the dark right now.
> What matters is how hard it is to run one.
>
Which is why I'm interested to learn the reason behind the drop. Is it
insufficient interest, or is running a node too painful?
For this purpose I'd like to exclude people running Bitcoin Core on laptops
or non-dedicated desktops. I don't think full nodes will ever make sense
for consumer wallets again, and I see the bleeding off of those people as
natural and expected (as Satoshi did). But if someone feels it's too hard
to run on a cheap server then that'd concern me.
> My own network crawler (which feeds my DNS seeder) hasn't seen any
> significant drop
It would be good to explain the difference, but I suspect your definition
of "well reachable" excludes people running Core at home. From the diurnal
cycle we see in Addy's graphs it's clear some nodes are being shut down
when people go to bed. So if we have 6000 nodes on servers and 2000 at
home, then I'd expect Addy's graphs and yours to slowly come into alignment
as people give up using Core as a consumer wallet.
--001a11362fb0310f8904f673151a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"">In my opinion, the number of ful=
l nodes doesn't matter (as long as<br>
</div>
it's enough to satisfy demand by other nodes).<br></blockquote><div><br=
></div><div>Correct. Still, a high number of nodes has a few other benefits=
:</div><div><br></div><div>1) The more nodes there are, the cheaper it shou=
ld be to run each one, given that the bandwidth and CPU for serving the cha=
in will be spread over more people.</div>
<div><br></div><div>2) It makes Bitcoin <i>seem</i> bigger, more robust and=
more decentralised, because there are more people uniting to run it. So th=
ere's a psychological benefit.</div><div><br></div><div>Also, we don=
9;t have a good way to measure capacity vs demand at the moment. Whether we=
have enough capacity is rather a shot in the dark right now.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">What matters is how hard it=
is to run one.<br></blockquote><div><br></div><div>Which is why I'm in=
terested to learn the reason behind the drop. Is it insufficient interest, =
or is running a node too painful?</div>
<div><br></div><div>For this purpose I'd like to exclude people running=
Bitcoin Core on laptops or non-dedicated desktops. I don't think full =
nodes will ever make sense for consumer wallets again, and I see the bleedi=
ng off of those people as natural and expected (as Satoshi did). But if som=
eone feels it's too hard to run on a cheap server then that'd conce=
rn me.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">My own network crawler (which feeds my DNS seeder) hasn'=
;t seen any<br></div>
significant drop</blockquote><div><br></div><div>It would be good to explai=
n the difference, but I suspect your definition of "well reachable&quo=
t; excludes people running Core at home. From the diurnal cycle we see in A=
ddy's graphs it's clear some nodes are being shut down when people =
go to bed. So if we have 6000 nodes on servers and 2000 at home, then I'=
;d expect Addy's graphs and yours to slowly come into alignment as peop=
le give up using Core as a consumer wallet.</div>
</div></div></div>
--001a11362fb0310f8904f673151a--
|
