04:43:27 <luigi1111> YES
05:06:20 <m-relay> <j​effro256:monero.social> Yippee!
05:07:01 <m-relay> <j​effro256:monero.social> Guys I'm so sorry I wasted PR 10,000 on a stupid serialization warning fix, I didn't know...
05:08:04 <m-relay> <t​ritonn:matrix.org> 💀
05:08:28 <m-relay> <t​ritonn:matrix.org> 10k PRs is def insane though
05:09:14 <m-relay> <o​frnxmr:xmr.mx> You can always force push something better 🤣 (jk)
16:38:19 <m-relay> <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.
16:39:46 <m-relay> <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
16:40:37 <m-relay> <o​frnxmr:xmr.mx> So just linkinglion's spy nodes. The others were an attacker iirc. Maybe he got bored
16:40:53 <m-relay> <o​frnxmr:xmr.mx> Just the original* linkinglion spy nodes
16:41:35 <m-relay> <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.
16:45:15 <m-relay> <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.
16:46:19 <m-relay> <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.
16:47:34 <m-relay> <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.
16:54:37 <m-relay> <a​ntilt:we2.ee> what were the common attacks modes / behavior that got them on the list back then ?
16:55:39 <m-relay> <r​ucknium:monero.social> I don't know, but someone in this room probably does.
17:00:42 <selsta> most of these are from the 2020 network attack
17:00:57 <selsta> where the nodes would for example report block height + 1
17:01:27 <selsta> fireice was running these and selling the data from what i remember
17:03:55 <rbrunner> https://x.com/mbadcaca
17:10:32 <m-relay> <r​ucknium:monero.social> Thanks for the info :)
17:14:23 <m-relay> <a​ntilt:we2.ee> tx - height + 1 
17:14:23 <m-relay> <a​ntilt:we2.ee> ... guess this is now spotted ? will look it up.
17:14:40 <selsta> no, this hasn't been relevant in years
17:15:10 <selsta> they did some things to annoy other nodes like incorrect block height, but later switched to pure passive surveillance
17:15:28 <m-relay> <a​ntilt:we2.ee> *tx = thanks
17:17:22 <m-relay> <a​ntilt:we2.ee> so, would be nice to remember those IPs and check them from time to time, before throwing them out
17:29:29 <m-relay> <a​ntilt:we2.ee> ... meaning, i'm all in favour for replacing these entries asap with @rucknium:monero.social's.
18:23:42 <selsta> luigi1111: v0.18.4.1 would be ready to tag
18:23:50 <selsta> please ping me once done
19:11:29 <luigi1111> ok I think it worked
19:41:41 <m-relay> <o​frnxmr:xmr.mx> 💯
19:42:10 <m-relay> <o​frnxmr:xmr.mx> "let the build party begin"
20:14:46 <sech1> some errors happened in Github actions gitian builds: https://github.com/monero-project/monero/actions/runs/16328184397
20:14:55 <sech1> Probably intermittent, someone needs to restart builds
20:34:51 <scoobybejesus_tl> https://paste.debian.net/plain/1386251