Skip to content

Instantly share code, notes, and snippets.

@Rucknium
Last active July 15, 2025 20:30
Show Gist options
  • Save Rucknium/76edd249c363b9ecf2517db4fab42e88 to your computer and use it in GitHub Desktop.
Save Rucknium/76edd249c363b9ecf2517db4fab42e88 to your computer and use it in GitHub Desktop.
monerod Ban List Community Communication

UPDATE: Please go to the MRL issue for the current version of this notice.

MRL recommendation: Ban spy node IP addresses from connecting to your node

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.

@rbrunner7
Copy link

Here the sentence misses the info between the quotes:

In the "Daemon startup flags" box, input ""


The following sounds a bit strange to me. Nitpicking a bit, addresses can't be nodes:

What is the evidence that these IP addresses are spy nodes?

Maybe something like this?

What is the evidence that spy nodes run at these IP addresses?


Here you probably mean "spy", not "pay":

That way, the spying adversary can pay on the node network


Typo in "Dandelion":

Dandedelion++ provides strong privacy


Missing "i" for "is":

Blocking the IP addresses by default s technically possible,


Some general thoughts: It's quite technical in many parts, but I think that's still ok as a starting point. I hope for some lively discussion after this gets posted on Reddit, and from the questions there we may learn which aspects are most unclear for people with little technical background, and overall whether we might need an additional "ELI5" version of the whole thing or not.

@Rucknium
Copy link
Author

Rucknium commented Dec 6, 2024

@rbrunner7 Thanks for the edits and input! I made the edits in the latest revision: https://gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88/revisions

@rbrunner7
Copy link

You are welcome! Thank you for writing this, high quality info.

Just so that the work never stops, you now have small Markdown error in the What is the evidence that spy nodes run at these IP addresses? title :)

@Rucknium
Copy link
Author

Rucknium commented Dec 6, 2024

@rbrunner7 Thanks. Fixed :)

@xuid0
Copy link

xuid0 commented Dec 8, 2024

The same has happened in the past to Tor nodes in similar fashion so do not see why with the right knowledge cannot be done by those looking to de-anon Monero users. Also i came here via Mastodon and don't have active involvement with XMR anymore ;)

@kkarhan
Copy link

kkarhan commented Dec 13, 2024

Thanks @Rucknium for this info.

I've added the banlist by @Boog900 to the blocklist index as I think the observed issue is a a security concern that needs to be accounted for.

@kkarhan
Copy link

kkarhan commented Dec 13, 2024

The same has happened in the past to Tor nodes in similar fashion so do not see why with the right knowledge cannot be done by those looking to de-anon Monero users. Also i came here via Mastodon and don't have active involvement with XMR anymore ;)

I agree with @theoldblokecodes in that matter: This is a security issue and thus needs to be combatted like any other ITsec threat: With decisive intolerance!

  • Anything else would be normalizing such malicious actions and thus moving the overton window due to lack of accountability and/or lack of consequences...

@Rucknium
Copy link
Author

@kkarhan Thanks! This gist was meant as a place to review the draft announcement before it was published. Please post comments about the ban list here: monero-project/meta#1124

@kkarhan
Copy link

kkarhan commented Dec 14, 2024

@kkarhan Thanks! This gist was meant as a place to review the draft announcement before it was published. Please post comments about the ban list here: monero-project/meta#1124

Thanks for the hint, @Rucknium.

I merely maintain the lists.d repository as a means of spreading "sane" defaults for many setups.

OFC I'll make the inclusion known there too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment