Aha.

<s​yntheticbird:monero.social> I think i've seen this subnet in the blocklist

The IP is connecting to my node, sending a ping command to stay alive. Then whenever I get a new transaction come in, it sends request 1007

this log level 1

<g​ooglemozilla:matrix.org> What does request 1007 do?

RECEIVED_NEW_TRANSACTIONS, like 50ms laters send 1007

chatgpt says NOTIFY_NEW_TRANSACTIONS

hmm

chatgtp?

im just asking chatgpt what the hell command-100X means in the level 1 logs

there this weird node connecting to peoples node and doing funky stuff with transactions

I think its trying to break dandelion++

<b​oog900:monero.social> it's known: monero-project/research-lab #126

<g​ooglemozilla:matrix.org> Smells like Chainalysis.

yea

<g​ooglemozilla:matrix.org> Banning IPs won't be an effective solution, as that would only address a temporary symptom rather than the underlying problem. However, if we encourage users to use TOR or I2P when sending transactions, it could render eavesdropping attempts futile. What are your thoughts on this approach?

some of my nodes are both clearnet and tor

I should probably add enable-dns-blocklist

<b​oog900:monero.social> it would be a good solution, however our Tor impl is not perfect: dl.acm.org/doi/abs/10.1145/3589335.3651487 (going to fixed). Plus with the amount of nodes they run it's a network security risk as well

<b​oog900:monero.social> it would be a good solution, however our Tor impl is not perfect: dl.acm.org/doi/abs/10.1145/3589335.3651487 (going to be fixed). Plus with the amount of nodes they run it's a network security risk as well

<g​ooglemozilla:matrix.org> How will this be fixed?

<e​longated:matrix.org> tx-proxy

<g​ooglemozilla:matrix.org> Isn't this already supported?

<e​longated:matrix.org> Use it ?

boog900

should i stop having my nodes priority-node connect to each other

<e​longated:matrix.org> Oh nvm this is a different issue

<g​ooglemozilla:matrix.org> I don't understand.

If a public client sends a transaction through one of my public nodes

and my public nodes choose my other public nodes as that anonymity stage for dandelion

<b​oog900:monero.social> by not inserting the nodes incoming onion address to the end of the peer list message + by randomly re-routing txs over, currently they only do 1 Tor hop

these trackers can connect to all my public nodes to try and pick up the fluff stage

but this is is probably unlikely

my nodes are unlikely to choose my priority nodes as the initial anonymity stage dandelion all time.

its I assume 1/the number of nodes you are currently connected to

<g​ooglemozilla:matrix.org> I don't think Tor is a good solution for the long term, though. Considering that most nodes are suspiciously located in Germany, which may be run by Interpol, is it possible to migrate to I2P instead?

<b​oog900:monero.social> only outbound connections are used to stem, I would just ban the nodes: github.com/Boog900/monero-ban-list/tree/main

is priority node in bound our outbound connection? what if two nodes have priority-node for each other

that means they are always connected

<b​oog900:monero.social> you can use I2p with monero now, it gets priority for routing your txs if you set Tor as well.

says you have 50 outbound connections

then every 1/50 transactions you get, you'll send it to your other node your are priority connected to

we should probably disable sending txs to priority nodes imo

<b​oog900:monero.social> > is priority node in bound our outbound connection?

<b​oog900:monero.social> outbound

<b​oog900:monero.social> > what if two nodes have priority-node for each other

<b​oog900:monero.social> No clue, probably which eve connects first has the peer as outbound

<b​oog900:monero.social> ever*

<b​oog900:monero.social> > we should probably disable sending txs to priority nodes imo

<b​oog900:monero.social> why?

yea, so the stem phase may be sent to your priority nodes

and an advesary knows what your public nodes are

they can connect to your public nodes and listen for transactions

obviously its unlikely that all your stem transmits will go to another priority node you have

buts its possible

<b​oog900:monero.social> I don't see how that's a problem, they would still need your node to connect to a spy and for that spy to be chosen as a stem

<s​ethforprivacy:monero.social> Done:

<s​ethforprivacy:monero.social> sethforprivacy/simple-monerod-docker cea9d8c

<s​ethforprivacy:monero.social> Note that anyone running the image WITHOUT setting any custom flags/configs will get the ban list automatically applied, but anyone customizing the config at all (most people) will need to add this line to their command or config:

<s​ethforprivacy:monero.social> `--ban-list=/home/monero/ban_list.txt`

<s​ethforprivacy:monero.social> OR

<s​ethforprivacy:monero.social> `ban-list=/home/monero/ban_list.txt`

<s​ethforprivacy:monero.social> The ban list itself is the latest from boog900 but is locally pinned as I didn't want to pull in an external repo I have no control over at build time. If there are major updates to the list please let me know.

<s​ethforprivacy:monero.social> I've subscribed to changes to the repo so will do my best to keep up with it.

<r​ucknium:monero.social> Seth For Privacy: Thank you!

hmm

If I use a vps with an ipv6 range

I can host at my house a proxmox node. On there I can put tiny stupidly underpowered (half fractional cpu, 1gb ram, lots of swap) vms on them. I can route the traffic from the vms to each ipv6 address on my vps

this can like fight the war against these fake proxy nodes

the nodes don't have to be fast enough for public rpc access, just used for p2p

<g​ooglemozilla:matrix.org> As more and more legitimate nodes emerge, I assume that this threat will have fewer impacts, since the probability of a spy node being selected as one of the D++ nodes becomes much smaller?

or dandelion++ gets replaced

<g​ooglemozilla:matrix.org> As more and more legitimate nodes emerge, I assume that this threat will have fewer impacts, since the probability of a spy node being selected as one of the D++ leaves becomes much smaller?

<g​ooglemozilla:matrix.org> What alternatives are there? I'm not aware of any.

<o​frnxmr:xmr.mx> Tor / i2p

<g​ooglemozilla:matrix.org> Forcing only Tor and I2P usage?

honestly I agree, tor is just much better solution overall. A fully synced node doesn't use that much bandwidth anyway.

We need more nodes on tor. It's also a lot easier to host tor entry nodes than exit nodes

Basically anyone can host a tor entry node, so, hopefully it wouldn't be too much of a strain on the tor network.