Thank you very much. Had never expected to get such an qualified answer AND a working proof of concept. I really appreciate this.
@DannyHamilton
Very well summarized and clearly explained. Thank you.
@starmyc
I will test it out. Thank you.
Topic: Query all peers from a network (Read 227 times)
Thank you. I don't want to connect to them. I just want to get a full list of all online nodes. Similar to that list from bitnodes.earn.com.
It's for a different network and therefore I would do this by my own.
It's for a different network and therefore I would do this by my own.
DannyHamilton described the way to do it. Following to this post, I wrote a quick and really dirty POC in golang to try out, and it works surprisingly well.
After a few minutes of runnign, it found out a list of possible ~30000 bitcoin nodes (a lot are down though), but that would be a good start to build your own software.
Code:
$ sqlite3 peers.db "SELECT count(*) FROM peers;"
31307
getaddr is NOT an API command. You can't use it via the API interface of your client.
getaddr is a communications message used over the connection between two clients. Therefore, to use it you will need to write software that emulates a client.
Your software will need to connect to a client and pretend to be a bitcoin node. The default port to connect to is 8333, but if you changed that in your configuration then just use whatever port you configured your client to operate on.
When your software connects, the first thing it will need to do is send the version message containing your version number, block count, and current time. The client generally will not acknowledge ANY other messages until this has been completed.
The client will send back a verack message and its own version message if it is accepting connections from your version. You will then need to respond with your own verack if you are accepting connections from that client's version.
Once you've completed that, you can send the getaddr message and the client should respond with 1 or more addr messages. The addr messages will be the list of IP addresses and ports that the client has either connected to or heard about from peers that it is connected to.
During this communication the client may send it's own requests to your software. To prevent the client disconnecting from you and banning you, you might need to respond appropriately to some of those requests.
Eventually you'll have a full list of all the IP addresses and ports that the client is currently sharing. Then you'll want your software to connect to each of those IP addresses and ports to repeat the process and get the list of nodes that THEY are sharing. Then you'll want to repeat the process and connect to each of THOSE clients to get the list of nodes that THEY are sharing. You'll continue to repeat this process for so long as you continue to receive new IP addresses and ports. Eventually you'll find that every IP address and port that is reported to you is one that you already heard about from some other node. At that point, you'll have found all the nodes that you are capable of finding from your starting point.
Then you have a couple of things to do to maintain this list.
1. On a regular basis, you'll want to re-attempt to connect to each of the nodes in your list to see if they still exist. At any moment a node could be shut down and you won't know that unless you attempt to connect to it. (This allows you to prune your list of nodes that no longer exist).
2. On a regular basis, you'll want to re-send the getaddr message to every node in your list to see if any of them know about a new node that they didn't report to you the last time you connected to them. For each new node you hear about this way, you'll need to repeat the earlier process of connecting and sending getaddr messages to learn about all the other nodes that may have become accessible. (This allows you to find new nodes as they come online).
getaddr is a communications message used over the connection between two clients. Therefore, to use it you will need to write software that emulates a client.
Your software will need to connect to a client and pretend to be a bitcoin node. The default port to connect to is 8333, but if you changed that in your configuration then just use whatever port you configured your client to operate on.
When your software connects, the first thing it will need to do is send the version message containing your version number, block count, and current time. The client generally will not acknowledge ANY other messages until this has been completed.
The client will send back a verack message and its own version message if it is accepting connections from your version. You will then need to respond with your own verack if you are accepting connections from that client's version.
Once you've completed that, you can send the getaddr message and the client should respond with 1 or more addr messages. The addr messages will be the list of IP addresses and ports that the client has either connected to or heard about from peers that it is connected to.
During this communication the client may send it's own requests to your software. To prevent the client disconnecting from you and banning you, you might need to respond appropriately to some of those requests.
Eventually you'll have a full list of all the IP addresses and ports that the client is currently sharing. Then you'll want your software to connect to each of those IP addresses and ports to repeat the process and get the list of nodes that THEY are sharing. Then you'll want to repeat the process and connect to each of THOSE clients to get the list of nodes that THEY are sharing. You'll continue to repeat this process for so long as you continue to receive new IP addresses and ports. Eventually you'll find that every IP address and port that is reported to you is one that you already heard about from some other node. At that point, you'll have found all the nodes that you are capable of finding from your starting point.
Then you have a couple of things to do to maintain this list.
1. On a regular basis, you'll want to re-attempt to connect to each of the nodes in your list to see if they still exist. At any moment a node could be shut down and you won't know that unless you attempt to connect to it. (This allows you to prune your list of nodes that no longer exist).
2. On a regular basis, you'll want to re-send the getaddr message to every node in your list to see if any of them know about a new node that they didn't report to you the last time you connected to them. For each new node you hear about this way, you'll need to repeat the earlier process of connecting and sending getaddr messages to learn about all the other nodes that may have become accessible. (This allows you to find new nodes as they come online).
Here you can find all of the nodes on network: Bitnodes
However for you to be able to connect to all of them, you would gain no real benefit from it and use bandwith of the nodes.
But if you want to do this, you would have to modify the code so the bitcoin core allows unlimited connections, as well as opening bitcoin core default ports (port 8333), or your own configured ports.
However for you to be able to connect to all of them, you would gain no real benefit from it and use bandwith of the nodes.
But if you want to do this, you would have to modify the code so the bitcoin core allows unlimited connections, as well as opening bitcoin core default ports (port 8333), or your own configured ports.
Thank you. I don't want to connect to them. I just want to get a full list of all online nodes. Similar to that list from bitnodes.earn.com.
It's for a different network and therefore I would do this by my own.
Here you can find all of the nodes on network: Bitnodes
However for you to be able to connect to all of them, you would gain no real benefit from it and use bandwith of the nodes.
But if you want to do this, you would have to modify the code so the bitcoin core allows unlimited connections, as well as opening bitcoin core default ports (port 8333), or your own configured ports.
However for you to be able to connect to all of them, you would gain no real benefit from it and use bandwith of the nodes.
But if you want to do this, you would have to modify the code so the bitcoin core allows unlimited connections, as well as opening bitcoin core default ports (port 8333), or your own configured ports.
Currently there should be about 12 000 nodes online. I would like to query all these nodes based on the few peers from my current wallet (getpeerinfo). According to this documentation there should be a method named getaddr to achieve this, but I am not able to invoke it.
https://en.bitcoin.it/wiki/Protocol_documentation#getaddr
I tried to run it in the console, but I get an error with 'method not found'. When I list all available commands it isn't listed there either.
My idea would be, I get all current nodes with and then query the additional recursive via .
Can someone help me to get the command invoked? I know there is a site which lists all this nodes, but I have another use case where I would need this.
https://en.bitcoin.it/wiki/Protocol_documentation#getaddr
I tried to run it in the console, but I get an error with 'method not found'. When I list all available commands it isn't listed there either.
My idea would be, I get all current nodes with
Code:
getpeerinfo
Code:
getaddr
Can someone help me to get the command invoked? I know there is a site which lists all this nodes, but I have another use case where I would need this.
Jump to: