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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1WmJFk-0000u8-9L
for bitcoin-development@lists.sourceforge.net;
Mon, 19 May 2014 08:49:00 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.180 as permitted sender)
client-ip=209.85.213.180; envelope-from=laanwj@gmail.com;
helo=mail-ig0-f180.google.com;
Received: from mail-ig0-f180.google.com ([209.85.213.180])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WmJFi-0002IF-Uc
for bitcoin-development@lists.sourceforge.net;
Mon, 19 May 2014 08:49:00 +0000
Received: by mail-ig0-f180.google.com with SMTP id c1so3230447igq.7
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 May 2014 01:48:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.85.18 with SMTP id d18mr14839247igz.42.1400489332760;
Mon, 19 May 2014 01:48:52 -0700 (PDT)
Received: by 10.64.22.168 with HTTP; Mon, 19 May 2014 01:48:52 -0700 (PDT)
In-Reply-To: <CA+8=xu+GPykmKdAjxLdRA3QoCPR8azervT9uO-GVraNowAb49g@mail.gmail.com>
References: <CA+8=xu+GPykmKdAjxLdRA3QoCPR8azervT9uO-GVraNowAb49g@mail.gmail.com>
Date: Mon, 19 May 2014 10:48:52 +0200
Message-ID: <CA+s+GJDphJ5yetm7kQyGrsLWfhXjz1TtgF8kp4BaLaFWLJf9rg@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= <rme@i-rme.es>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WmJFi-0002IF-Uc
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] About the small number of bitcoin 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, 19 May 2014 08:49:00 -0000
On Sun, May 18, 2014 at 7:43 PM, Ra=C3=BAl Mart=C3=ADnez <rme@i-rme.es> wro=
te:
> About the small number of bitcoin nodes:
> Hi, I read the message that Mike Hearn sent to this mailing list some day=
s
> ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes.
>
> As an owner of two Bitcoin Nodes, one in my home computer and one in a
> dedicated server, I believe I can contribute with some of my thoughts and
> ideas:
>
> - Allow users to view the bandwith used by Bitcoin Core:
> This is available in the Bitcoin Core GUI (btw, when the computer is
> restarted the data gets reseted) but I cant find it in the bitcoind
> commandline
That's also possible through the RPC. See "getnettotals". You can also
get stats per peer in "getpeerinfo".
I also suggest looking at Jameson Lopp's Statoshi work
(http://statoshi.info) if you like graphs and more detailed stats.
> - Educate users about the correct setup of a bitcoin node:
> Add a page in the bitcoin.org website with a tutorial about running Bitco=
in
> Core with the ports opened, about runing bitcoind, etc. This guide shoud =
not
> be for regular users but for advanced ones.
Yes, such a document would be very welcome.
Maybe coordinate with Sa=C3=AFvann Carignan or David Harding, it could be
part of their bitcoin documentation project.
> - bitcoind and Bitcoin Core should create a bitcoin.conf file on the firs=
t
> start:
> The first time the software should create a default config file with a
> random RCP password and username (user can change it later) and the confi=
g
> file should be commented so the user can know how to change configuration=
s.
> This is very useful in setups without GUI, for example in Ubuntu Server.
I agree with you that a default configuration file is useful,
*however* this does not need to be created by the daemon.
The idea would be to make bitcoind and its data and configuration
system-wide. See https://github.com/bitcoin/bitcoin/issues/4124
A daemon should not even have write access to its own configuration
files. To follow the example of apache, tor, and such the distribution
installs a default configuration file which the user can adapt.
> - bitcoind and Bitcoin Core should be in Linux repos:
> People want to type "yum install bitcoind" or "apt-get install bitcoind" =
and
> install bitcoin. No one wants to follow a tutorial made by somewho saying
> that you have to add external repos to install bitcoin in your server.
> For example Electrum has been added to Ubuntu software center recently.
> Bitcoin Core an bitcoind should be on CentOS, Debian, Ubuntu and Ubuntu
> Server repos.
This sounds good, but as usual the practice is much uglier.
Bitcoind was part of the Ubuntu default repos for a while, but they
don't upgrade versions as we need to. This resulted in Ubuntu 12.04
stable being stuck with 0.3.xx forever. It would be even worse for
Debian Stable, which has even older versions of packages.
So right now we need you to add the PPA to get the package for Ubuntu.
This is only a small extra step.
This has to be determined per distribution, though. In some distros
this may be perfectly possible. This is just another place where the
project is completely dependent on volunteers.
> - Create a "grafical interface" for bitcoind on Linux servers:
> Create a command, for example "bitcoind show" that shows a nice summary i=
n
> your Terminal (Console) with all the data that a node administrator wants=
to
> know.
> When I say "grafical interface" I mean like "top" command, an interface m=
ade
> out of characters in ASCII.
Sounds like a fun project for someone in Python. Most of the
information is already available through RPC (and if not, request
it!).
Some hacking with ncurses could quickly make a decent tool here. It
could be packaged with bitcoin itself but that's not necessary. For
example Tor has the tool 'arm' which is a separate package.
You may want to talk with Shawn Wilkinson he has some ideas in this
direction. See also the issue
https://github.com/bitcoin/bitcoin/issues/3122 .
> - Split Bitcoin Wallet from Bitcoin Node:
> I believe that this is planned, some people want to help the network and
> others want to keep a wallet, someones want both.
> With bitcoind you can use the option "disablewallet=3D1" that allows to s=
ave
> some memory.
Running the node without wallet is already possible since 0.9.0 in two ways=
:
- ./configure --disable-wallet when compiling
- run with -disablewallet (as you say)
This works both for the GUI and the daemon. You can use the resulting
node-only instance ("edge router") with any existing SPV wallet.
There are plans to split off the wallet so that it can run separately,
but I wouldn't be holding my breath.
It feels to me that the general direction things are going in is that
other wallet projects are advancing much faster than Bitcoin Core's
wallet and people will likely switch to other wallet projects for
wallet functionality. Bitcoin Core is moving to an edge router role.
I'm happy to be proven wrong here and would like to see someone work
on bitcoind's wallet, but with the current development resources we
have to focus on a what is most urgent: maintaining and improving the
infrastructure.
> - Inform users if 8333 port is closed:
> That should be more visible, I dont mean an alert or warning but some ico=
n.
Yes, it would be great of connectivity and proxy problems were
signaled in some way.
Detecting whether your port is closed from the outside is an imprecise
art at most, though, as it relies on information from others.
A first step could be showing the number of incoming and outgoing
connections separately in getnetworkinfo. If you have no incoming
connections after a while you can be fairly sure that there is no
outward connectivity.
> - Keep connections if bitcoind is restarted:
> I noticed that if I restart bitcoind (to apply new config) my reset to 0 =
and
> take some hours to rise up to ~40. I believe that my peers should notice
> that I am down for less than ~15 minutes and try to connect again faster.
What incentive do peers have to reconnect to you specifically? The
nature of a P2P network is that nodes are interchangeable. If a node
fails or kicks them, they'll just try the next node in the list.
Sometimes that will be you, sometimes it will not.
Wladimir
|
