diff options
| author | Wladimir <laanwj@gmail.com> | 2014-05-19 10:48:52 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-05-19 08:49:00 +0000 |
| commit | 014294a4033dbcbef1325ca77df37ddbceb5921b (patch) | |
| tree | b8a589b2e4b6dabf8a5e5084d7ac778c2367546d /aa | |
| parent | 6e2bb95c1e6bb167b8369ffafde23cf2ed7bb3f1 (diff) | |
| download | pi-bitcoindev-014294a4033dbcbef1325ca77df37ddbceb5921b.tar.gz pi-bitcoindev-014294a4033dbcbef1325ca77df37ddbceb5921b.zip | |
Re: [Bitcoin-development] About the small number of bitcoin nodes
Diffstat (limited to 'aa')
| -rw-r--r-- | aa/c4dbca6b64fca48e23320ae6d1dfc20c29898e | 216 |
1 files changed, 216 insertions, 0 deletions
diff --git a/aa/c4dbca6b64fca48e23320ae6d1dfc20c29898e b/aa/c4dbca6b64fca48e23320ae6d1dfc20c29898e new file mode 100644 index 000000000..d73b68c15 --- /dev/null +++ b/aa/c4dbca6b64fca48e23320ae6d1dfc20c29898e @@ -0,0 +1,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 + + |