Maldo Map Introduction Maldo Map Introductionjhendrix - Apr 1, 2025
The initial experiment aimed to assess the P2P network health of all privacy coins. To study the P2P network, we launched Maldo Map, which adds recent peers to the map, acting as a set of remote supernodes. To our knowledge, it is the largest and most detailed network map for Monero or any other privacy coin.
There are other maps worth mentioning, such as monerohash.com/nodes-distribution and monero.fail/map.
Though it
is not a map, we find xmr.ditatompel to be an interesting remote node monitor and recommend checking it out as well.
The author of this writing run the full node for all privacy coins that exist on the market, including those with a market capitalization no greater than Monero's 1-hour daily volume. Sadly, if we were to keep running our nodes, it would be trivial to identify which ones belong to Maldo Map. For example, if we combine the networks of all private-by-default privacy coins altogether, their total network size would still be less than 5% of Monero's network, this highlights how poor their networks are.
The reason we studied Monero more closely is that it is the only privacy coin with real usage and the largest P2P network due to the CPU mining algorithm that is accessible to everyone. The rest are merely personal projects, where all remote nodes are rented servers managed by the core team or a single developer.
By chance, we discovered many other interesting findings that we would like to share. The goal is raising awareness and showcasing our findings, encouraging users to avoid clearnet connections, mitigating ISP spying as well as spying from Chainalysis and Elliptic, spy nodes and their friends. Although much less probable than a spy node spying, some users might not benefit from Dandelion++ due to the lack of mandatory network encryption. In this write-up, we will cover protocol and network-level privacy, spy nodes, and more, hopefully to entertain and educate.
As we know, not all cryptocurrencies are private. Bitcoin and most coins are public ledgers that expose all possible metadata. Once a Bitcoin address is linked to an IP address, email address, or any other identifiable metadata, it becomes less plausible to reverse the damage. It is possible to use a coin mixing service to break the chain linkability, but it presents a great challenge for the end user and the need to pay unnecessary fees, in some scenarios, this may not achieve the desired result due to the nature of transparent transactions.
Unlike Bitcoin, Zcash has very likely the best technology that utilizes zero-knowledge mathematics to conceal all three: sender, recipient, and amount. However, since its blockchain does not enforce it via consensus rules, ZEC blockchain looks just like Bitcoin. Excluding coinbase transactions, we can generally classify transactions as follows:
| Type | Symbol | Description |
|---|---|---|
| Transparent | t → t | Just like in Bitcoin |
| Shielding | t → z | Moving funds from a Bitcoin-like address to an anonymous shielded address |
| Deshielding | z → t | Moving funds from an anonymous shielded address to a Bitcoin-like address |
| Shielded | z → z | Fully anonymous and untraceable transaction |
For simplicity, we can refer to shielded transactions as anonymous or untraceable, which is essentially what they are. To make a blockchain private by default we would need to disallow t → t and z → t completely. The reason why t → z exists is because mining funds go to a transparent Bitcoin-like address, then a solo miner or a mining pool sends funds to an anonymous shielded address.
We reviewed ZEC blockchain over the past three months or 100000 blocks between January 7th 2025 and April 4th 2025.
All data is stored in a JSON format and can be verified in zcash_stats.json.
Most transactions in Zcash are transparent. A half of the blockchain consists of empty blocks. The total number of anonymous transactions in three months is what Monero processes in a few days.
Back to the ZEC blockchain, shielding and deshielding transactions are roughly equal, suggesting that most funds that enter the anonymous pool return to fully transparent addresses. This is because most centralized exchanges accept only funds from transparent addresses to monitor users and link their IP addresses, full legal names, and blockchain addresses. There is no point to study the network-level privacy in the blockchain that fails to deliver privacy at the protocol level.
| Shielded vs Transparent | Shielding vs Deshielding | All Transaction Types | General Usage |
|---|---|---|---|
 |
 |
 |
 |
We believe it is misleading, and in some scenarios dangerous, for end-users to utilize a cryptocurrency with optional privacy. Not everyone is tech-savvy, and marketing a cryptocurrency as a privacy coin while the majority of transactions remain transparent can lead to significant consequences due to the improper usage.
Not all users know that Monero used to have optional privacy too, but this flaw was quickly acknowledged and addressed in the early days by making private transactions mandatory. Optional privacy is no privacy, this is another reason we chose to study Monero more closer in this experiment.
Assuming we are on a server, reproducing this experiment is relatively easy, we just need to open the P2P port 18080. This will make the node function not just as a normal full node, but also as a remote full node, essentially allowing others to download the blockchain from us.
sudo ufw allow 18080
The second step is to configure the remote full node as a remote full supernode. By default, every node connects to 12 peers to synchronize the blockchain, but we need to increase that number. To achieve this, we must make a few modifications to the cryptonote_config.h file. Below, we list the line we are interested in:
#define P2P_LOCAL_WHITE_PEERLIST_LIMIT 1000 #define P2P_LOCAL_GRAY_PEERLIST_LIMIT 5000#define P2P_DEFAULT_CONNECTIONS_COUNT 12#define P2P_DEFAULT_PEERS_IN_HANDSHAKE 250 #define P2P_MAX_PEERS_IN_HANDSHAKE 250
If you find this confusing, much will become clearer as you continue reading.
For advanced users, the public API is available and updated every few hours:
http://onion.tor.my/map/nodes.json
To download the JSON file with all recent peers found by Maldo Map:
torsocks curl http://onion.tor.my/map/nodes.json -o nodes.json
To retrieve all information for the given IP address via curl and jq:
jq '.[] | select(.["IP Address"] == "1.2.3.4")' nodes.json
To retrieve peers based on the ISP name:
jq '.[] | select(.["ISP"] | contains("LIONLINK"))' nodes.json
List peers based on the typology description, replace Typology Description, as we will learn later:
jq '.[] | select(.["Description"] == "Typology Description")' nodes.json
Alternatively, we can filter nodes on the map, as shown in the animation below, based on the IP address, ASN or ISP, location or geolocation, and even node typology.
| Search feature |
|---|
 |
In the first hour, we began noticing an abnormal number of peers sharing the same IP address. We found that all of them were from the same ISP, specifically AS54098 Lionlink Networks. Later, we discovered that Boog900 was the first to notice these peers, and there is an issue #1124 created by the same user who published OSPEAD. We encourage to read the original finding, below are the key points:
A large number of the suspected spy IP addresses are the same IP addresses implicated in LinkingLion's spying on the BTC node network as far back as 2020. The spying adversary is likely using the same IP addresses to spy on both BTC and Monero.
Monero uses Dandelion++ for the 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 many spy nodes may be able to guess which user's IP address was the original sender of a Monero transaction.
There are a few community banlists from Boog900 and a more actively updated one from rblaine95. We have a very similar but more up-to-date list to offer, at the time of this writing, we have listed 400 more IP addresses associated with spy node operators. If you wish to use them, the list is updated every hour:
torsocks curl http://onion.tor.my/map/ban_list.txt -o ban_list.txt
We understand the concerns of why these IP addresses are not banned by default in the full node software. Voluntarily, we can add them to the banlist as follows:
./monerod --ban-list /home/user/Downloads/ban_list.txt
Next, we checked how many of those nodes act as remote nodes. This is important because normal users are more likely to leak valuable metadata to the remote node first.
One might wonder why they can't do that from home. There are many reasons why running a public remote full node from home is not a good idea, one of the main reasons is the IP address exposure to the entire Internet. If for some reason the user can share the IP address of its network, another reason would be technical, running a remote node requires certain firewall configurations and a static IP address, or a Dynamic DNS setup. At the end of this writing, we learn about a new way for every user to become a remote node while remaining anonymous simultaneously, by default.
In a simple scenario where we send a transaction, for a spy node operator to be effective, they would need to run enough nodes to intercept your IP address as the true source. Since all normal users can only connect to public nodes, this task becomes easier, given that the number of volunteers willing to run a public node is limited.
Before discovering issue #1124, we recorded how often each IP address appeared in the get_peer_list and compared the likelihood of a peer being malicious based on the frequency of individual IP addresses in the list. Under normal circumstances, you should see only one IP address per peer. Initially, we thought it was possible for multiple users to be connected through the same VPN server managed by a provider such as Mullvad or similar. However, that was not the case, but we will learn why in the next observation.
| Occurrences | Ratio |
|---|---|
| 2 | 27.32% |
| 3-5 | 5.36% |
| 6 | 7.80% |
| 7-9 | 48.23% |
| 10 | 8.42% |
| 11 | 2.82% |
| 17 | 0.05% |
| Spies in Ashburn, United States 🇺🇸 | Spies in Reston, United States 🇺🇸 | Spies in Wilmington, United States 🇺🇸 | Spies in Almere Stad, the Netherlands 🇳🇱 |
|---|---|---|---|
 |
 |
 |
 |
The distribution indicated that most spy nodes appeared in the 6-10 range. The most interesting aspect for us was that every single node that appeared more than once was indeed a spy node and was found in 27.32% of every spy node. All 1600 IP addresses marked by us and Boog900 turned out to be operating as spy nodes.
Once we discovered that every peer appearing more than once is a spy node, it became clear to us that users of Monero, or any cryptocurrency for that matter, are not really utilizing a secure tunnel to encrypt their traffic. This is because a single IP address could have been used by multiple users via paid VPN services, such as those offered by Proton, Mullvad, Njalla, and many others.
To investigate this further, we used OSINT sources to examine the peers we found in the network and determine how many of them were not running over a VPN, thereby leaking their IP addresses. To enhance the analysis, we launched Maldo Map that defines nodes in 7 different typologies. We recorded over 19000 unique peers, and excluding the spy nodes, this is what we found:
| Occurrences | Ratio | Typology Description | Node Type | Typology | Proxy | Hosting | Known VPN |
|---|---|---|---|---|---|---|---|
| 14091 | 73.7% | The node run by a user at home, leaking their actual IP address | Normal Node | #1 | No | No | No |
| 1879 | 9.82% | Remote node likely run by a user at home, leaking their actual IP address | Remote Node | #2 | No | No | No |
| 1473 | 7.70% | Potentially legit service or a self-hosted VPN | Normal Node | #3 | No | Yes | No |
| 1394 | 7.29% | Remote node with no signs of being malicious | Remote Node | #4 | |||
| 282 | 1.47% | The user is connected over VPN, Proxy or Known VPN needs to be true | Normal Node | #5 | Yes | No | Yes |
| Occurrences | Typology Description | Node Type | Typology |
|---|---|---|---|
| 1525 | Spy Node | Remote Node | #6 |
| 58 | Spy Node | Normal Node | #7 |
The second and third typologies might also be involved in botnets or could be spy nodes. To determine if an IP address is involved in any ongoing botnets, we would need access to more OSINT sources that are unavailable to us since there are only available on the clearnet. The members of the Haze project have no interest in using such services.
As we have learned, a node is very likely to be classified as a spy node if it appears more than once in the peer list. However, if three-letter agencies and their friends, with access to unlimited funds, essentially our money, truly wanted to, they could most likely run hundreds of other indistinguishable nodes, and they certainly do.
In the first days of May, we noticed more than 1300 IP addresses appeared from a previously unseen ISP, specifically AS54600 PEG TECH INC and AS398823 PEG TECH INC. The peers associated with this suspicious ISP are very new, none of them operate as remote nodes yet, but we believe they may also be spies. Once these peers become remote nodes, we will update the notes accordingly.
The company behind PEG TECH INC is a Chinese-American hosting company RAKsmart based in San Jose, CA. The reason why these nodes are suspicious is that, in just a few days, we found more unique nodes from them than from Digital Ocean, Contabo, Amazon, OVH, Google and Hezner combined, with an average occurrence of 3 peers per IP address.
| Spies in Tokyo, Japan 🇯🇵 | Spies in Los Angeles, United States 🇺🇸 | Spies in San Jose, United States 🇺🇸 |
|---|---|---|
 |
 |
 |
If our suspicion is correct and these are indeed spy nodes that become remote nodes, then when combined with AS54098 Lionlink Networks, 67.5% of all remote nodes consist of spy nodes at the moment of writing, those we are certain about, excluding non-deterministic nodes that were not easy to spot, but also exist. The likelihood of leaking the IP address as the real sender significantly increases, even with Dandelion++, if not using --ban-list.
In #1124, it was mentioned that in the future, we might see a new feature where the node will diversify its peers based on the Autonomous System Networks (ASNs).
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.
Since the feature mentioned above doesn't exist yet, consider using --ban-list, or better yet, switching to non-clearnet connections via anonymous networks.
What really happens when we run a full node on our desktop or laptop computer? In this paragraph, we will see the distribution of nodes we connect to and the probability of a node broadcasting its transaction to the known spy operator that we have already established to be AS54098 Lionlink Networks.
We can safely assume that 99% of all users don't use --ban-list or even know about it. In the graph below, we recorded how often the local node has peers from AS54098 Lionlink Networks, starting from the very first start during the synchronization process until the node is fully synced and ready to send.
| The distribution of spy nodes from AS54098 in a normal node |
|---|
 |
The most interesting observation was that spy nodes were not particularly active during the synchronization process. However, once the node was synced and ready to send transactions, we began to actively see spy nodes in our peer list.
Remote nodes constantly ask other nodes what block height is the highest they know about, to decide who to download which blocks from. Spy nodes use that data to see if a node is fully synced or not, because only fully synced nodes can send transactions. They are managing their own resources effectively by not making lots of connections to nodes which are not fully synced. They are interested in spying only and not providing a public service by hosting a copy of the blockchain.
If the spy nodes from AS54600 PEG TECH INC and AS398823 PEG TECH INC become remote nodes again and then remote supernodes, we might see 3 or 4 spies out of 12 peers, and even with Dandelion++, there will be a 30% chance of just guessing the user's IP address that made a transaction without using any other advanced tools, assuming both spy node operators work together.
Not all cryptocurrencies encrypt P2P traffic by default. Although Monero does have an auto-detection feature that attempts to establish an encrypted connection first, it does not enforce this, which means users can still connect over plaintext if the remote node does not support encryption. This can lead to de-anonymization by the ISP without running a single node. This is because all traffic can, and we can assume is, monitored by the ISP and their friends.
Every time we create a transaction without using a VPN or anonymous network, the ISP might link the IP address and the user's full legal name to the transaction created if the remote node chose not to have an encrypted connection. This is when Dandelion++ can be ineffective for the end-user, although it is much less probable than a spy node spying.
ISPs often sell network data to the highest bidder and provide it to the governments to surveil their citizens. There is enough public evidence, such as Room 641A, to show not only is raw data about every packet on the internet bought and sold by ISPs and data brokers, it is harvested, stored and analyzed in its entirety by literally copying all the data that goes over the fiber optic lines that form the backbone of the internet.
Monero launched in 2014, and many amazing projects, such as Mullvad, have been accepting XMR for payments. The price is also quite affordable for most nations. However, the end-user still either shows no interest in setting it up or in paying for it.
Optional protocol-level privacy is no privacy, as we have learned, it can only be enforced. Otherwise, it risks becoming like Zcash - having amazing technology but only 12% of the network using it. Our observations show that most users won't set up or pay for a VPN, and since anonymous networks such as Tor and I2P are free, this may be a good reason for the full node software to switch to mandatory non-clearnet connections, moving away from clearnet and enforcing network-level privacy.
When a spy node operator sees that a transaction has been broadcast from a public remote node, it is trivial to determine whether this peer was a genuine sender, given that regular users do not run remote nodes. The advantage of running a full node as a hidden service on anonymous networks is that every normal node is not only concealed but also functions as a remote node. There is no need to open ports on our local network, as traffic passes through the anonymous networks, and every node contributes to the network in the same way that a remote node does.
Satoshi was smart to stay anonymous, but Bitcoin was eventually hijacked by the corporation anyways, and now the workflow is on GitHub, which is owned by Microsoft. If GitHub decides to censor the repository, with OnionShare integration, the community could choose the node that has hosted the source code the longest or select one based on other criteria.
One possible critism against transitioning to mandatory non-clearnet connections via anon networks would be Sybil Attacks. Renting IP addresses costs money, but generating hidden services on Tor or I2P does not. An adversary could spawn as many addresses as they like to pretend to be a unique node, thereby increasing their chances of being included in a large portion of the user's peer list.
From Using Tor in the official documentation, we are greeted with the message that even when using Tor, we might want to allow simultaneous connections over IPv4 to protect against Sybil attacks. What it means is that we retrieve blockchain data using the clearnet, but when we broadcast transactions, we use anonymous networks.
There is a new, still experimental, integration with Tor. The feature allows connecting over IPv4 and Tor simultaneously - IPv4 is used for relaying blocks and relaying transactions received by peers whereas Tor is used solely for relaying transactions received over local RPC. This provides privacy and better protection against surrounding node (sybil) attacks.
Even if an adversary has determined which transaction was created by which hidden service, it tells them very little since the user's IP address is hidden. The attack becomes more expensive and challenging because they would need to spy on Tor at the same time.
In a perfect world, Zcash would enforce shielded z → z transactions and Monero would upgrade to FCMP++, with both enforcing mandatory non-clearnet connections. To protect against theoretical Sybil de-anonymization and DoS attacks, we would need to choose at least one honest and trusted peer, similar to using clearnet, with the only difference being that we wouldn't leak our real IP address and would have the opportunity to run a non-deterministic hidden remote full node.
Although Bitcoin and Zcash provide better Tor and I2P integration, only Monero truly attempts to deliver privacy. In this paragraph, we will review how to run a privacy coin the right way. By following these simple steps, we will be able to run a non-deterministic hidden remote full node from home. Assuming we are using a Debian/Ubuntu distribution, we run sudo apt install tor first.
Next modify /etc/tor/torrc as follows:
HiddenServiceDir /var/lib/tor/monero-service/HiddenServicePort 18888 127.0.0.1:18888
Now restart the service for the changes to take effect by using sudo systemctl restart tor. After that, view the tor hidden service as below:
sudo cat /var/lib/tor/monero-service/hostname
We are now ready to start our node. Replace addr.onion with the value from hostname.
./monerod --proxy=127.0.0.1:9050 --anonymous-inbound addr.onion:18888,127.0.0.1:18888,25 --tx-proxy tor,127.0.0.1:9050,10 --p2p-bind-ip 127.0.0.1 --no-igd
Whether you would like to leave feedback or read it from others, the following links are where our findings were represented:
Why would anyone support anything that also reports the real IP addresses of users in real time? First, we could say it's public knowledge. Second, blockchain analytical companies such as Chainalysis and Elliptic, and their friends, have far more advanced tools and maps anyway. Third, how else would we motivate users to switch to anonymous networks and stop using clearnet with privacy coins?
The goal was to evaluate the P2P network health, not to spy on users. Ironically, the map was previously called "Spy Map" as a joke and even more ironically, we then found out about the actual spies that run thousands of nodes worldwide to spy on users.
Also if you just found this an interesting read and would like to express your appreciation with a donation, or even support our future work, it would be welcome:
88EwKsWtjvpV9aLqjasZ988bCbwBokvwa4n5g1435SSiFZmf1Pm1eeEGuj6hFtczSU9FtqJQ3wm6aQ4m5pTJo5MbKXYXQDk (QR code)