monero-project
MRL recommendation: Ban spy node IP addresses from connecting to your node
UPDATE 19 June 2025: Code and explanation for how the spy nodes were detected is here. Relevant MRL meeting log.
The Monero Research Lab (MRL) has decided to recommend that all Monero node operators enable a ban list of suspected spy node IP addresses. The spy nodes can reduce the privacy of Monero users.
cuprate developer Boog900 discovered these spy nodes and created an IP address ban list. Developers and researchers associated with MRL (list names) have indicated their approval of this list by signing it with their PGP keys.
How do I enable the ban list?
Download the ban list from https://raw.githubusercontent.com/Boog900/monero-ban-list/refs/heads/main/ban_list.txt and remember the directory on your computer where you saved it so you can replace --ban-list <file-path-to-ban-list> below with it. For example, if you saved the file in /home/user/Downloads, they you would replace <file-path-to-ban-list> with /home/user/Downloads/ban_list.txt. WINDOWS USERS: Download the ban list file directly and save it. Do not copy-paste it into a new file. There is a Windows problem with the copy-paste method that will be fixed in the next Monero software release version.
Running monerod from the terminal
If you run the node from the terminal, add --ban-list <file-path-to-ban-list> when you start up monerod, i.e.
./monerod --ban-list <file-path-to-ban-list>
If you use a config file instead of command line flags, add this line to the config file:
ban-list=<file-path-to-ban-list>
Monero GUI wallet
If you use a remote node, whoever operates the remote node will decide if the ban list is enabled. If your run your own local node through the GUI wallet, go to Settings. In the "Daemon startup flags" box, input "--ban-list <file-path-to-ban-list>". Then click the orange "Stop daemon" button. It will take a few seconds for the daemon to shut down. Then click the orange "Start daemon" button.
Docker
If you use SethForPrivacy's monerod Docker file, update to the latest version, which has the ban list: https://github.com/sethforprivacy/simple-monerod-docker
If you run the Docker Monero node with any custom flags or custom config file, you need to add to --ban-list=/home/monero/ban_list.txt to the set of flags or ban-list=/home/monero/ban_list.txt to the config file.
FAQs
1) What is the evidence that spy nodes run at these IP addresses?
The numerous spy node IP addresses are pretending to be distinct nodes, but the spying adversary is proxying a few nodes through a large number of IP addresses. That way, the spying adversary can spy on the node network, but does not have to pay the full cost of running one node per IP address.
Unfortunately, the exact fingerprint of the spy nodes is not being released because the spying adversary might be able to fix the fingerprint and set up new spy IP addresses. However, a large number of the suspected spy IP addresses are the same IP addresses implicated in "LinkingLion" spying on the BTC node network as far back as 2020. The spying adversary is likely using the same IP addresses to spy on BTC and Monero.
Furthermore, most of the spying IP addresses are in a few "subnets", which are basically consecutive IP address numbers that can be purchased at a bulk price rate from IP address providers. Almost every IP address in the subnets have a suspected spy node, a status MRL is calling "subnet saturation". More details are in the MRL GitHub issue.
2) Can I tell how many spy nodes my node is connected to?
Yes. You can run the peers.ip.collect() function in the xmrpeers R package. See the "Examples" in the documentation here. The function will also start to show the subnet saturation after running for about 24 hours.
3) What is the privacy issue?
Monero uses Dandelion++ for privacy of transactions relayed on its peer-to-peer node network. Dandelion++ provides strong privacy, but even its privacy can be weakened if there are too many spy nodes on the network. An adversary who controls a lot of spy nodes may be able to guess which user's IP address was the original sender of a Monero transaction.
4) Won't the spying adversary just change its IP addresses?
This is possible, but it's costly for the adversary. The LinkingLion BTC spying adversary is still using these IP addresses even though the spying has been publicly revealed for at least 21 months, which suggests that the adversary cannot easily change their IP addresses.
5) Are more universal fixes possible so that a specific ban list doesn't have to be used?
MRL will analyze the possible benefit of implementing an algorithm that chooses node peers to maximize diversity of Autonomous System Networks (ASNs), which are groups of IP addresses managed by the same entity. This algorithm could reduce the probability of connecting to too many potential spy nodes.
In the long term, there may be ways for nodes to verify that their peers are truly running a node instead of just proxying one node through many IP addresses.
6) Why not block these IP addresses by default in the Monero node software?
Blocking the IP addresses by default is technically possible, but it would set a precedent of blocking IP addresses by a decision making process that is semi-centralized. MRL has decided to ask node operators to block these IP addresses voluntarily instead of by default.
I can confirm this has been deployed on my public node and all of Cake's Monero nodes.
Would a viable long term solution be to block IPs that share node fingerprints?
e.g: If the same fingerprint is detected across >1 IP automatically ban the IPs?
@rblaine95 I don't think this is possible, whatever fingerprint detection we use can simply be fixed by the spy node operators before we even put out a release.
As per recent commit said banlist has been added to lists.d blocklists.list.tsv.
In my comment under @Rucknium 's gist I considered such cyberespionage attempts a matter of security, which is in line with known state-sponsored attacks against Monero.
- Simply because malicious nodes like
node.moneroworld.comare easy to spin up and U$D 1,25M is a lot of money to burn, tho with IPv4 shortages it'll be hard for said attackers to keep doing so if we literally blocklist entire /24's.
Needless to say the optimal strategy would be if everyone were to host their own node over Tor but that's sadly not a viable option for everyone.
To address @rblaine95 's question: It's not that easy, given that someone may have a shitty ISP with changing IPv4's or using mobile networks or even using Multipath TCP or some applicanced / commercial VPN for redundancy...
-
That being said such malicious nodes are a general problem and it'll be only a matter of time till the operators of said network either learn how to properly deploy stuff without wasting entire /24's with non-unique Fingerprints.
-
I'd suggest to look at how Tor Project dealt with that. I remember ioerror having dealt with such things in the past when the "P.R." China and Russia tried to deanonymize local Tor users but I don't have much details on that...
So besides the existing IPv4 banlist I'd also suggest IPv6 banlists and to look into integrating Tor natively into Monero wallets and nodes where feasible.
- Feather Wallet and monerujo already have Tor integration, may it be built in as in Feather Wallet or simple proxy support.
@rblaine95 I don't think this is possible, whatever fingerprint detection we use can simply be fixed by the spy node operators before we even put out a release.
Yeah, they'd just learn how to use ansible (or whatever tools they use to deploy that) properly instead of rolling out clones...
- simply because the suspected attackers have a lot of money to burn through...
6) Why not block these IP addresses by default in the Monero node software?
Blocking the IP addresses by default is technically possible, but it would set a precedent of blocking IP addresses by a decision making process that is semi-centralized. MRL has decided to ask node operators to block these IP addresses voluntarily instead of by default.
THIS is crucial. Otherwise it would be trivial to strong-arm MRL into imploding Monero!
I am syncing a local node on MacOS, but will soon set up a full node on VPS. Regarding the local node on Monero GUI that is currently syncing, is there a chance that some nodes on the ban list will be queried during the sync?
@HCNOP
Regarding the local node on Monero GUI that is currently syncing, is there a chance that some nodes on the ban list will be queried during the sync?
No, if you have the ban list enabled.
Isn't an alternative solution, to upgrade Monero to only accept connections via Tor, and force all wallets to implement it? This way even if it is a spy node it can't collect anything useful
Another question, in monerohash.com there is a Monero node map that shows like 50% of all nodes on the network being in the same spot in the USA. Is this accurate? If so it could be a huge privacy issue.
- What would be the benefit of choosing TOR over I2P, I was under the impression I2P was specifically built to handle this kind of of P2P traffic over its network?
My understanding is the underlying concern in this GH issue is that spy nodes can log user IPs potentially compromising privacy. While I2P is used for node peering, and the initial solution offered here is banning spy nodes from becoming peers; I'm referring to another possible solution: enforcing TOR on wallet to node connection, which I believe happen using ZMQ and it already has good TOR support.
Making TOR mandatory for wallet to node connections, in my understanding, would eliminate the need of maintaining spy node blocklists, as IP logging would become useless. For now, the only fault-proof solution is running your own node, but for the average user is not easy enough. And banning spy nodes is only a mitigation as not all node operators will do it, and governments with their big budgets could spin up thousands of spy nodes if they wanted (and maybe they already do).
- Integrate it directly into monerod daemon, wallets will all automatically inherit it then
Yes I think this would require changes in monerod, and wallet providers would require to add TOR support. It also needs considerations on the performance impact of establishing TOR circuit which I believe takes 5-10 seconds and would need to be re-done in mobile devices when changing networks. This is above my development knowledge, so I'm only sharing the idea in case someone else wants to pick it up to further consider/implement.
Another question, in monerohash.com there is a Monero node map that shows like 50% of all nodes on the network being in the same spot in the USA. Is this accurate? If so it could be a huge privacy issue.
IIRC, all the the IPs in the USA without precise geographical data, as according to the database monerohash.com uses, get placed in Ashburn, Virginia. So no, probably not accurate.
It has come to my attention that some node operators can make a mistake when trying to enable the ban list, especially when performing all tasks on the command line. The mistake can prevent the ban list from taking effect.
The link for the ban list originally appeared as https://github.com/Boog900/monero-ban-list/blob/main/ban_list.txt This is an HTML web page on GitHub. If the web page is downloaded directly through a wget request or similar, all the extra HTML code will be downloaded in the file. Then, the Monero node software will fail to properly parse the ban list file when there is all the extra HTML content.
If node operators directly download the file, they should use the link to the raw text file: https://raw.githubusercontent.com/Boog900/monero-ban-list/refs/heads/main/ban_list.txt
Node operators and users can check if a specific node (with IP address) has the MRL ban list enabled by scrolling to the bottom of this experimental web app and searching for the node: https://moneronet.info/
https://github.com/Boog900/monero-ban-list/raw/main/ban_list.txt
this works too (redirects)
