Enumerate Monero nodes

[Mitchellpkt]

During this interview on Bitcoin Uncensored, fluffy comments: "Monero Hash tracks nodes, but they don't track every single node. Its not like they are plowing through nodes like chain analysis would, trying to enumerate them"

Well, that's actually a very interesting idea.... Should be a quick iterative process... Request a peer list from each connected node. Connect to those nodes and request their peer lists (memoize by not repeatedly connecting to already-sampled nodes). Repeat recursively until we know about all of the open nodes.

Occasionally checking the size of the Monero network will be valuable for ascertaining how the number and distribution of nodes impacts other characteristics. This will also help with determining how MAP nodes should be geographically distributed, to match the profile of Monero network activity.

---

As a speculative side note / secondary analysis... This kind of network mapping is probably already a routine procedure for one or more surveilling entities. Could we turn this idea on its head and analyze our connection history across multiple MAP nodes for evidence of such activity by non-MAP entities? If the scanning party does not take steps intentionally obscure/obfuscate their search pattern, it would be trivial to see their loggers sweep across our archival nodes.

Consider three MAP nodes {A, B, C} configured so that node B is always connected to node A and node C. If a scan is executed without concealing the behavior, what would we expect to see in our combined logs across the MAP network?

13:59:00 Some unknown node X connects to MAP node A 13:59:01 Node X requests peer list from MAP node A 13:59:02 Node X disconnects from A 13:59:03 Node X connects to node B 13:59:04 Node X requests peer list from MAP node B 13:59:05 Node X disconnects from B 13:59:06 Node X connects to node C 13:59:07 Node X requests peer list from MAP node C 13:59:08 Node X disconnects from C

This propagating blip would be strongly suggestive of a network scan in progress

[Mitchellpkt]

Implementation notes, relevant daemon flags:

  --add-peer arg                        Manually add peer to local peerlist

  --add-priority-node arg               Specify list of peers to connect to and
                                        attempt to keep the connection open

  --add-exclusive-node arg              Specify list of peers to connect to 
                                        only. If this option is given the 
                                        options add-priority-node and seed-node
                                        are ignored

  --seed-node arg                       Connect to a node to retrieve peer 
                                        addresses, and disconnect

  --hide-my-port                        Do not announce yourself as peerlist 
                                        candidate

[Mitchellpkt]

Ah ha! https://github.com/suhz/monero-nodecount

[Mitchellpkt]

Experiment

1) Among normal/random connections, add a link between Frankfurt and Tokyo, and make sure logs are recording peer connection events.

2) Install VPN on London

3) Use monero-nodecount or other method to scan the network from London.

4) Review scan signature from Frankfurt and Tokyo.

[Mitchellpkt]

Even better! https://github.com/Gingeropolous/moneriote

@Gingeropolous let's set this up as part of standard MAP archival daemon protocol, which enables studies about node volatility, longevity, centralization through VPNs, peer list heterogeneity, etc!

Thanks @neptuneresearch for making this connection.

[Gingeropolous]

@Mitchellpkt , that specifically looks for open RPC ports though. And its very crude - you only get the peer list from 1 reference node, and then scan through that list of IPs. You never actually get the peer lists from your peers.

In general, we do need to find a way to hack from the daemon the code to get a node to give us your peer list. Its there. I just haven't isolated it.

[Mitchellpkt]

@Gingeropolous Ahh, gotcha gotcha. Hmm, is there a way to record then purge the peerlist, then restart our node with a connection to a specific node to query its peerlist? Repeating that cycle for all of the IP addresses we encounter.

This may be overcomplicating it, definitely open to better suggestions.

Thoughts? @Gingeropolous @neptuneresearch @serhack

[serhack]

@Mitchellpkt I found an interesting paper about this and a possible attack.

Nodes are able to request a list of peers from the other nodes they are connected to, which produces a large set pretty quickly.

According to this, I agree with @Gingeropolous. We should isolate that code and try to log peers per IP.

For those who are paranoid about the origin of the list, you can use the monero daemon --add-peer (or --add-exclusive-node during your first sync) to add some nodes to your local peerlist manually.

[Gingeropolous]

@Mitchellpkt , u may want to checkout m2049r (monerujo developer) for the node-o-matic. It enumerates through nodes.