Closed Rav3nPL closed 1 year ago
SomberNight
commented
3 years ago I believe it would be sufficient to remove v2 onion addresses from just the default hardcoded list. If your server runs a modern tor daemon, then even if other peers send you v2 onion addresses for potential peers, you will simply fail to connect to them at that point -- this should not result in many connection attempts (unlike the default list).
Rav3nPL
commented
3 years ago As you can see in log, those peers are constantly broadcasting form peers and there are few tries until server gives up. Why waste time/resources on such tries, when we can kill it instantly?
Removing from hard coded peers is another thing, which should be done anyway.
Rav3nPL
commented
3 years ago I did this on my server, no more v2 connections
diff --git a/electrumx/server/peers.py b/electrumx/server/peers.py
index dcb9ab7..6f8ba78 100644
--- a/electrumx/server/peers.py
+++ b/electrumx/server/peers.py
@@ -206,7 +206,7 @@ class PeerManager:
new_peers = []
match_set = self.peers.copy()
for peer in peers:
- if not peer.is_public or (peer.is_tor and not self.proxy):
+ if not peer.is_public or (peer.is_tor and (not self.proxy or len(peer.host) < 30)):
continue
matches = peer.matches(match_set)
gits7r
commented
3 years ago The hack is good for now, but I think it's better to fully validate the v3 address in ElectrumX entirely. Just the length might not be enough in the future as Tor tries to implement a system that will map v3 onion addresses to human memorable names.
As TOR network evolves v2 addresses are now dropped from use https://support.torproject.org/onionservices/#v2-deprecation
In server log I can see, that some servers still propagating v2 addresses, and server is trying to reach them - and fail when using current TOR software (I have 0.4.6.6).
We should filter "short" addresses on source and/or add them directly to "do not connect" list.