help with finding issues in a modifcation of Bitcoin core

[achow101_alt]

I've created a modification of Bitcoin core that is like getaddr.bitnodes.io, but is a full node. It records the ip address from an addr message and then connects to each node in the list. However, I have had some problems and need some help diagnosing the issues. The source is here: https://github.com/achow101/fully-connected-bitcoin.

I have three problems currently:
1) Every so often, about 20-ish hours, the node will abort and give some error about "Unable to Open the Database" (I will update this post with the exact error next time it happens).

2) When I run getnetworkinfo from bitcoin-cli, I get this:
 

Code:

{
    "version" : 109900,
    "subversion" : "/Satoshi:0.10.99/",
    "protocolversion" : 70002,
    "localservices" : "0000000000000001",
    "timeoffset" : -1,
    "connections" : 646,
    "networks" : [
        {
            "name" : "ipv4",
            "limited" : false,
            "reachable" : false,
            "proxy" : "",
            "proxy_randomize_credentials" : false
        },
        {
            "name" : "ipv6",
            "limited" : false,
            "reachable" : false,
            "proxy" : "",
            "proxy_randomize_credentials" : false
        },
        {
            "name" : "onion",
            "limited" : false,
            "reachable" : false,
            "proxy" : "",
            "proxy_randomize_credentials" : false
        }
    ],
    "relayfee" : 0.00001000,
    "localaddresses" : [
    ]
}

It should have reachable in ipv4 as true and localaddresses should have atleast one ip address.

3) I have this on Travis-CI with Bitcoin core's default travis.yml file. It always errors everytime Travis builds it, and I don't know why. The travis page is here: https://travis-ci.org/achow101/fully-connected-bitcoin

Help would be greatly appreciated for any of these three issues.

Also, the software is being run on two Ubuntu 15.04 VMs, one at home with 3 cores and 4 GB of RAM, the other on Google cloud with 2 cores and 7.5 GB RAM. I am building and running bitcoind from terminal.

[1713909288]

1713909288

[1713909288]

1713909288

[1713909288]

1713909288

[1713909288]

1713909288

[cr1776]

The first thing that jumps out at me is whether you have increased the number of file descriptors available. And if you know the number 15.04 defaults to.

It may not be related but 646 connections, it is something to check.

[achow101_alt]

The first thing that jumps out at me is whether you have increased the number of file descriptors available. And if you know the number 15.04 defaults to.

It may not be related but 646 connections, it is something to check.

Actually, that might be the answer to number 1. I have not increased the limits, and Ubuntu has a soft limit of 1024 files per user, and Bitcoin usually aborts around 1000 nodes connected. It aborts because it cannot open the database, which might be because the limit prevents it from opening another file. I will increase the limit and see what happens.

[gmaxwell]

Achow101, you are basically asking for help to abuse the network.  Other people are not providing connectivity to you so that you can aggressively use up their resources and monitor their activity. Worse-- you are aggressively connecting to hosts without understanding software engineering well enough to avoid your own system failing-- how do you know that you're not also causing harm to those other hosts?  I hope that other people who understand the nature of the failure you're experiencing will also choose to not assist, sorry.  Please reconsider what you are doing.

[achow101_alt]

How does this abuse the network? Since it is a full node, wouldn't it help the network because it can provide data to all of the nodes that it connects to?

[spin]

You are using open slots on other hosts that could be used by people who need to sync.

[achow101_alt]

You are using open slots on other hosts that could be used by people who need to sync.

So you are saying that bitnodes abuses the network since it takes up a connection slot on all nodes.

What I fail to understand is how my node abuses the network, because even though it takes up a connection slot, it still has the full blockchain and can relay blocks and transactions. It is a full node

[bitsolutions]

Achow101, you are basically asking for help to abuse the network.  Other people are not providing connectivity to you so that you can aggressively use up their resources and monitor their activity. Worse-- you are aggressively connecting to hosts without understanding software engineering well enough to avoid your own system failing-- how do you know that you're not also causing harm to those other hosts?  I hope that other people who understand the nature of the failure you're experiencing will also choose to not assist, sorry.  Please reconsider what you are doing.

I understand the reasoning behind this but I don't agree with how it is being handled by the core developers. The core developers worry that there won't be enough available inbound connections on nodes if too many people are establishing more than 8 outbound connections.

I don't think putting arbitrary limits into Bitcoin Core is a good idea since it forces others to maintain their own fork if they end up in a situation where these arbitrary limits are not desired.

The core developers have essentially caused fragmentation of Bitcoin Core because of this issue. They would rather use FUD to keep people from making these modifications instead of working with them to solve the underlying issues.

[spin]

You are using open slots on other hosts that could be used by people who need to sync.

So you are saying that bitnodes abuses the network since it takes up a connection slot on all nodes.

What I fail to understand is how my node abuses the network, because even though it takes up a connection slot, it still has the full blockchain and can relay blocks and transactions. It is a full node

In my mind:
* It takes up a connection slot on each node meaning one less node can connect to that node.
* It decreases privacy of nodes.

To quote the experts (from here: http://bitcoin.stackexchange.com/a/8140)

Bitcoin by default will not make more than 8 outgoing connections, and -maxconnections only controls how many incoming connections you allow. Feel free to set this higher, but it will take time before others connect to you in large numbers.

Please don't change [outbound connections], as there is no need. Connectable peers on the network are a scarce resource, and essential to the decentralization. If people go try connect to all of them like some sites do, we'll very quickly run out.

In case you're a merchant or miner, you perhaps want to set up a few fixed connections to trusted others (see the -addnode command line/config option), but having more connections does not mean stronger verification (the reference client always verifies everything) or even faster relaying (as you'll slow down by distributing new blocks and transactions to all your peers). It is mostly a matter of providing a server to the network.

[spin]

I understand the reasoning behind this but I don't agree with how it is being handled by the core developers. The core developers worry that there won't be enough available inbound connections on nodes if too many people are establishing more than 8 outbound connections.

So you agree.

I don't think putting arbitrary limits into Bitcoin Core is a good idea since it forces others to maintain their own fork if they end up in a situation where these arbitrary limits are not desired.

Well if you want to do something different, you know, you have to actually do it? 

The core developers have essentially caused fragmentation of Bitcoin Core because of this issue. They would rather use FUD to keep people from making these modifications instead of working with them to solve the underlying issues.

What underlying issues? 

The core developers have essentially caused fragmentation of Bitcoin Core because of this issue. They would rather use FUD to keep people from making these modifications instead of working with them to solve the underlying issues.

The core developers did not change the settings.  The core developers even recommend people to not change it.  How are they *causing* fragmentation.

[bitsolutions]

You are using open slots on other hosts that could be used by people who need to sync.

So you are saying that bitnodes abuses the network since it takes up a connection slot on all nodes.

What I fail to understand is how my node abuses the network, because even though it takes up a connection slot, it still has the full blockchain and can relay blocks and transactions. It is a full node

In my mind:
* It takes up a connection slot on each node meaning one less node can connect to that node.
* It decreases privacy of nodes.

To quote the experts (from here: http://bitcoin.stackexchange.com/a/8140)

Bitcoin by default will not make more than 8 outgoing connections, and -maxconnections only controls how many incoming connections you allow. Feel free to set this higher, but it will take time before others connect to you in large numbers.

Please don't change [outbound connections], as there is no need. Connectable peers on the network are a scarce resource, and essential to the decentralization. If people go try connect to all of them like some sites do, we'll very quickly run out.

In case you're a merchant or miner, you perhaps want to set up a few fixed connections to trusted others (see the -addnode command line/config option), but having more connections does not mean stronger verification (the reference client always verifies everything) or even faster relaying (as you'll slow down by distributing new blocks and transactions to all your peers). It is mostly a matter of providing a server to the network.

It doesn't really make a difference for privacy if those who want to connect to a lot of nodes can modify their clients.
Even with a node not behind NAT its hard to get over 50 connections even when the connection limit is set much higher so I don't think we all that close to being up against the limit.

I understand the reasoning behind this but I don't agree with how it is being handled by the core developers. The core developers worry that there won't be enough available inbound connections on nodes if too many people are establishing more than 8 outbound connections.

So you agree.

I don't think putting arbitrary limits into Bitcoin Core is a good idea since it forces others to maintain their own fork if they end up in a situation where these arbitrary limits are not desired.

Well if you want to do something different, you know, you have to actually do it? 

The core developers have essentially caused fragmentation of Bitcoin Core because of this issue. They would rather use FUD to keep people from making these modifications instead of working with them to solve the underlying issues.

What underlying issues? 

The core developers have essentially caused fragmentation of Bitcoin Core because of this issue. They would rather use FUD to keep people from making these modifications instead of working with them to solve the underlying issues.

The core developers did not change the settings.  The core developers even recommend people to not change it.  How are they *causing* fragmentation.

I understand their reason, I don't agree with it however.
The bitcoin core node is not good at handling certain amounts of connections, there are improvements there that could help.
The fragmentation is because of the need for certain users to override the limit, if it was a config flag it wouldn't be as bad.

[spin]

The fragmentation is because of the need for certain users to override the limit, if it was a config flag it wouldn't be as bad.

Well if you had config flag more people would change it which means more people running with different settings which means more "fragmentation"...

[bitsolutions]

The fragmentation is because of the need for certain users to override the limit, if it was a config flag it wouldn't be as bad.

Well if you had config flag more people would change it which means more people running with different settings which means more "fragmentation"...

A config flag allows people to use different settings without using a different Bitcoin Core, so it would reduce forks(fragmentation). The point of config flags is to be able to run the same software with different settings.

[kcud_dab]

You are using open slots on other hosts that could be used by people who need to sync.

So you are saying that bitnodes abuses the network since it takes up a connection slot on all nodes.

What I fail to understand is how my node abuses the network, because even though it takes up a connection slot, it still has the full blockchain and can relay blocks and transactions. It is a full node

If there are only a few who make this if not harmful, but if there are many of people (like >150) doing that all nodes would have more than 150 connections used for this and no more slot to serve the others (default settings is 125 peers max). With a bigger number maybe it wouldn't be possible to run a node with low hardware because there would be at least 500 guys who would try to connect to your node?

[spin]

The fragmentation is because of the need for certain users to override the limit, if it was a config flag it wouldn't be as bad.

Well if you had config flag more people would change it which means more people running with different settings which means more "fragmentation"...

A config flag allows people to use different settings without using a different Bitcoin Core, so it would reduce forks(fragmentation). The point of config flags is to be able to run the same software with different settings.

But there is still a real difference there.  One is via a code & compile and the other is via a config.  Whichever way there is still difference there. 

[bitsolutions]

But there is still a real difference there.  One is via a code & compile and the other is via a config.  Whichever way there is still difference there. 

Yes, but as it is people use different config options when running Bitcoin Core and those are not considered to cause fragmentation, making this change via config would allow for people to use different outbound connection count options without having to maintain and test their own fork.

Having to maintain and compile a separate fork means they have to run code that is less well tested than it could be especially since the core developers actively refuse to provide any assistance and encourage others to not help people making these modifications.

[gmaxwell]

Having to maintain and compile a separate fork means they have to run code that is less well tested than it could be especially since the core developers actively refuse to provide any assistance and encourage others to not help people making these modifications.

Yes, we refuse to help people who are objectively attacking the network, wasting other users resources and harming their privacy.  Beyond it being harmful to bitcoin and bitcoin's users, knowingly assisting in this activity might make a participant a target of torts from harmed parties or even subject to criminal prosecution in jurisdictions with expansive computer crime laws.

Why people think that its casually okay to attack the network, and think there is any chance that standard Bitcoin software would come with a user exposed switch to make a single node try to use a substantial fraction of the network's total capacity is beyond me. That isn't going to happen; and users should be highly wary of the competence or ethics anyone who ships software that does that (after all, if might makes right then why not also have the software backdoor your computer?-- if it's possible to do, it's okay, by the logic presented here, no?). The fact that someone don't have any ethical qualms about the resources of other people that they waste or the privacy harm most of these efforts are intended to create, nor do they have the most basic software engineering experience to understand the requirements and ramifications of a software change; doesn't create any obligation on my part to compromise my own integrity and aid in these activities.

And sure, sufficiently software-competent people can technically modify the software or write their own which behaves aggressively; but fewer people doing it is an improvement (less resources wasted) even if it is not possible to prevent it completely. This isn't the only thing that is done with respect to this kind of abuse, like in many things a layered response is important, the first is avoiding cases where thoughtful and ethical people do not accidentally abuse the network-- and making it clear what behavior is abusive--, then social, technical, and legal measures can be employed against those who remain. (All of which are continually being worked on by many people).

[bitsolutions]

Yes, we refuse to help people who are objectively attacking the network, wasting other users resources and harming their privacy.  Beyond it being harmful to bitcoin and bitcoin's users, knowingly assisting in this activity might make a participant a target of torts from harmed parties or even subject to criminal prosecution in jurisdictions with expansive computer crime laws.

Why people think that its casually okay to attack the network, and think there is any chance that standard Bitcoin software would come with a user exposed switch to make it try to use a substantial fraction of the network's total capacity is beyond me.

I think this is a complete overreaction, overriding Bitcoin Core defaults like this is not something that is illegal.

Since there are people who are going to override this anyways I think its better for those users to use tested software than being forced to use their own fork.

That isn't going to happen; and users should be highly wary of the competence or ethics anyone who ships software that does that (after all, if might makes right then why not also have the software backdoor your computer?-- if it's possible to do, it's okay, by the logic presented here, no?). The fact that someone don't have any ethical qualms about the resources of other people that they waste or the privacy harm most of these efforts are intended to create, nor do they have the most basic software engineering experience to understand the requirements and ramifications of a software change; doesn't create any obligation on my part to compromise my own integrity and aid in these activities.

And sure, sufficiently software-competent people can technically modify the software or write their own which behaves aggressively; but fewer people doing it is an improvement (less resources wasted) even if it is not possible to make prevent it completely. This isn't the only thing that is done with respect to this kind of abuse, like in many things a layered response is important, the first is avoiding cases where thoughtful and ethical people do not accidentally abuse the network-- and making it clear what behavior is abusive--, then social, technical, and legal measures can be employed against those who remain. (All of which are continually being worked on by many people).

This isn't a resource we are really all that close to using up, run a full node and see how close to 125 inbound connections you can get, you usually only get 20-30, these are available resources and using them is not something I consider to be wasting. I don't agree that using FUD is the right way to go about solving issue.

[gmaxwell]

Since there are people who are going to override this anyways I think its better for those users to use tested software than being forced to use their own fork.

I disagree. Most of the people who think doing this is okay are not technically competent enough to make the change, -- this is why making the change is hard for them. The result is that the software crashes for the (as we see in this thread), and they adopt a new approach-- sometimes one which is less uncivilized. To whatever extent that people do successfully do so, having more users of the software able to make modifications is a virtue. There are parts of the system where diversity is a hazard, but thats generally limited to the consensus parts.

you usually only get 20-30, these are available resources and using them is not something I consider to be wasting.

Thats only true when you are on colocation subnets which are already saturated with nodes. A more common numbers is 80+ and we've had instances of widespread fullness in the past (resulting in problems with nodes getting online). If you would bother to do simple arithmetic you would conclude that even if only 20 were typically used (which isn't the case), it would only take about 100 parties total running "connect to everyone" settings to completely saturate it.  Moreover, what you "consider" or not is irrelevant. It's other people's resources you would be consuming, usually for reasons which are highly adverse to their interests (e.g. spying on them and other users of Bitcoin)... beyond the spying activity, the second most common reason for wanting to do this is also ill advised (some people erroneously believe more connections improves block propagation, when in fact it too many slows it down).  

[bitsolutions]

Since there are people who are going to override this anyways I think its better for those users to use tested software than being forced to use their own fork.

I disagree. Most of the people who think doing this is okay are not technically competent enough to make the change, -- this is why making the change is hard for them. The result is that the software crashes for the (as we see in this thread), and they adopt a new approach-- sometimes one which is less uncivilized. To whatever extent that people do successfully do so, having more users of the software able to make modifications is a virtue. There are parts of the system where diversity is a hazard, but thats generally limited to the consensus parts.

you usually only get 20-30, these are available resources and using them is not something I consider to be wasting.

Thats only true when you are on colocation subnets which are already saturated with nodes. A more common numbers is 80+ and we've had instances of widespread fullness in the past (resulting in problems with nodes getting online). If you would bother to do simple arithmetic you would conclude that even if only 20 were typically used (which isn't the case), it would only take about 100 parties total running "connect to everyone" settings to completely saturate it.  Moreover, what you "consider" or not is irrelevant. It's other people's resources you would be consuming, usually for reasons which are highly adverse to their interests (e.g. spying on them and other users of Bitcoin)... beyond the spying activity, the second most common reason for wanting to do this is also ill advised (some people erroneously believe more connections improves block propagation, when in fact it too many slows it down).  

So why not have low priority outbound connections or something like that(basically any outbound connections above 8 are marked as low priority)? These could be connections that nodes will drop if regular priority incoming connections are competing for space. That could be a way to implement this responsibly so that low priority connections only use excess slots and won't compete for space with regular priority connections.