hello

can i ask for xmrig and network issues  here

<1​7lifers:matrix.org> use port 80/443 if the pool supports it if theres a firewall or isp filter blocking outgoing ports

seed node surviving 8634 inc connections...... while syncing....

Bro u gotta be full of shit

connections to *what*

Gingeropolous

i dunno. INC cnxns p2p

its what the status reports.

however this socket statistcs command gives me 696

"ss -tan | grep ":18080 " | wc -l"

so perhaps the daemon *is* full of shit

and 467 of them are in "close-wait"

Will check later 👀

danke

fyi plowsof its the release branch with the 2for1-reads patch in

or 2for1 writes. whatever it is

8634 p2p connections is wild

I think btc limits to 100 by default. I dont think monero has a limit hmm

But max-onnections-per-ip is 1 by default, so 8600 would assume 8600 different ips were connecting to you. Doesnt sound right

gingeropolous "ss -tan | grep ":18080 " | wc -l" returns 346, 278 and 109

<o​frnxmr:xmr.mx> How many actual peers?

monerod status shows 180 in while that command shows 372

<o​frnxmr:xmr.mx> github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md

<o​frnxmr:xmr.mx> seed nodes could do with the maxuploadtarget, and blocksonly boog900 thoughts?

<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).

<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.

<b​oog900:monero.social> Having ways to reduce bandwidth consumption would probably be good for all nodes though.

<o​hchase:envs.net> since we are talking about seed nodes did want to get some opinions on monero-project/monero #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

<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.

<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

<o​frnxmr:xmr.mx> Fluffy isnt our founder, he's our pegasus

<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)

<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

<o​frnxmr:xmr.mx> Open pr to set to false ohchase

<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

<o​hchase:envs.net> This would also be my first contribution so I didn't want to just go guns blazing and over step

<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

<o​frnxmr:xmr.mx> disabling it by default seems sane to me tho 🤷‍♂️

<o​hchase:envs.net> attempting a draft pr for now, lets see how this goes monero-project/monero #9811 😰