"give all hosts the same chance of being picked for connecting"

does this mean if someone runs multiple nodes on one IP they don’t have an advantage anymore?

Yes.

luigi1111: can you ban this person from the repo? monero-project/monero #6940#issuecomment-717651602

keeps spamming

done

moneromooo: we are going to add these, tag, and release into the into the wild git.wownero.com/wownero/wownero/compare/master...wowario:buttholes

any other commits we should cherry-pick?

.merges

wowario[m]: the full list is 6933 6935 6936 6939 6940 6942 6943

The dropping/banning is very slow though, you might want to increase it.

there are ~90 peers on wow network, by how much should I increase it?

are you referring to DROP_PEERS_ON_SCORE?

or context.m_score (5)?

DROP_PEERS_ON_SCORE and score decrease by 5.

DROP_PEERS_ON_SCORE is 10 IIRC, which means you need two fails to drop.

The more out peers you have on a node, the less likely it is each peer is tested. Monero has 12 atm.

DROP_PEERS_ON_SCORE -2

Ah, right, so a failure drops score by 1, takes two failures to drop the connection.

When it drops, it increases hte ban score by 5, and the peer gets banned at 10.

So 4 fails in total to get banned.

we've increase P2P_DEFAULT_CONNECTIONS_COUNT to 12

change DROP_PEERS_ON_SCORE to -5?

That'd drop them even less. You want -1 if you want to test more aggressively.

And replace 5 with 10 in the "drop_connection_with_score" call.

Then a single fail should ban.

Which is a bit harsh.

is logging thorough for these new functions? running on wownero network will help determine false positive rate - just off the cuff, i doubt wownero is being actively spied on / attacked.

so i guess i mean logging regarding ability to see which peers are getting banned

wownero also has a longer blocktime though. dunno how that factors in

5 min blocktime

The longer the block time, the slower peers are tested.

For logs, you grep for waiting\|bad\ peer (INFO level).

hrm, how can we mimic the attack? would running a node with --no-sync do it?

No.

could you add a monero AHP as a wownero peer? if the protocol is the same or similar enough

Doubt they'll oblige, given they're malicious in the first place.

what prevents the spy nodes from relaying blocks though?

Nothing. It just makes them conspicuous, which is odd.

Now they'll start hiding.

Occam's razor says they just could rent those boxes cheaper :)

wowario[m]: another you might want: 6944

14:13 <gingeropolous> is logging thorough for these new functions? running on wownero network will help determine false positive rate - just off the cuff, i doubt wownero is being actively spied on / attacked. <-- I did test for false positives on monero network and did not have a single peer have their score decreased in 12+ hours

so looks good, the 20 seconds waiting time is quite generous, usually blocks are relayed in less than a second

I had a fluffy block from a peer 1.5 minutes after everyone else. Shit happens from time to time.

right, not saying we should decrease the 20 seconds

btw I did a transaction this morning and it got relayed only after ~2 minutes, is this normal?

I have 64 peers out/20-30 in usually

normal?

Isn't 2 minutes too slow for tx propagation?

dandelion?

yes

all these spy nodes drop transactions so yes it is normal currently

I banned spy nodes, but I guess next node in the chain didn't

yep

so we have to put out a release soon and hope that many upgrade

plus manually ban them from as many nodes as possible

which reduce how often they show up in peer lists

should reduce*

selsta: Perhaps it would be worthwhile to issue a mailing list message

selsta : there isn't much of a fix for what the user described. 2 minutes is within the expectation for dandelion++ timeout

or I see, if everyone bans spying nodes it would possibly improve

that seems to be the hope, but sounds unrealistic to me

yeah they'll likely react somehow

the current PRs - which I plan to comment on shortly (hopefully) - would force them to use more disk+memory+cache I/O, so there's less "asymmetric warfare" going on with the number of connections they have vs honest nodes

*they can support. although, dunno yet there are some moves around that too though

that sounds all promising. if fake nodes are forced to do as much work as real nodes anyway, we've succeeded.

not sure is that has any repelling effect. the work a node does is pretty negligable imo. at least cpu/io wise

I think measuring the time-to-fluff might be the way to go after that. A long time means one node along the way dropped it. Maybe not the first one you're connected to, but one of those it's connected to, or recursively.

Dropping the first one means that overall, if everyone's doing the same thing, *some node somewhere* will be dropping the bad one.

Then it won't drop it again, and other nodes should start accreting.

was thinking about that. Would have to think about leaking path information via timings of switching. Should be difficult to identify without active txes

Actually, it might drop it again, since the length of the stem phase is random, so it'd have to be a threshold. Do more than N% of the stem txes I sent this peer get unreasonably delayed ?

It might end up unstable.

oh sorry I zoomed through your message a bit since it was similar to my idea

I was thinking instead of dropping the peer, just "re-roll" the selection on which outbound peer is used

because the next hop might be legit, so its not a complete turnover on connection

you might be able to score against that, because the next hop shouldn't keep selecting the next peer, but I dunno

deviates from the algorithm a bit, I'll dig into what grin has been doing

gingeropolous: do you have a long lived hidden service monerod ?

(or anyone else)

mine is

Address ?

hm, lemme dig it up

2xmrnode5itf65lz.onion

ty

Port is 18083 ?

18081

Sorry, I meant P2P, that's RPC, is it ?

oh, yes rpc only

I could add p2p too I guess

why 18083?

(reason being 6947 above)

Because that's what's in the doc, so easier :)

ok lemme tweak torrc

I guess it's in the docs because it's the first one free after zmq.

ok try it

reminds me. we have --rpc-bind-port and --rpc-restricted-bind-port, but only --rpc-bind-ip

would be nice to have --rpc-restricted-bind-ip

then could keep unrestricted bind-port open on localhost, and restricted-bind-port open on 0.0.0.0

I think smeone proposed that too on Github

I remember there being an issue for it

and maybe ignore --confirm-external-bind on the latter, since it's restricted anyway

igonre: don't require

hm, looking at issues now

I seem to be connecting, but it's closing the connection, failing to handshake.

It's connecting fine to other tor nodes tohugh.

hmm

I've never tested p2p

anything useful we can turn on in logging from this side?

Oh, it connected now. Then complains about bad zone. Probably my fault here.

all I'm doing is having tor forward to localhost:18080

Oh, so it thinks it's on clearnet, then sending clearnet peers.

Explains.

what do I need to do instead?

monero-project/monero #6947 has the steps :D

ok

They're from ANONYMITY_NETWORKS.md

Should be: --tx-proxy tor,127.0.0.1:9050,10 --anonymous-inbound 2xmrnode5itf65lz.onion:18083,127.0.0.1:18083,25

Tweak ports as necessary.

ok

ok try again

Works, thanks :)

hm, I didn't have that control socket stuff enabled in torrc. restarting tor again

ok, running again

ah found it, issue #6369