Eriq

joined 2 months ago
[–] Eriq@monero.town 1 points 1 week ago (1 children)

Did you manually ban from the monerod terminal? subnet parsing works when manually banning it from cli but seems to have issues when loading automatically ban list. If u loaded it with the ban list and it worked then it is somehow a local issue for me.

[–] Eriq@monero.town 2 points 1 week ago

Best solution when connecting to public nodes would be through Tor. Even if the public node is a spy node somehow with tor enabled, they would still be able to see requested blocks but would not be able to pinpoint who is requesting. It still adds a good layer and is recommended by most, but it is not perfect because Tor is also somewhat under a timing attack.

[–] Eriq@monero.town 2 points 1 week ago (2 children)

yes the overall transaction is safe but the individual node sending that transaction/block is recorded with the IP logged. Mass collection with a large spy network would easily enable a semi reliable initiator logging system that could be used later for any purpose. You could connect to a public node to hide and not send from personal node but then again the public node itself could be a spy node too. Its all about collecting general metadata for use with other data to be cross examined when the time is needed.

[–] Eriq@monero.town 4 points 1 week ago (6 children)

It removes the spy nodes from network so they cant do a timing attack (If one spy node receives a transaction unseen by the 100s of other spy nodes, they can logically deduce that the first instance seen was the originator of the transaction/block). The current list above has a parsing error for the subnets (IPs with 0/24) and those are important because each single subnet contains 256 possible IPs. These possible IPs are fully actively being utilized for the attack as I have seen first hand. I hope Boog900 or one of the list maintainers can address this parsing error somehow so I can remove my temporary fixed list. This could be somehow a personal error somehow but most probably these unparsed subnets are a unnoticed issue.

[–] Eriq@monero.town 1 points 2 weeks ago (5 children)

Is this a common issue of ban lists unable to parse subnets or am I the only one because if no one is banning these subnets due to parsing error that is small problem.

[–] Eriq@monero.town 1 points 2 weeks ago* (last edited 2 weeks ago)

https://github.com/ErikASD/enum-monero-ban-list/blob/main/ban_list.txt seems to fix the issue above for me.

All I modified was the subnets, expanding them into individual IPs to be banned properly.

[–] Eriq@monero.town 1 points 2 weeks ago* (last edited 2 weeks ago) (8 children)

All the subnet addresses are not banned and shows error when adding any subnet, other IPs without the subnet format are added successfully : "

2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 91.198.115.0/24

2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 100.42.27.0/24

2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 162.218.65.0/24

2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 193.142.4.0/24

2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 199.116.84.0/24

2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 209.222.252.0/24 "

These IPs account for more than half the problem and do not seem to be banned properly by the ban list.

If the subnet format does not work we could enumerate the subnet and have each individual IP from that subnet on the list as a workaround.

[–] Eriq@monero.town 1 points 1 month ago

100.42.27.* is banned on the one above but not the official monero ban list indicating new malicious subnets appearing.

[–] Eriq@monero.town 2 points 1 month ago (1 children)

yea and all above IP ranges are found at the top of https://github.com/Boog900/monero-ban-list/blob/main/ban_list.txt. The ban list is good but it is not enabled by default.

24
submitted 1 month ago* (last edited 1 month ago) by Eriq@monero.town to c/monero@monero.town
 

Created a script to get the connections every time a new node connected. Everything looked normal in the peer list until I saw many nodes from:

100.42.27.* (around 200 peers)

193.142.59.* (around 200 peers)

199.116.84.* (around 100 peers)

209.222.252.* (around 150 peers)

91.198.115.* (around 150 peers)

The 100.42.27., 199.116.84., 209.222.252., and 91.198.115. all belong to "Lionlink Networks".

These are around 600 nodes that are under that ISP and account for 20-30% of all nodes seen from a 3 day survey span.

This looks suspicious to me and the massive amounts of nodes raises many red flags and does not look natural at all.

~~If these were malicious, in concept, with the 13 default IN/OUT peers, if all connected are malicious, the innocent one would have no other data to compare it to~~.

(Edit: Updated Theory: having many nodes has the ability trace transactions and block miners easier based on timing attack)

 

Created a simple sample jackpot website for educational purposes, especially educational when you look at the rigged version of this even thought it looks legit https://github.com/ErikASD/simpyle-xmr-arcade-rigged with all the bs provability fair.

 

I was interested on which the best way to accept XMR programmatically and made this concept payment processor that credits PGP based accounts with the XMR amount deposited like an exchange would have with sub addresses assigned to each account.

When withdrawing, It is a lot more difficult to implement as transfer RPC call cannot auto-calculate the fee.

Workaround:

Estimate transfer is sent with no relay

transfer2 with no relay is sent after deducting fee manually.

Checks for proper deduction and then uses relay_tx for the final step.

If you have any suggestions on how to improve this, especially if you have a better architecture in mind for the withdraw/deposit functionalities.