-
makaros
hello
-
makaros
can i ask for xmrig and network issues here
-
m-relay
<17lifers:matrix.org> use port 80/443 if the pool supports it if theres a firewall or isp filter blocking outgoing ports
-
gingeropolous
seed node surviving 8634 inc connections...... while syncing....
-
ofrnxmr
Bro u gotta be full of shit
-
ofrnxmr
connections to *what*
-
ofrnxmr
Gingeropolous
-
gingeropolous
i dunno. INC cnxns p2p
-
gingeropolous
its what the status reports.
-
gingeropolous
however this socket statistcs command gives me 696
-
gingeropolous
"ss -tan | grep ":18080 " | wc -l"
-
gingeropolous
so perhaps the daemon *is* full of shit
-
gingeropolous
and 467 of them are in "close-wait"
-
plowsof
Will check later 👀
-
gingeropolous
danke
-
gingeropolous
fyi plowsof its the release branch with the 2for1-reads patch in
-
gingeropolous
or 2for1 writes. whatever it is
-
ofrnxmr
8634 p2p connections is wild
-
ofrnxmr
I think btc limits to 100 by default. I dont think monero has a limit hmm
-
ofrnxmr
But max-onnections-per-ip is 1 by default, so 8600 would assume 8600 different ips were connecting to you. Doesnt sound right
-
plowsof
gingeropolous "ss -tan | grep ":18080 " | wc -l" returns 346, 278 and 109
-
m-relay
<ofrnxmr:xmr.mx> How many actual peers?
-
plowsof
monerod status shows 180 in while that command shows 372
-
m-relay
-
m-relay
<ofrnxmr:xmr.mx> seed nodes could do with the maxuploadtarget, and blocksonly boog900 thoughts?
-
m-relay
<ofrnxmr: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).
-
m-relay
<boog900: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.
-
m-relay
<boog900:monero.social> Having ways to reduce bandwidth consumption would probably be good for all nodes though.
-
m-relay
<ohchase: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
-
m-relay
<ofrnxmr: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.
-
m-relay
<ofrnxmr: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
-
m-relay
<ofrnxmr:xmr.mx> Fluffy isnt our founder, he's our pegasus
-
m-relay
<boog900: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)
-
m-relay
<ohchase: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
-
m-relay
<ofrnxmr:xmr.mx> Open pr to set to false ohchase
-
m-relay
<ohchase: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
-
m-relay
<ohchase:envs.net> This would also be my first contribution so I didn't want to just go guns blazing and over step
-
m-relay
<ofrnxmr: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
-
m-relay
<ofrnxmr:xmr.mx> disabling it by default seems sane to me tho 🤷♂️
-
m-relay
<ohchase:envs.net> attempting a draft pr for now, lets see how this goes
monero-project/monero #9811 😰
-
m-relay
<ohchase: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 dns seed nodes but at this time has not designated/decided what the standard is
-
m-relay
<321bob321:monero.social> There is that many people running i2p overall ?
-
m-relay
<321bob321:monero.social> CEO sir
-
m-relay
<detherminal:monero.social> Everybody is nobody in this project.
-
m-relay
<321bob321:monero.social> everybody is somebody to someone