Monero Spy Nodes Explained and How to Enable the Ban List

In late 2024, Monero researchers confirmed what many node operators suspected: a large share of the reachable Monero network was made up of nodes that weren’t there to help. These “spy nodes” relay data like normal peers while quietly recording who sends what first. This guide explains what spy nodes do, how big the problem is, and how to block them on your own node.

What is a spy node?

A Monero node keeps connections to a set of peers and passes new transactions and blocks between them. A spy node joins this network looking like any other peer, but its goal is surveillance. It logs which peer sent it each transaction and when.

With enough of these listening posts spread across the network, an adversary can try to work out which IP address a transaction started from. That is the same kind of network-level analysis that has been used against Bitcoin for years.

What spy nodes can and cannot learn

Key point: Spy nodes go after the network layer, not the blockchain. Monero’s on-chain privacy stays intact. What spy nodes threaten is the link between a transaction and your IP address.

Why Dandelion++ isn’t enough on its own

Monero already uses Dandelion++ to blur where transactions come from. A new transaction first travels along a random “stem” of single hops before being “fluffed” (broadcast widely). An observer who sees the fluff can’t easily tell which node started the stem.

Dandelion++ assumes most of your peers are honest, though. According to the MRL notice, if too many of the nodes around you are spies, the protection weakens, and an adversary with enough of them may be able to guess the originating IP.

What MRL found in 2024

The Monero Research Lab’s notice, drafted by researcher Rucknium and tracked in monero-project/meta issue #1124, set out several findings:

• Many IPs, few real nodes. The suspected spy nodes used a large number of IP addresses that appeared to proxy a much smaller number of real nodes. That lets an adversary watch many points in the network cheaply.
• Concentrated in a few subnets. Most suspicious addresses sat in a handful of IP ranges, a pattern MRL called “subnet saturation.”
• Overlap with a known Bitcoin spy. Many of the IPs matched those tied to “LinkingLion,” an entity that had been monitoring Bitcoin’s peer-to-peer network since 2020.
• Fingerprint withheld. MRL kept the exact detection method private so the adversary couldn’t simply evade it.

Later reporting put the suspected spy share at roughly 40% of reachable node addresses. Treat that as an estimate from a particular snapshot of the network rather than a fixed number.

The recommendation was simple: every node operator should enable a ban list of suspected spy-node IPs. Cuprate developer Boog900 compiled the list, and several MRL-associated researchers signed it with their PGP keys.

How to enable the ban list

The list is a plain text file with one IP address or subnet per line, and monerod refuses connections to and from anything on it. The --ban-list option was originally added as an emergency measure against DDoS attacks in 2020–2021, according to the monerod reference.

Step 1: Download the file

The list referenced in the MRL notice is hosted at:

https://raw.githubusercontent.com/Boog900/monero-ban-list/refs/heads/main/ban_list.txt

On Linux:

wget -O ~/ban_list.txt https://raw.githubusercontent.com/Boog900/monero-ban-list/refs/heads/main/ban_list.txt

Tip: On Windows, download the file directly rather than copying and pasting the text into Notepad. The MRL notice specifically warns about this, because pasted text can pick up line-ending or encoding problems.

Optionally, verify the signatures published alongside the list before using it. That is the point of the PGP signatures.

Step 2a: Command line or config file

Add the path to your startup command:

./monerod --ban-list /home/you/ban_list.txt

Or, better, add one line to your config file so it survives restarts:

ban-list=/home/you/ban_list.txt

Step 2b: Monero GUI with a local node

1. Open Settings → Node and make sure you’re using a local node.
2. Find the Daemon startup flags box.
3. Add --ban-list C:\path\to\ban_list.txt (or your Linux/macOS path).
4. Stop and restart the daemon from the GUI.

Step 2c: Docker

If you use SethForPrivacy’s popular monerod image, the MRL notice says updated images include the list. If you pass custom flags or your own config file, add --ban-list=/home/monero/ban_list.txt (or ban-list=/home/monero/ban_list.txt in the config) so it isn’t overridden.

Step 3: Confirm it loaded

In the running daemon’s console (or with monerod followed by a command), type:

bans

The reference describes this command as showing the currently banned IPs. You should see a long list. If it’s empty, check the path and restart.

Warning: A ban list is a static snapshot. The monerod reference itself warns that static IP bans can catch innocent users, such as people on shared hosting or VPN ranges. That’s one reason the list is opt-in and open for anyone to review.

The built-in defense: /24 subnet deduplication

The ban list is a manual fix. A structural one arrived in Monero 0.18.4.3 in October 2025. According to the release notes, peer selection now deduplicates peers by /24 subnet, explicitly to disadvantage spy nodes.

In practice, if an adversary rents a whole block of 256 consecutive addresses, your node treats that block more like a single peer and won’t fill its connection slots from it. A determined attacker can still spread out across many subnets, but doing so costs more. Later releases continued hardening peer handling. For example, 0.18.5.3 groups IPv6 connection limits by /64.

Keep monerod updated. This protection only works if you run a version that has it.

What if you use a remote node?

A ban list lives on the node, not the wallet. If you connect to someone else’s node, you depend on whether its operator enabled one. Options:

1. Choose nodes that run the list. Some node directories, such as this ditatompel list, flag nodes that appear to have the ban list enabled.
2. Broadcast over Tor or I2P. If the first hop for your transaction is a Tor or I2P connection, a spy watching the clearnet relay can’t tie it back to your IP.
3. Run your own node. A pruned node with the ban list and --tx-proxy gives you both protections.

Common questions and objections

“Won’t banning IPs hurt honest users?”

Possibly, at the edges. A static list can include an address that later gets reassigned to an honest person, or a shared hosting range where one bad actor sits next to legitimate nodes. In practice, an honest node that can’t connect to your node still has many other peers, so the cost is low. The benefit is that your node stops handing transaction-timing data to a known surveillance network.

“Doesn’t this make Monero dependent on one person’s list?”

No. The list is a text file you can read line by line, it’s signed by several researchers rather than one, and you can edit it, use a different one, or skip it entirely. It doesn’t affect consensus. Nodes with and without the list still agree on the same blockchain. It only shapes which peers your own node talks to.

“How do I know it’s working?”

Besides bans, you can run print_cn to see your current connections. After loading the list and running for a while, you shouldn’t see peers from the banned ranges. If you also run tx-proxy, your own transactions leave through Tor or I2P peers, which you can confirm in the daemon log at a higher log level.

“Should I also use the DNS blocklist option?”

monerod has a separate --enable-dns-blocklist flag that pulls a dynamic list published as DNS TXT records, managed by Monero contributors. It’s a different mechanism from the MRL-recommended spy-node file, and the official notice focuses on the file-based --ban-list. If you enable both, make sure you understand what each one blocks.

A quick hardening checklist for node operators

1. Upgrade to the latest monerod (0.18.5.4 at the time of writing, released October 2026).
2. Download the ban list, verify it, and add ban-list= to your config.
3. Add tx-proxy=tor,... or tx-proxy=i2p,... so your own transactions leave over an anonymity network.
4. If you run a public node, enable restricted RPC so visitors can’t use sensitive methods.
5. Re-download the list from time to time and restart.
6. Run bans and print_cn occasionally to sanity-check your peers.

Will FCMP++ fix this?

No, and it isn’t meant to. FCMP++, the upgrade that replaces 16-member rings with proofs over the whole chain, is an on-chain change. It was on a public stressnet in October 2026 with no mainnet date announced yet. Spy nodes target the peer-to-peer layer, so network defenses like ban lists, subnet limits and anonymity-network relaying will still matter after it ships.

For related setup guides, see our Privacy & OpSec category. For the cryptography behind rings and FCMP++, see the Technology category.