YES

<j​effro256:monero.social> Yippee!

<j​effro256:monero.social> Guys I'm so sorry I wasted PR 10,000 on a stupid serialization warning fix, I didn't know...

<t​ritonn:matrix.org> 💀

<t​ritonn:matrix.org> 10k PRs is def insane though

<o​frnxmr:xmr.mx> You can always force push something better 🤣 (jk)

<r​ucknium:monero.social> According to my data, almost all IP addresses in the DNS block list have disappeared from the network some time in the last year. Has anyone else noticed this? It's possible that my data is wrong or misinterpreted, of course.

<r​ucknium:monero.social> The only nodes on the DNS block list remaining are the four `/24` subnets that the spy node adversary uses (not all `/24` spy node subnets are on the DNS block list yet): 91.198.115.0/24 162.218.65.0/24 199.116.84.0/24 209.222.252.0/24

<o​frnxmr:xmr.mx> So just linkinglion's spy nodes. The others were an attacker iirc. Maybe he got bored

<o​frnxmr:xmr.mx> Just the original* linkinglion spy nodes

<r​ucknium:monero.social> Last year, April-May, I gathered node logs from many users who recorded fluff-phase transaction relay info. In that dataset, almost all of the DNS-blocklist IPs appear as both inbound and outbound connections, relaying transactions.

<r​ucknium:monero.social> Or, today they could be hiding as unreachable nodes, still making outbound connections, but not accepting inbound connections. But my log data from a year ago said that they were accepting inbound connections.

<r​ucknium:monero.social> I wanted to suggest switching out three of the singleton IP addresses and add three `/24` subnets from the MRL ban list. I was trying to figure out which three existing entries would be best to switch out.

<r​ucknium:monero.social> "Attacker got bored" is my hypothesis, too. Of course, at any time the attacker could come back at the same IP addresses.

<a​ntilt:we2.ee> what were the common attacks modes / behavior that got them on the list back then ?

<r​ucknium:monero.social> I don't know, but someone in this room probably does.

most of these are from the 2020 network attack

where the nodes would for example report block height + 1

fireice was running these and selling the data from what i remember

<r​ucknium:monero.social> Thanks for the info :)

<a​ntilt:we2.ee> tx - height + 1

<a​ntilt:we2.ee> ... guess this is now spotted ? will look it up.

no, this hasn't been relevant in years

they did some things to annoy other nodes like incorrect block height, but later switched to pure passive surveillance

<a​ntilt:we2.ee> *tx = thanks

<a​ntilt:we2.ee> so, would be nice to remember those IPs and check them from time to time, before throwing them out

<a​ntilt:we2.ee> ... meaning, i'm all in favour for replacing these entries asap with @rucknium:monero.social's.

luigi1111: v0.18.4.1 would be ready to tag

please ping me once done

ok I think it worked

<o​frnxmr:xmr.mx> 💯

<o​frnxmr:xmr.mx> "let the build party begin"

some errors happened in Github actions gitian builds: github.com/monero-project/monero/actions/runs/16328184397

Probably intermittent, someone needs to restart builds