About the small number of bitcoin nodes

About the small number of bitcoin nodes
2014-05-18 20:15 ` Raúl Martínez
                   ` (4 more replies)
  
From: Raúl Martínez @ 2014-05-18 17:43 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]

About the small number of bitcoin nodes:
Hi, I read the message that Mike Hearn sent to this mailing list some days
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, people that run nodes want to see the amount of GB that they
have "donated" to the network.

- Educate users about the correct setup of a bitcoin node:
Add a page in the bitcoin.org website with a tutorial about running Bitcoin
Core with the ports opened, about runing bitcoind, etc. This guide shoud
not be for regular users but for advanced ones.

- bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
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 config
file should be commented so the user can know how to change configurations.
This is very useful in setups without GUI, for example in Ubuntu Server.

- 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.

- Create a "grafical interface" for bitcoind on Linux servers:
Create a command, for example "bitcoind show" that shows a nice summary in
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
made out of characters in ASCII.

- 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=1" that allows to save
some memory.

- Inform users if 8333 port is closed:
That should be more visible, I dont mean an alert or warning but some icon.

- 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.

[-- Attachment #2: Type: text/html, Size: 3216 bytes --]

 permalink raw reply	[|nested]
2014-05-18 20:15 ` 
                   ` 
  
From: Raúl Martínez @ 2014-05-18 17:43 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]

About the small number of bitcoin nodes:
Hi, I read the message that Mike Hearn sent to this mailing list some days
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, people that run nodes want to see the amount of GB that they
have "donated" to the network.

- Educate users about the correct setup of a bitcoin node:
Add a page in the bitcoin.org website with a tutorial about running Bitcoin
Core with the ports opened, about runing bitcoind, etc. This guide shoud
not be for regular users but for advanced ones.

- bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
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 config
file should be commented so the user can know how to change configurations.
This is very useful in setups without GUI, for example in Ubuntu Server.

- 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.

- Create a "grafical interface" for bitcoind on Linux servers:
Create a command, for example "bitcoind show" that shows a nice summary in
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
made out of characters in ASCII.

- 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=1" that allows to save
some memory.

- Inform users if 8333 port is closed:
That should be more visible, I dont mean an alert or warning but some icon.

- 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.

[-- Attachment #2: Type: text/html, Size: 3216 bytes --]

 permalink raw reply	[|nested]
* 
  2014-05-18 17:43 [Bitcoin-development] About the small number of bitcoin nodes Raúl Martínez

  2014-05-19  7:11 ` 
                   ` 
  4 siblings, 0 replies; 15+ messages in thread
From: Raúl Martínez @ 2014-05-18 20:15 UTC (permalink / raw)
  Cc: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]

About the small number of bitcoin nodes:
Hi, I read the message that Mike Hearn sent to this mailing list some days
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, people that run nodes want to see the amount of GB that they
have "donated" to the network.

- Educate users about the correct setup of a bitcoin node:
Add a page in the bitcoin.org website with a tutorial about running Bitcoin
Core with the ports opened, about runing bitcoind, etc. This guide shoud
not be for regular users but for advanced ones.

- bitcoind and Bitcoin Core should create a bitcoin.conf file on the first
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 config
file should be commented so the user can know how to change configurations.
This is very useful in setups without GUI, for example in Ubuntu Server.

- 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.

- Create a "grafical interface" for bitcoind on Linux servers:
Create a command, for example "bitcoind show" that shows a nice summary in
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
made out of characters in ASCII.

- 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=1" that allows to save
some memory.

- Inform users if 8333 port is closed:
That should be more visible, I dont mean an alert or warning but some icon.

- 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.

Thanks for reading

[-- Attachment #2: Type: text/html, Size: 3064 bytes --]

^ permalink raw reply	[|nested] 15+ messages in thread
2014-05-19  7:11 ` Jeff Garzik

  2014-05-19 14:02   ` Scott Howard
  
From: Justus Ranvier @ 2014-05-19  7:25 UTC (permalink / raw)
  To: bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/19/2014 09:11 AM, Jeff Garzik wrote:
> Meh.  I like example configs, perhaps tuned by the distro.  If the 
> distro (_not_ Bitcoin Core upstream) chooses to install a
> bitcoin.conf in the proper location, that's up to them.
> 
> 
>> - bitcoind and Bitcoin Core should be in Linux repos:
> 
> Agreed with conditions: 1) The distro MUST let bitcoin devs dictate
> which dependent libs are shipped with / built statically into the
> bitcoin binaries/libs. 2) The distro MUST permit fresh updates even
> to older stable distros. 2) The maintainer(s) MUST be active, and
> follow bitcoin development, release status, etc. on a near-daily
> basis, be able to respond quickly if security issues arise, etc.

If we're talking about making bitcoind behave like a proper daemon,
then syslog support should be on the list.

Also, the option to store things in FHS-compliant directories (not
somewhere/.bitcoin)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTebHTAAoJEMP3uyY4RQ2170IIAMDcx5rj/ZlCTJTOJ2sFttFM
miK9t7oewJ73UpgvFniCUngfjk9Tt5knmskQYEMQ5C9Do/P3Deh1gF6MBBuuai5G
kDNDv51zMEqhwGcqGrPYFMV3NEnBEjullTMgJFvKJf1kZRo7uplwp+eUhILjgSY5
mZjLIUK8iKDNn+Pi8/2UetAvyaRibHAsAnkJnEeOoKAhxUbtzjgZsj08loCCmJrs
RleOTLgArdc33e1bwTTwsS9DDvF18RNTACglsc75Oz0ohHyc5U1A1hBfaRuyu6Fv
8BK+0KPg/zdBCnM1m3aueVukg9p3kIfB2VUVFBHBTo4CPMi91k6oldbfRHy8dXw=
=SjxO
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
* 
  2014-05-18 17:43 [Bitcoin-development] About the small number of bitcoin nodes Raúl Martínez
  2014-05-18 20:15 ` Raúl Martínez

  2014-05-19  7:25   ` Justus Ranvier
  2014-05-19 14:02   ` Scott Howard
  2014-05-19  8:48 ` 
                   ` 
  4 siblings, 2 replies; 15+ messages in thread
From: Jeff Garzik @ 2014-05-19  7:11 UTC (permalink / raw)
  To: Raúl Martínez;  Bitcoin Dev

On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez <rme@i-rme•es> wrote:
> - Allow users to view the bandwith used by Bitcoin Core:

+1 for the sake of transparency

HOWEVER, the impact on this feature RE user population is
unpredictable.  Users may see bigger than expected numbers, and switch
off their node.


> - Educate users about the correct setup of a bitcoin node:

+1

> - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first

Meh.  I like example configs, perhaps tuned by the distro.  If the
distro (_not_ Bitcoin Core upstream) chooses to install a bitcoin.conf
in the proper location, that's up to them.


> - bitcoind and Bitcoin Core should be in Linux repos:

Agreed with conditions:
1) The distro MUST let bitcoin devs dictate which dependent libs are
shipped with / built statically into the bitcoin binaries/libs.
2) The distro MUST permit fresh updates even to older stable distros.
2) The maintainer(s) MUST be active, and follow bitcoin development,
release status, etc. on a near-daily basis, be able to respond quickly
if security issues arise, etc.

Matt C seems to do a good job of this in Ubuntu PPA, I'm told.


> - Create a "grafical interface" for bitcoind on Linux servers:
> When I say "grafical interface" I mean like "top" command, an interface made
> out of characters in ASCII.

The best path for this is figure out what statistics you want to see,
and have bitcoind export those raw numbers to any willing consumer.
Then write your bitcoind-top on top of that.

> - Split Bitcoin Wallet from Bitcoin Node:

+1

In progress.  Disable-wallet support, at compile time or runtime, was
the first step.

> - Inform users if 8333 port is closed:

+1

> - 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.

No, you don't want this (and it's not possible in many cases anyway).

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



^ permalink raw reply	[|nested] 15+ messages in thread
2014-05-18 17:43 [Bitcoin-development] About the small number of bitcoin nodes Raúl Martínez
                   ` (2 preceding siblings ...)
  2014-05-19  8:48 ` Wladimir

  2014-05-19 12:15   ` Mike Hearn
  2014-05-19 12:44   ` Wladimir
  2014-06-30 10:16 ` Wladimir
  
From: Bjørn Øivind Bjørnsen @ 2014-05-19  9:26 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On 18/05/14 19:43, Raúl Martínez wrote:
> About the small number of bitcoin nodes:
> Hi, I read the message that Mike Hearn sent to this mailing list some
> days 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:
> 
> <snip some good ideas>

As an interested party not intimately familiar with the bitcoin codebase
who also spent some time setting up a node a while ago, I would like to
add one thing to the above list - network rate limiting.
When I first set up my node, I did not consider this until it started
eating all of my upstream bandwith (on an ADSL line that isn't so fun),
and I must admit I was a bit disappointed when I found that I would have
to set this up separately. An option to limit the upstream and
downstream network usage (like what tor or most torrent clients does)
would be useful.

On the note of the distro packages, I've so far been pretty happy with
the packages provided by Arch Linux - I have no idea if they build it
correctly (with the correct static libs and all), but it seems to work
fine for the edge router case.

Bjørn Øivind



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

 permalink raw reply	[|nested]
2014-05-19  8:48 ` Wladimir

  2014-05-19 10:47     ` Felipe Micaroni Lalli
  
From: Wladimir @ 2014-05-19 10:39 UTC (permalink / raw)
  To: Raúl Martínez;  Bitcoin Dev

On Mon, May 19, 2014 at 10:48 AM, Wladimir <laanwj@gmail•com> wrote:
>
> 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.

Regarding tor-arm, here are some screenshots:
https://www.atagar.com/arm/screenshots.php

It shows, among other things:
- bandwidth up/down graphs
- CPU usage
- debug logging (in real time)
- connected peers+statistics
- currently active configuration

Would be nice to have a similar tool for bitcoind.

Wladimir



 permalink raw reply	[|nested]
2014-05-19 10:39   ` Wladimir

  
From: Felipe Micaroni Lalli @ 2014-05-19 10:47 UTC (permalink / raw)
  To: Wladimir;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

Is the small number of bitcoin nodes a concern? If yes, why? What kind of attack can the network suffer? And where can we find statistical information about the full nodes running?

I guess the only effective incentive to keep a node running would be financial. A kind of proof of stake would be nice on bitcoin. But I have no idea how to begin with.



Felipe Micaroni Lalli

Walltime: https://walltime.info
Bitcoin Paranoid Android developer
PGP ID: 0x4c0afccfed5cde14
BTC: 1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N

On 19/05/2014, at 07:39, Wladimir <laanwj@gmail•com> wrote:

> On Mon, May 19, 2014 at 10:48 AM, Wladimir <laanwj@gmail•com> wrote:
>> 
>> 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.
> 
> Regarding tor-arm, here are some screenshots:
> https://www.atagar.com/arm/screenshots.php
> 
> It shows, among other things:
> - bandwidth up/down graphs
> - CPU usage
> - debug logging (in real time)
> - connected peers+statistics
> - currently active configuration
> 
> Would be nice to have a similar tool for bitcoind.
> 
> Wladimir
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2014-05-19  9:26 ` Bjørn Øivind Bjørnsen

  2014-05-19 12:24     ` Bjørn Øivind Bjørnsen
  2014-05-19 12:44   ` Wladimir
  
From: Mike Hearn @ 2014-05-19 12:15 UTC (permalink / raw)
  To: Bjørn Øivind Bjørnsen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

>
> As an interested party not intimately familiar with the bitcoin codebase
> who also spent some time setting up a node a while ago, I would like to
> add one thing to the above list - network rate limiting.


The problem is that this is easier said than done. Bitcoin Core won't
notice a remote peer is working but slow and switch to a faster one, and
even if it did, it'd just mean throttling your connection would cause all
remote nodes to give up and hit the other unthrottled peers even more.

The best way to implement this is to do chain pruning, so your node will
still try and shovel bytes as fast as possible, but it's limited by how
many bytes it has to shovel. Remote nodes that are pulling down the block
chain can then switch between nodes depending on what they have available
in order to try and avoid hitting one node too hard. Nodes that were
offline for a while and just catching up would prefer nodes that have less
of the chain.

It'd be great if someone could experiment with this. The first step is
extending the p2p protocol so addr broadcasts and version messages include
how much of the chain (counting blocks from the head?) the peer is willing
to serve, and then updating the downloading code so it tries to be smarter
about peer selection. Unfortunately all this work is sort of backed up
waiting for sipa to finish merging in headers-first downloading.

[-- Attachment #2: Type: text/html, Size: 1681 bytes --]

 permalink raw reply	[|nested]
2014-05-19 12:15   ` Mike Hearn

  2014-05-19 12:28       ` Mike Hearn
  
From: Bjørn Øivind Bjørnsen @ 2014-05-19 12:24 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On 19/05/14 14:15, Mike Hearn wrote:
>     As an interested party not intimately familiar with the bitcoin codebase
>     who also spent some time setting up a node a while ago, I would like to
>     add one thing to the above list - network rate limiting.
> 
> 
> The problem is that this is easier said than done. Bitcoin Core won't
> notice a remote peer is working but slow and switch to a faster one, and
> even if it did, it'd just mean throttling your connection would cause
> all remote nodes to give up and hit the other unthrottled peers even more.
> 

Does this mean that you can currently actively hurt the network by
adding a node with a very slow upstream / downstream? If so, what is the
recommended minimum amount of bandwidth you should allocate for a node?
I've already throttled mine with QoS based on the script in the contrib/
folder.

Bjørn Øivind



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

 permalink raw reply	[|nested]
2014-05-19 12:24     ` Bjørn Øivind Bjørnsen

  
From: Mike Hearn @ 2014-05-19 12:28 UTC (permalink / raw)
  To: Bjørn Øivind Bjørnsen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

>
> Does this mean that you can currently actively hurt the network by
> adding a node with a very slow upstream / downstream?


Well, I guess "hurting" the network is perhaps a bit dramatic. There are
already lots of ways the download process can go wrong and take days. Using
the torrent is much faster. But my understanding is that this will slow
down the bootstrap process for some people yes. Remote peers won't try and
download in parallel or anything like that.

[-- Attachment #2: Type: text/html, Size: 730 bytes --]

 permalink raw reply	[|nested]
2014-05-19  9:26 ` Bjørn Øivind Bjørnsen
  2014-05-19 12:15   ` Mike Hearn

  2014-05-19 12:53     ` Mike Hearn
  
From: Wladimir @ 2014-05-19 12:44 UTC (permalink / raw)
  To: Bjørn Øivind Bjørnsen;  Bitcoin Dev

On Mon, May 19, 2014 at 11:26 AM, Bjørn Øivind Bjørnsen
<bo.bjornsen@gmail•com> wrote:
> On 18/05/14 19:43, Raúl Martínez wrote:
>> <snip some good ideas>
>
> As an interested party not intimately familiar with the bitcoin codebase
> who also spent some time setting up a node a while ago, I would like to
> add one thing to the above list - network rate limiting.

There is already an (old) patch that implements that. It won't be
merged, though, until headers-first and parallel block download is in.
Only when the node can download blocks from multiple peers at once it
is really safe to allow limiting rates.

(sure - there are tricks to limit rates anyway, like the script in
contrib/qos, but to have it generally available the block download
needs to be more robust first)

Wladimir



 permalink raw reply	[|nested]
2014-05-19 12:44   ` Wladimir

  
From: Mike Hearn @ 2014-05-19 12:53 UTC ( / )
  To: Wladimir;  Bitcoin Dev



>
> (sure - there are tricks to limit rates anyway, like the script in
> contrib/qos, but to have it generally available the block download
> needs to be more robust first)


One thing we could consider as a short term solution (if headers
first+parallel downloading will take a while, which seems plausible) is to
add a service bit that says "I have chain data and am willing to Bloom
filter it for you, but I won't serve full block data", and then just
exclude all of those from the chain download logic. It should not be a deep
change to the code headers first is impacting, and would allow home users
who may have no tolerance for block chain uploads at all to still take part
and offer useful services to the network.

I know Pieter likes the idea of an "archival node" service bit, or
something like that. I'd been thinking that the stored chain height value
would be better, but perhaps we need to divorce "I have CPU and can filter"
from "I have bandwidth and can serve" more vigorously.
2014-05-19  7:11 ` Jeff Garzik
  2014-05-19  7:25   ` Justus Ranvier

  
From: Scott Howard @ 2014-05-19 14:02 UTC (permalink / raw)
  Cc: Bitcoin Dev

On Mon, May 19, 2014 at 3:11 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
> On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez <rme@i-rme•es> wrote:
>> - bitcoind and Bitcoin Core should be in Linux repos:
>
> Agreed with conditions:
> 1) The distro MUST let bitcoin devs dictate which dependent libs are
> shipped with / built statically into the bitcoin binaries/libs.
> 2) The distro MUST permit fresh updates even to older stable distros.
> 2) The maintainer(s) MUST be active, and follow bitcoin development,
> release status, etc. on a near-daily basis, be able to respond quickly
> if security issues arise, etc.
>
> Matt C seems to do a good job of this in Ubuntu PPA, I'm told.

Update:

(1) and (3) are doable, however, Debian and Ubuntu policies make (2)
very difficult (with the exception of security patches). Micha Bailey
and I worked to get bitcoin removed from Debian and Ubuntu stable
releases because they would not allow (2). There are other mechanisms
that could accomplish (2) (backports, volatile, and updates
repositories), however they are not enabled by default and require
user intervention.

Debian unstable does allow (2) since there is no release, and there is
a package in Debian unstable. That package is blocked from
transitioning to a stable release. We've also blacklisted it from
Ubuntu so that Ubuntu doesn't just autoimport and release the Debian
unstable package in an Ubuntu stable release.

Micha is also working to have all old versions of bitcoin removed from
previous released Ubuntu versions.

Matt C's PPA is the best way of getting (1-3) above on Ubuntu, and the
Debian unstable package is probably the best way of getting (1-3)
above in Debian. Both require users to add a line to their apt sources
list; the Debian package would also require apt pinning.

Regards,
Scott



 permalink raw reply	[|nested]
2014-05-18 17:43 [Bitcoin-development] About the small number of bitcoin nodes Raúl Martínez
                   ` (3 preceding siblings ...)
  2014-05-19  9:26 ` Bjørn Øivind Bjørnsen

  
From: Wladimir @ 2014-06-30 10:16 UTC (permalink / raw)
  To: Raúl Martínez;  Bitcoin Dev

> - Create a "grafical interface" for bitcoind on Linux servers:
> Create a command, for example "bitcoind show" that shows a nice summary in
> 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 made
> out of characters in ASCII.

FYI someone created this! It's still in the initial stages, I'm sure
the author could use some help to grow this into a full-functional
node admin tool.

https://github.com/azeteki/bitcoind-ncurses

Wladimir



 permalink raw reply	[|nested]