Based: Monero Fights 40% Network Spy Nodes with Subnet Filter

The new release implements /24 subnet filtering to disadvantage spy nodes that have been attempting transaction-to-IP correlation since October 2020.

Based: Monero Fights 40% Network Spy Nodes with Subnet Filter

Monero released version 0.18.4.3 on October 9, 2025, and called it "highly recommended." That phrasing usually means someone found something ugly.

The Monero Research Lab identified it in December 2024, adversaries running spy nodes on roughly 40% of reachable addresses in the network. These nodes operate across approximately 130 IP addresses hosted primarily on OVH and Digital Ocean, and they've been active since at least October 2020.

The attack uses IP proxying to make a small number of actual nodes appear as hundreds of distinct peers. This lets the operator surveil network traffic without paying the full infrastructure cost. The threat is fairly specific, transaction-to-IP correlation.

If an adversary controls enough nodes and you connect to multiple malicious peers, they can potentially link your transaction to your IP address even though Monero's Dandelion++ protocol was designed to prevent exactly this.

Dandelion++ works in two phases.

During the "stem" phase, your node relays the transaction to single random peers before entering the "fluff" phase where it broadcasts to everyone. This obscures which node originated the transaction. The problem is that when 40% of the network is hostile, the probability of hitting multiple spy nodes during stem propagation increases dramatically. Your privacy tool degrades when the threat model exceeds design assumptions.

Version 0.18.4.3 implements /24 subnet deduplication in pull request #10113. A /24 subnet contains 256 IP addresses sharing the first three octets everything from 192.168.120.0 to 192.168.120.255, for example. The daemon now limits peer connections from the same /24 range during peer selection. If a spy operator controls 100 nodes on sequential IPs like 45.142.120.1 through 45.142.120.100, your node treats them as coming from the same subnet and refuses to connect to multiple addresses in that block.

This works because bulk hosting providers typically assign IPs in consecutive blocks within the same /24 range. Running true geographic and network diversity across different /24 subnets costs significantly more money. The identified spy nodes concentrate on specific hosting providers using predictable IP allocation patterns. Subnet deduplication specifically targets the economic model that makes mass surveillance operations viable.

The spy nodes employ several techniques beyond simple eavesdropping. They spam outgoing connections to valid nodes, inject peer lists containing only malicious addresses, report incorrect block heights to prevent wallet synchronization, and drop transactions during Dandelion++ stem phase to disrupt privacy propagation.

Analysis from the Monero community documents these behaviors with specific IP ranges and timestamps. The Monero Research Lab issued formal recommendations in December 2024 for node operators to ban known spy node addresses.

The cryptographic privacy layer remains mathematically secure. Ring signatures hide the sender among 16 decoy outputs, stealth addresses obscure the recipient, and RingCT conceals transaction amounts. None of the spy node attacks break these protocol-level protections. The threat operates at the network metadata layer correlating your IP address with transaction broadcast patterns, not decrypting the transaction itself.

But IP addresses matter. If chain analysis firms like Chainalysis can link your transaction to your IP, they can potentially identify you through ISP records, especially if you're not using Tor or I2P. The privacy model assumes attackers cannot determine which node originated a transaction. When that assumption breaks, the entire network-level privacy guarantee collapses even though on-chain privacy stays intact.

Version 0.18.4.3 includes other significant changes. Pull request #10150 modifies RingDB error handling.

RingDB is a local database tracking which ring signature outputs you've used in previous transactions. This prevents privacy leaks during blockchain reorganizations. If you spend the same output on two chain forks with different rings, observers can identify your real input by finding the common ring member. The wallet now warns instead of throwing errors when RingDB data becomes stale after a reorg, improving stability without compromising the privacy protection.

Pull request #10096 removes the 64-address creation limit in RPC calls. Previously, generating more than 64 subaddresses required loop calls, which is inefficient for exchanges and payment processors handling thousands of addresses. The limit was arbitrary and users complained about needing workarounds. It's gone now.

Pull request #10066 fixes a logging deadlock that could freeze the daemon completely. Race conditions in logging code are easy to overlook during development but catastrophic for node operators running 24/7 infrastructure. A frozen node can't relay transactions, can't mine blocks, and can't serve wallet requests. The fix patches a specific lock acquisition order problem, though the commit notes mention future optimizations are still needed.

Seed node maintenance occurred in pull requests #10105, #10112, and #10115. Seed nodes are hardcoded addresses your wallet contacts when first joining the network. If seed nodes are offline or compromised, new users can't bootstrap onto the network. This is unglamorous infrastructure work that nobody notices until it fails. Regular maintenance updates ensure reliable entry points.

The daemon also received ZeroMQ miner notification improvements in pull request #10104. Miners need immediate notification when transactions arrive in the mempool to include them in block templates. The previous implementation had timing issues that could delay mining pool responsiveness. The fix ensures ZMQ notifications fire after transaction pool additions, improving mining efficiency.

The GUI release adds Ledger Flex support. Ledger Flex is the company's mid-tier hardware wallet announced July 2024, featuring a 2.84-inch E Ink touchscreen, CC EAL6+ certified secure element chip, and both Bluetooth and USB-C connectivity. It slots between the entry-level Nano series and premium Stax model. Users now have another secure cold storage option.

Qt framework updated to version 5.15.17 in the GUI. Qt is the underlying graphical interface library. Updates include security patches for GUI vulnerabilities, compatibility fixes for modern operating systems, and general performance improvements. These updates rarely make headlines but prevent exploitation of known vulnerabilities in the display layer.

P2Pool v4.11 ships with the GUI release. P2Pool is Monero's decentralized mining pool no central operator, no pool fees beyond network costs, no single point of failure. Version 4.11 fixes a critical bug causing 1-2 blocks per 1000 to be invalid, which translates to 0.1-0.2% mining reward loss. If you mine Monero, you were literally throwing away money. The update also adds subaddress mining support, letting miners receive payments to subaddresses instead of main addresses for improved privacy. Solo miners and pool operators should update immediately.

RingDB will eventually become obsolete when FCMP++ (Full-Chain Membership Proofs) deploys. FCMP++ allows proving your output exists somewhere in the entire blockchain without revealing which block or transaction. Current ring signatures only hide among roughly 16 outputs from recent blocks. FCMP++ provides a full blockchain anonymity set every output ever created becomes a potential decoy. The Monero project announced an alpha testnet launching in 2025, with performance improvements showing 5x speedup in proof generation. Once FCMP++ activates, the fork protection RingDB provides becomes unnecessary because every ring will span the entire chain.

The spy node problem predates this release by years. Documentation from October 2020 shows the attack cluster was already operational. The adversary has maintained this infrastructure through multiple Monero hard forks, protocol upgrades, and community countermeasures. The operational costs suggest a well-funded entity likely state-level actors or commercial chain analysis firms like Chainalysis, which has openly discussed using network-level surveillance techniques.

Previous releases in the 0.18.4.x series addressed related security concerns. Version 0.18.4.2 released August 2025 fixed a privacy leak when using malicious remote nodes. Version 0.18.4.1 from July 2025 contained general bug fixes. Version 0.18.4.0 from April 2025 patched multiple daemon network vulnerabilities. The pattern shows consistent hardening of network-level defenses while the core cryptographic protocol remains unchanged.

The /24 deduplication won't eliminate spy nodes. Determined adversaries can acquire IPs across different /24 ranges, though this requires more sophisticated infrastructure and higher costs. What the change accomplishes is breaking the economic viability of cheap mass surveillance. Instead of renting 200 VPS instances from OVH in the same IP block, attackers need geographic distribution across multiple providers, multiple datacenters, and multiple IP ranges. That's orders of magnitude more expensive to operate at scale.

This matters for anyone running a Monero node. If you don't update, your node remains vulnerable to eclipse attacks where spy nodes isolate you from honest peers by flooding your peer list with malicious addresses. Your wallet might sync to false blockchain data. Your transactions could route through hostile nodes during critical privacy phases. The daemon might crash from the logging deadlock.

If you mine with P2Pool, you lose 0.1-0.2% of rewards to invalid blocks.

The release verification process remains unchanged. Download binaries from getmonero.org/downloads or compile from source on GitHub. Check SHA256 hashes against the signed list at https://www.getmonero.org/downloads/hashes.txt. Verify the GPG signature using the appropriate key from the source code repository at /utils/gpg_keys. Version 0.18.4.3 was signed by binaryFate, a long-standing Monero maintainer. GitHub shows the release with 13 contributors making 36 commits containing 253 new lines of code.

The existence of this spy node infrastructure reveals the threat model accurately. Privacy-focused cryptocurrency networks face active, persistent, well-funded adversaries running sophisticated surveillance operations over multi-year timespans.

The Monero Research Lab documented specific IP addresses, hosting providers, connection patterns, and attack behaviors with timestamps and packet captures. Someone is spending real money to deanonymize Monero users, and they've been doing it for at least five years.

Update immediately if you run Monero software in any capacity. The /24 subnet deduplication directly counters the identified attack infrastructure. The P2Pool fixes recover lost mining revenue. The stability improvements prevent daemon crashes. The Qt update patches GUI vulnerabilities. The RingDB handling prevents errors during normal blockchain operations. Every change addresses a documented problem with evidence-based solutions.

The spy node attack will continue evolving. Adversaries will acquire more diverse IP ranges, develop new correlation techniques, and adapt to countermeasures. The subnet filtering buys time and increases costs but doesn't permanently solve the problem. Long-term solutions require protocol-level changes like FCMP++, which makes network-level correlation attacks significantly harder by expanding the anonymity set to the entire blockchain. Until then, node operators should use Tor or I2P, apply the MRL recommended ban lists, and update to 0.18.4.3 immediately.

Monero's response to documented network attacks demonstrates the difference between privacy theater and functional privacy engineering. When researchers identified 40% hostile network penetration, developers didn't issue press releases claiming everything was fine. They analyzed the attack economics, identified the infrastructure dependencies, and deployed countermeasures targeting the specific operational model. The fix isn't perfect, but it makes the attack measurably more expensive. That's how you fight surveillance: make it cost more than it's worth.

Monero 0.18.4.3 Security Quiz
Test your understanding of spy node attacks, subnet filtering, and Monero's network defense mechanisms
Progress 0/10 answered
Question 1
What percentage of reachable Monero network nodes does the Monero Research Lab estimate are controlled by adversaries?
Question 2
How many IP addresses does a /24 subnet contain?
Question 3
When was Monero version 0.18.4.3 released?
Question 4
What is the primary threat posed by spy nodes in the Monero network?
Question 5
How long have the identified spy nodes been operating in the Monero network?
Question 6
What percentage of mining rewards were lost due to the P2Pool bug fixed in version 4.11?
Question 7
What does Dandelion++ protect against in Monero's network?
Question 8
Which hosting providers are primarily used by the identified spy node infrastructure?
Question 9
What future Monero upgrade will make RingDB obsolete by expanding the anonymity set to the entire blockchain?
Question 10
What new hardware wallet does Monero GUI 0.18.4.3 add support for?
0/10
Your Score
0
Correct
0
Incorrect
0
Unanswered
Coins by Cryptorank