Quote from: achow101 on February 01, 2016, 12:48:32 AM

Quote from: .anto. on January 31, 2016, 11:09:12 PM

Quote from: 2112 on January 31, 2016, 10:51:18 PM

You clearly already know everything and don't need any help. Sorry to disturb you. Have a nice day!

Please don't get me wrong. If I knew the reasons of the problem, I would not ask the question in the first place.

However, you didn't actually answer my main question, especially on why Bitcoin node does not automatically connect to the available IPv6 peers while I can manually force it to connect to the IPv6 peers.

It has to do with how node discovery works. Your node has an internal database of nodes that it will try to connect to. That database is built by nodes that you have previously connected to (so it will include your IPv6 peers from the past) and nodes that your peers have announced to you. Given that you have only connected to a few IPv6 nodes, then your database of available IPv6 nodes is probably very small. Since you can only have 8 total outgoing connections, your node is unable to connect to other IPv6 nodes that it knows about once all 8 connections are taken. After that, you just have to wait for other IPv6 nodes to connect to you, and you have no control over that whatsoever. All you can do is hope that your peers announce you to its peers and that your IP address makes it onto a DNS seed so that new nodes may be able to see your IPv6 Address and connect to you.

Basically it all really has to do with how there are significantly less IPv6 nodes than there are IPv4 nodes and that the addresses of those IPv6 nodes is not propagated through the network.

To get more IPv6 nodes, you could force your node to only accept IPv6 connections or force it to get peers from the DNS seed which will probably return more IPv6 nodes for you to connect to.

Thanks for your comment. That makes sense to me.

I think the fundamental problem is that, Bitcoin software only allows maximum 8 outbound connections regardless how many available IP addresses on the node. A part from obsolete implementation, i.e. based on only IPv4 network, I think the intention is possibly also to avoid bad nodes with multiple IP addresses flooding the network.

Due to that 8 outbound connections limitation, it is quite likely that my nodes always connect to IPv4 peers first and they will be quite fast occupying the whole 8 outbound connection slots. For the same reason, the likelihood for my nodes to get IPv6 peers to connect to them is also quite low as all of those IPv6 peers experience the same issue, i.e. 8 outbound connections limitation, unless they are solely running on IPv6. I think this is what causing the propagation of IPv6 nodes into the whole network very slow.

I can easily change the MAX_OUTBOUND_CONNECTIONS on net.cpp and re-compile my bitcoind. But I am quite sure that will not solve the problem, because my nodes will first connect to the available IPv4 peers and occupy the whole outbound connection slots again.

I think the solution is to separate the maximum outbound connections per IP address types. So that each IPv4 and IPv6 addresses individually get maximum 8 outbound connections as they are clearly on separate networks. For this reason I raised this feature request. Unfortunately, I am not a hard core programmer otherwise I would fork Bitcoin, create a patch and pull request it.