The Monero Research Lab (MRL) has decided to recommend that all Monero node operators enable a ban list
https://github.com/Boog900/monero-ban-list/blob/main/ban_list.txt
- Download the ban list and:
./monerod --ban-list <file-path-to-ban-list>
🧐 https://gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88
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.
But with dandelion++ it should be infeasible to deduce anything about a transaction on receipt, no?
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.
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.
Well, the concept of a ban list seems ripe for abuse. We have to trust someone to tell us canonically who the bad nodes are, people can slap a fed honeypot node label on you for not going along with something.
What we need to do is design the system such that a bad node can do nothing but participate in the network. Just like the mining incentive structure with nakamoto consensus. Dandelion++ is supposed to do that, at least for everyone broadcasting their transactions only to initial nodes they know and trust. I don’t know how to do that, but a blacklist is a dangerous stopgap.