01:24:54 <selsta> "give all hosts the same chance of being picked for connecting"
01:25:15 <selsta> does this mean if someone runs multiple nodes on one IP they don’t have an advantage anymore?
02:06:32 <moneromooo> Yes.
02:33:54 <selsta> luigi1111: can you ban this person from the repo? https://github.com/monero-project/monero/pull/6940#issuecomment-717651602
02:33:57 <selsta> keeps spamming
03:24:51 <luigi1111w> done
04:43:30 <wowario[m]> moneromooo: we are going to add these, tag, and release into the into the wild https://git.wownero.com/wownero/wownero/compare/master...wowario:buttholes
04:44:18 <wowario[m]> any other commits we should cherry-pick?
07:45:39 <Snipa> .merges
07:45:40 -xmr-pr- 6886
11:44:03 <moneromooo> wowario[m]: the full list is 6933 6935 6936 6939 6940 6942 6943
11:44:23 <moneromooo> The dropping/banning is very slow though, you might want to increase it.
12:44:11 <wowario[m]> there are ~90 peers on wow network, by how much should I increase it?
12:47:36 <wowario[m]> are you referring to DROP_PEERS_ON_SCORE?
12:48:44 <wowario[m]> or context.m_score (5)?
12:52:57 <moneromooo> DROP_PEERS_ON_SCORE and score decrease by 5.
12:53:09 <moneromooo> DROP_PEERS_ON_SCORE is 10 IIRC, which means you need two fails to drop.
12:53:50 <moneromooo> The more out peers you  have on a node, the less likely it is each peer is tested. Monero has 12 atm.
12:53:50 <wowario[m]> DROP_PEERS_ON_SCORE -2
12:54:19 <moneromooo> Ah, right, so a failure drops score by 1, takes two failures to drop the connection.
12:54:51 <moneromooo> When it drops, it increases hte ban score by 5, and the peer gets banned at 10.
12:55:02 <moneromooo> So 4 fails in total to get banned.
12:55:48 <wowario[m]> we've increase P2P_DEFAULT_CONNECTIONS_COUNT to 12
12:56:54 <wowario[m]> change DROP_PEERS_ON_SCORE to -5?
12:57:36 <wowario[m]> https://git.wownero.com/wownero/wownero/pulls/341/files
12:58:22 <moneromooo> That'd drop them even less. You want -1 if you want to test more aggressively.
12:58:48 <moneromooo> And replace 5 with 10 in the "drop_connection_with_score" call.
12:58:55 <moneromooo> Then a single fail should ban.
12:58:59 <moneromooo> Which is a bit harsh.
13:08:31 <wowario[m]> https://git.wownero.com/wownero/wownero/commit/38b9be84f2f1d1d3a9ccb6bd6869091bf8da29de
13:13:24 <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.
13:13:56 <gingeropolous> so i guess i mean logging regarding ability to see which peers are getting banned
13:14:56 <gingeropolous> wownero also has a longer blocktime though. dunno how that factors in
13:16:32 <wowario[m]> 5 min blocktime
13:19:36 <moneromooo> The longer the block time, the slower peers are tested.
13:22:52 <moneromooo> For logs, you grep for waiting\|bad\ peer  (INFO level).
13:47:12 <gingeropolous> hrm, how can we mimic the attack? would running a node with --no-sync do it?
13:50:33 <moneromooo> No.
14:00:58 <n3ptune> could you add a monero AHP as a wownero peer? if the protocol is the same or similar enough
14:02:07 <moneromooo> Doubt they'll oblige, given they're malicious in the first place.
14:03:13 <yanmaani> what prevents the spy nodes from relaying blocks though?
14:03:32 <moneromooo> Nothing. It just makes them conspicuous, which is odd.
14:03:45 <moneromooo> Now they'll start hiding.
14:05:12 <moneromooo> Occam's razor says they just could rent those boxes cheaper :)
14:26:02 <moneromooo> wowario[m]: another you might want: 6944
14:31:08 -xmr-pr- moneromooo-monero opened pull request #6944: protocol: drop peers which repeatedly don't reply to chain requests
14:31:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6944
16:35:28 <selsta> 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
16:36:17 <selsta> so looks good, the 20 seconds waiting time is quite generous, usually blocks are relayed in less than a second
16:41:23 <moneromooo> I had a fluffy block from a peer 1.5 minutes after everyone else. Shit happens from time to time.
16:42:12 <selsta> right, not saying we should decrease the 20 seconds
16:42:25 <sech1> btw I did a transaction this morning and it got relayed only after ~2 minutes, is this normal?
16:42:33 <sech1> I have 64 peers out/20-30 in usually
16:42:35 <selsta> normal?
16:42:51 <sech1> Isn't 2 minutes too slow for tx propagation?
16:42:59 <selsta> dandelion?
16:43:13 <sech1> yes
16:43:15 <selsta> all these spy nodes drop transactions so yes it is normal currently
16:43:32 <sech1> I banned spy nodes, but I guess next node in the chain didn't
16:43:58 <selsta> yep
16:44:20 <selsta> so we have to put out a release soon and hope that many upgrade
16:44:29 <selsta> plus manually ban them from as many nodes as possible
16:44:43 <selsta> which reduce how often they show up in peer lists
16:44:51 <selsta> should reduce*
18:46:08 -xmr-pr- MoneroArbo opened issue #6945: "Edit" and "Copy" buttons in Account and Receive tabs are not visible ...
18:46:08 -xmr-pr- > https://github.com/monero-project/monero/issues/6945
18:47:30 <dEBRUYNE> selsta: Perhaps it would be worthwhile to issue a mailing list message
18:54:57 <vtnerd> selsta : there isn't much of a fix for what the user described. 2 minutes is within the expectation for dandelion++ timeout
18:55:42 <vtnerd> or I see, if everyone bans spying nodes it would possibly improve
18:56:02 <hyc> that seems to be the hope, but sounds unrealistic to me
18:56:13 <vtnerd> yeah they'll likely react somehow
18:57:16 <vtnerd> 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
18:58:52 <vtnerd> *they can support. although, dunno yet there are some moves around that too though
19:00:17 <hyc> that sounds all promising. if fake nodes are forced to do as much work as real nodes anyway, we've succeeded.
19:01:42 <M5M400> not sure is that has any repelling effect. the work a node does is pretty negligable imo. at least cpu/io wise
19:09:37 <moneromooo> 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.
19:10:12 <moneromooo> Dropping the first one means that overall, if everyone's doing the same thing, *some node somewhere* will be dropping the bad one.
19:10:34 <moneromooo> Then it won't drop it again, and other nodes should start accreting.
19:15:06 <vtnerd> was thinking about that. Would have to think about leaking path information via timings of switching. Should be difficult to identify without active txes
19:17:29 <moneromooo> 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 ?
19:17:46 <moneromooo> It might end up unstable.
19:37:29 <vtnerd> oh sorry I zoomed through your message a bit since it was similar to my idea
19:37:49 <vtnerd> I was thinking instead of dropping the peer, just "re-roll" the selection on which outbound peer is used
19:38:10 <vtnerd> because the next hop might be legit, so its not a complete turnover on connection
19:39:13 <vtnerd> you might be able to score against that, because the next hop shouldn't keep selecting the next peer, but I dunno
19:39:32 <vtnerd> deviates from the algorithm a bit, I'll dig into what grin has been doing
19:46:08 -xmr-pr- moneromooo-monero opened pull request #6946: protocol: prefer cycling low score peers
19:46:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6946
22:01:08 -xmr-pr- moneromooo-monero opened pull request #6947: add a convenience script to start monero with inbound tor
22:01:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6947
22:03:03 <moneromooo> gingeropolous: do you have a long lived hidden service monerod ?
22:14:10 <moneromooo> (or anyone else)
22:14:33 <hyc> mine is
22:15:52 <moneromooo> Address ?
22:16:58 <hyc> hm, lemme dig it up
22:17:53 <hyc> 2xmrnode5itf65lz.onion
22:17:55 <moneromooo> ty
22:18:16 <moneromooo> Port is 18083 ?
22:18:48 <hyc> 18081
22:19:58 <moneromooo> Sorry, I meant P2P, that's RPC, is it ?
22:20:05 <hyc> oh, yes rpc only
22:20:31 <hyc> I could add p2p too I guess
22:20:47 <hyc> why 18083?
22:20:49 <moneromooo> (reason being 6947 above)
22:21:00 <moneromooo> Because that's what's in the doc, so easier :)
22:21:10 <hyc> ok lemme tweak torrc
22:21:17 <moneromooo> I guess it's in the docs because it's the first one free after zmq.
22:24:08 <hyc> ok try it
22:27:10 <hyc> reminds me. we have --rpc-bind-port and --rpc-restricted-bind-port, but only --rpc-bind-ip
22:27:33 <hyc> would be nice to have --rpc-restricted-bind-ip
22:27:57 <hyc> then could keep unrestricted bind-port open on localhost, and restricted-bind-port open on 0.0.0.0
22:28:10 <dEBRUYNE> I think smeone proposed that too on Github
22:28:16 <dEBRUYNE> I remember there being an issue for it
22:28:27 <hyc> and maybe ignore --confirm-external-bind on the latter, since it's restricted anyway
22:28:41 <hyc> igonre: don't require
22:29:13 <hyc> hm, looking at issues now
22:29:31 <moneromooo> I seem to be connecting, but it's closing the connection, failing to handshake.
22:29:40 <moneromooo> It's connecting fine to other tor nodes tohugh.
22:30:40 <hyc> hmm
22:30:58 <hyc> I've never tested p2p
22:31:09 <hyc> anything useful we can turn on in logging from this side?
22:31:53 <moneromooo> Oh, it connected now. Then complains about bad zone. Probably my fault here.
22:32:26 <hyc> all I'm doing is having tor forward to localhost:18080
22:32:50 <moneromooo> Oh, so it thinks it's on clearnet, then sending clearnet peers.
22:32:57 <moneromooo> Explains.
22:33:05 <hyc> what do I need to do instead?
22:33:16 <moneromooo> https://github.com/monero-project/monero/pull/6947 has the steps :D
22:33:24 <hyc> ok
22:33:25 <moneromooo> They're from ANONYMITY_NETWORKS.md
22:34:04 <moneromooo> Should be: --tx-proxy tor,127.0.0.1:9050,10 --anonymous-inbound 2xmrnode5itf65lz.onion:18083,127.0.0.1:18083,25
22:34:14 <moneromooo> Tweak ports as necessary.
22:34:56 <hyc> ok
22:36:54 <hyc> ok try again
22:37:56 <moneromooo> Works, thanks :)
22:40:07 <hyc> hm, I didn't have that control socket stuff enabled in torrc. restarting tor again
22:42:34 <hyc> ok, running again
22:45:33 <hyc> ah found it, issue #6369