<w​aluigixox:matrix.org> Why not take whatever measures taken to discover the IPs that need to be banned (if not through centralised means) and implement mechanism that in to the node runtime for auto detection & consensus verification?

<b​oog900:monero.social> Because the method is then public and they can just fix it so their proxy can no longer be detected.

<3​21bob321:monero.social> Is this related to your ban list issue you made ?

<3​21bob321:monero.social> Qtip

<w​aluigixox:matrix.org> But security is always cat and mouse. From this I presume were not telling anyone why these are bad nodes and we have to trust?

<o​frnxmr:monero.social> You'd presume wrong

<w​aluigixox:matrix.org> Tell me more :O

<w​aluigixox:matrix.org> What am I missing then?

<b​oog900:monero.social> I have told people the method - other devs. The ones who wanted to have signed the list: github.com/Boog900/monero-ban-list

<w​aluigixox:matrix.org> 4

<w​aluigixox:matrix.org> Including yourself and a scammer

<s​yntheticbird:monero.social> xmrscott kewbit evasion, ban hom please

<b​oog900:monero.social> FWIW other devs know the method but have not signed the list. I know needing to trust devs is not great, but if you really want to just don't use the ban list.

<b​oog900:monero.social> If you think a large chunk of the active Monero devs are out to cause disruption to Monero there are certainly better things to target than trying to get people to ban some IPs.

<r​ucknium:monero.social> Any node operator can observe the subnet saturation of the banlist subnets. Instructions on how to observe it are in monero-project/meta #1124 . That's verifiable. And many of the banlist IP addresses are the same as the LinkingLion BTC spy nodes that were publicly analyzed about two years ago.

<r​ucknium:monero.social> And if it's a cat-and-mouse game, the mouse has been stationary for years, letting the cat trap it. By that I mean the IP addresses have been publicly unmasked for years, yet the adversary has not changed their IP addresses. Probably the mouse finds it hard to burrow another hole in the wall.

<d​oedl...:zano.org> actually this had the positive effect of ppl thinking about a WoT based defence

<d​oedl...:zano.org> (for a short period of time)

<r​ucknium:monero.social> Another observable characteristic is that the spy nodes don't initiate connections. They only accept inbound connections. That's optimal spy node behavior. Check the related MRL issue for details.

<d​oedl...:zano.org> actually this had the positive effect of ppl thinking about a WoT based defence (aka whitelisting in addition to blacklisting)

<p​reland:monero.social> A question: is the spy banlist planned to be a temporary measure or is it going to continue to exist indefinitely?

<r​ucknium:monero.social> This is a frequently asked question, or at least I anticipated that it would be. FAQ #5 "Are more universal fixes possible so that a specific ban list doesn't have to be used?": monero-project/meta #1124