10:35:04 <makaros> hello
10:35:21 <makaros> can i ask for xmrig and network issues  here
11:20:46 <m-relay> <1​7lifers:matrix.org> use port 80/443 if the pool supports it if theres a firewall or isp filter blocking outgoing ports
13:46:22 <gingeropolous> seed node surviving 8634 inc connections...... while syncing....
13:59:41 <ofrnxmr> Bro u gotta be full of shit
13:59:58 <ofrnxmr> connections to *what*
14:00:47 <ofrnxmr> Gingeropolous
14:01:11 <gingeropolous> i dunno. INC cnxns p2p
14:01:22 <gingeropolous> its what the status reports.
14:02:35 <gingeropolous> however this socket statistcs command gives me 696
14:02:52 <gingeropolous>  "ss -tan | grep ":18080 " | wc -l"
14:03:02 <gingeropolous> so perhaps the daemon *is* full of shit
14:03:43 <gingeropolous> and 467 of them are in "close-wait"
14:04:13 <plowsof> Will check later 👀
14:04:36 <gingeropolous> danke
14:08:37 <gingeropolous> fyi plowsof its the release branch with the 2for1-reads patch in
14:09:01 <gingeropolous> or 2for1 writes. whatever it is
14:09:41 <ofrnxmr> 8634 p2p connections is wild
14:10:09 <ofrnxmr> I think btc limits to 100 by default. I dont think monero has a limit hmm
14:11:05 <ofrnxmr> But max-onnections-per-ip is 1 by default, so 8600 would assume 8600 different ips were connecting to you. Doesnt sound right 
14:28:14 <plowsof> gingeropolous "ss -tan | grep ":18080 " | wc -l" returns 346, 278 and 109
14:50:43 <m-relay> <o​frnxmr:xmr.mx> How many actual peers?
14:53:41 <plowsof> monerod status shows 180 in while that command shows 372
14:58:04 <m-relay> <o​frnxmr:xmr.mx> https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md
15:04:31 <m-relay> <o​frnxmr:xmr.mx> seed nodes could do with the maxuploadtarget, and blocksonly boog900  thoughts?
15:05:45 <m-relay> <o​frnxmr:xmr.mx> maxuploadtarget: When the limit is about to be reached, the uploaded data is cut by no longer serving historic blocks (blocks older than one week).
15:30:51 <m-relay> <b​oog900:monero.social> Allowing unlimited incoming connections makes a node very vulnerable beyond just bandwidth usage IMO. Seed nodes should just serve peer lists and immediately disconnect to reduce their attack surface. 
15:30:52 <m-relay> <b​oog900:monero.social> Having ways to reduce bandwidth consumption would probably be good for all nodes though.
15:36:14 <m-relay> <o​hchase:envs.net> since we are talking about seed nodes did want to get some opinions on https://github.com/monero-project/monero/issues/9695 still... The default behavior is set to use seed nodes and from what I can tell these all are inactive and owned by a single user, albeit a highly respected founder
15:36:39 <m-relay> <o​frnxmr:xmr.mx> 1. I agree. I dont know why monero has yolo limits for inc peer counts, AND has/had very low bandwidth limits. Doesnt seem well thought out. Should add a default cap on incoming peers imo. bandwidth limits also dont effect rpc.
15:36:40 <m-relay> <o​frnxmr:xmr.mx> 2. A seed-node mode node type, sure, but i imagine it would need to have blocks to know the diff between good and bad peers. most seed nodes are intentionally regular nodes. You could have the seed-node type by using blockonly and maxuploadtarget=0 or similar. Seed node type might also only store recent blocks
15:36:59 <m-relay> <o​frnxmr:xmr.mx> Fluffy isnt our founder, he's our pegasus
15:38:41 <m-relay> <b​oog900:monero.social> For `2` although it may make it easier to fake being a good node, it is already pretty easy to fake it (40% of the ips &  75% of the reachable nodes are already fake)
15:38:43 <m-relay> <o​hchase:envs.net> as in to be held even higher than a founder or as in not a founder but a visionary because the project was "founded" by just the community
15:38:54 <m-relay> <o​frnxmr:xmr.mx> Open pr to set to false ohchase
15:40:27 <m-relay> <o​hchase:envs.net> I wouId be happy to, but do you think just setting the default ones as empty is the better solution? Because that would mean monero still accepts the idea of seed nodes but at this time has not designated/decided what the standard is
15:40:52 <m-relay> <o​hchase:envs.net> This would also be my first contribution so I didn't want to just go guns blazing and over step
15:41:35 <m-relay> <o​frnxmr:xmr.mx> Not without some potential pushback. An argument could be that all seed nodes are attacked and go down, and instesd of pushing out a new release, we update the dns seeds and tell users to enable it
15:42:38 <m-relay> <o​frnxmr:xmr.mx> disabling it by default seems sane to me tho 🤷‍♂️
15:48:53 <m-relay> <o​hchase:envs.net> attempting a draft pr for now, lets see how this goes https://github.com/monero-project/monero/pull/9811 😰