-
m-relay
<jhendrix:imagisphe.re> How can I run Monero via Tor so that it does not rely on IPv4, with both incoming and outgoing communications routed through Tor?
-
m-relay
<jhendrix:imagisphe.re> My current setup:
-
m-relay
<jhendrix:imagisphe.re> `./monerod --anonymous-inbound addr.onion:28083,127.0.0.1:28083,25 --tx-proxy tor,127.0.0.1:9050,10 --p2p-bind-ip 127.0.0.1 --no-igd`
-
m-relay
<jhendrix:imagisphe.re> I can still see remote nodes on the clearnet, but I would prefer to enforce Tor.
-
m-relay
<jhendrix:imagisphe.re> In the Bitcoin/Zcash world, we have `getpeerinfo` to check both clearnet and tor peers, but curl get_peer_list only retrieves clearnet addresses. How can I check the hidden services currently connected to my Monero node?
-
m-relay
<ofrnxmr:xmr.mx> Monero Support
-
m-relay
<ofrnxmr:xmr.mx> tldr: monero doesnt support blockchain sync over onion. You can force it over tor exit nodes with --proxy=127.0.0.1:9050
-
m-relay
<ofrnxmr:xmr.mx> And sync_info to receive connected onion peers
-
m-relay
<jhendrix:imagisphe.re> What is the reason for the Monero project to continue using the clearnet? I have been working on a separate project and accidentally discovered spy nodes. I found 1300 more spy nodes that are not yet publicized in #1124. Wouldn't it make more sense for a privacy coin to connect over Tor and/or I2P by default?
-
m-relay
<vtnerd:monero.social> There's a pr for p2p-ssl but it's stalled a bit. That cuts out the passive spying at least
-
moneromooo
p2p ssl was ready years ago.
-
moneromooo
I was asked to remove it.
-
moneromooo
Maybe someone can rebase the patch.
-
moneromooo
I guess I should have pushed at the time, had I known it'd take so much time to do anything about it.
-
moneromooo
Can't be bothered to rebase the old patch though.
-
moneromooo
I can't even remember the reason(s) for nacking it.
-
m-relay
<boog900:monero.social> 1300 spy nodes on the Monero network?
-
m-relay
<boog900:monero.social> if true that would mean we only have like 700 valid nodes
-
m-relay
<jhendrix:imagisphe.re> Yes, apart from Lionlink. I have almost 3000 added to the ban list.
-
moneromooo
Though ssl would not prevent spying by spy nodes.
-
moneromooo
Just by ISPs and such who ferry data around.
-
m-relay
<jhendrix:imagisphe.re> My estimate is that 67.5% of all remote nodes are run by the spy node operators. I am polishing my write-up, it should be released soon.
-
m-relay
<boog900:monero.social> the monero network has ~4500 nodes by IP. around ~2000 are known spies by my method leaving 2500.
-
m-relay
<boog900:monero.social> It would be very interesting to know the method ...
-
m-relay
<aremor:matrix.org> I don’t think transport encryption wouldn’t have any effect on spy nodes. Only MITM attacks or ISPs & in transit routers knowing what you’re doing
-
NorrinRadd
the bridge is down DataHoarder plowsof
-
m-relay
<datahoarder:monero.social> That's probably the cluster node having issues as I got alerted last night
-
m-relay
<datahoarder:monero.social> I'll take a look
-
m-relay
<aremor:matrix.org> hmm maybe was temporarily down DataHoarder . Boog’s message never made it to IRC.
-
ofrnxmr
I see boogs msg
-
DataHoarder
that's probably just monero.social and Matrix federation fun
-
DataHoarder
bridge looks ok within what it can deliver
-
m-relay
<rucknium:monero.social> jhendrix: No. Having everything go through Tor and/or I2P invites Sybil attacks, which can enable eclipse and network partitioning attacks: Biryukov & Pustogarov (2015) "Bitcoin over Tor isn't a good idea"
arxiv.org/abs/1410.6079
-
m-relay
<ofrnxmr:xmr.mx> i think allowing tor/i2p incoming connections connections is ultimately a good thing. Nodes w/o incoming (nat etc) also unintentionally create an env for sybils (by forcing majority nodes to rely on minority)
-
m-relay
<ofrnxmr:xmr.mx> --proxy _kills_ incoming connections, so is worse than having onion inc ..
-
m-relay
<rucknium:monero.social> ofrnxmr: That's probably true. I don't think _all_ connections should be through an anon network.
-
m-relay
<ofrnxmr:xmr.mx> monero's most paronoid mode does tx-relay over anon services, and does block sync over outgoing connections only. If those nodes make outgoing connections to clearnet nodes (over proxy) but allowed inconing over anon, imo thats an improvement over today.
-
m-relay
<ofrnxmr:xmr.mx> Clearnet-only nodes wouldn't be able to connect to anon nodes, but the anon nodes would be able to connect to the clearnet as well as other anon nodes
-
m-relay
<jhendrix:imagisphe.re> I've read that study, it's from 2015... There is another one I was reading recently that is also interesting and from 2019: eprint.iacr.org/2019/1111.pdf "Towards Characterizing Sybil Attacks in Cryptocurrency Mixers".
-
m-relay
<jhendrix:imagisphe.re> I am not sure what is worse using the clearnet, knowing there are thousands of spy nodes in the network and average users don't use `--ban-list`, or facing theoretical attacks from 2015. Let's say an adversary knows that this addr.onion sent a particular transaction, what can they do after that? My understanding is that an adversary would need to control enough spy nodes on both t<clipped message>
-
m-relay
<jhendrix:imagisphe.re> he Tor and Monero networks, which makes their life much harder.
-
m-relay
<ofrnxmr:xmr.mx> i dont think theyd know which onion sent the tx, only which onions they are sending to
-
m-relay
<rucknium:monero.social> Read this one too? Shi, R., Ge, Y., Lan, L., Peng, Z., Lin, S., & Li, L. 2024, Deanonymizing Transactions Originating from Monero Tor Hidden Service Nodes.
moneroresearch.info/218
-
m-relay
<rucknium:monero.social> AFAIK, at least some of the issues in that paper were fixed in Monero version 0.18.4
-
m-relay
<rucknium:monero.social> jhendrix: Anyway, in your write-up, do you plan to explain how decide that a node is a spy node? You maybe could instead submit it to the Monero vulnerability response process, but I'm unsure how the VRP team would handle it.
-
m-relay
<jhendrix:imagisphe.re> In the same way as in your original GitHub issue (#1124), this is how I initially discovered that something was off. I then searched for the ISP name and found the GitHub issue. I classify spy nodes based on how many times a single IP address pretends to be a unique node.
-
m-relay
<jhendrix:imagisphe.re> I have notes here:
-
m-relay
-
m-relay
<rucknium:monero.social> jhendrix: Very interesting. Thank you! Are you interested in discussing your findings at the next Monero Research Lab meeting? They happen every Wednesday 17:00 UTC through text chat only in #monero-research-lab:monero.social
-
m-relay
<rucknium:monero.social> jhendrix: It looks like you are using "remote node" to mean a node that has open ports. In research papers, this type of node has been given many names. The term I like now is "reachable node". Nodes that do not have open ports are "unreachable".
-
m-relay
<jhendrix:imagisphe.re> I will be there, thanks for the invite.
-
m-relay
<rucknium:monero.social> In Monero, "remote node" usually means something different. In normal operation, Monero wallet software communicates with a node to create the transaction and then ask the node to propagate it through the p2p node network. The node can be on the same machine or local network as the wallet (a local node) or it can be on a different IP address (a remote node).
-
m-relay
<rucknium:monero.social> Great. I will put you on the agenda.
-
NorrinRadd
jhendrix i'm not finding the #1124 that you're mentioning
-
m-relay
<rucknium:monero.social> NorrinRad: It's in `/meta`:
monero-project/meta #1124
-
m-relay
<rucknium:monero.social> NorrinRadd*
-
m-relay
<jhendrix:imagisphe.re>
monero-project/meta #1124
-
NorrinRadd
thanks!
-
m-relay
<boog900:monero.social> can confirm I am seeing these peers in nodes peer lists but I can't connect to them
-
m-relay
<boog900:monero.social> weird as to get added to peer-lists they must have been reachable at some point
-
m-relay
<ofrnxmr:xmr.mx> They could have just connected to a seed node (?)
-
m-relay
<ofrnxmr:xmr.mx> (or any node, actually)
-
m-relay
<jhendrix:imagisphe.re> The nodes from Peg Tech Inc?
-
m-relay
<boog900:monero.social> yeah
-
m-relay
<boog900:monero.social> true, there are so many addrs though for them just to have connected to a few nodes
-
m-relay
<jhendrix:imagisphe.re> They were all reachable nodes just yesterday, but that didn't last long, and they are now unreachable. Maybe they are testing the waters before configuring their setups.
-
m-relay
<boog900:monero.social> this peer list came from a single node:
paste.debian.net/1374198
-
m-relay
<boog900:monero.social> jhendrix: when you connected to them did you use a VPN or Tor?