13:46:08 -xmr-pr- moneromooo-monero opened pull request #6939: p2p: give all hosts the same chance of being picked for connecting
13:46:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6939
14:15:39 <moneromooo> Would be be OK with another release when the P2P connection patches are in, assuming they do ? They should hopefully fix the 3 minute relay time problem, though we'll only know for sure once most of the network has updated.
14:16:03 <moneromooo> s/d b/d /peopl/
14:16:23 <moneromooo> Oh, look, a stray slash.
14:50:45 <moneromooo> vtnerd: you may want to check 6940 does not break something. The intent is to change the connections considered for stem phase destinations.
14:52:34 <sech1> But what if a peer doesn't relay blocks to you because you always relay blocks to that peer first?
14:53:23 <gingeropolous> then that peer isn't really integrated into the network
14:53:47 <moneromooo> What does "But what if a peer doesn't relay blocks to you because you always relay blocks to that peer first?" mean ?
14:54:19 <gingeropolous> it means that the peer is using you as its only connection to the network
14:54:36 <moneromooo> Ah. Then it'll get dropped.
14:54:37 <gingeropolous> which means it isn't worthy of receiving a tx
14:54:53 <gingeropolous> ( maybe? )
14:55:12 <moneromooo> It sure is pointless to send stem txes to it.
14:56:09 <moneromooo> And boy, do I hate this hard to read C++ style with structrures with operator() on them.
14:56:28 <gingeropolous> i mean, does a peer first check whether a peer has a lower blockheight before sending a block?
14:56:37 <gingeropolous> or it just blasts blocks to all of its peers
14:57:03 <moneromooo> I tihnk it might test whether it's close enough, from memory.
14:57:21 <moneromooo> Saves bandwidth if you think the peer will just drop it.
14:57:47 <moneromooo> Something like a few hundred IIRC.
14:58:03 <gingeropolous> well that could throw a spanner in this mechanism... if my node is height 4055, and a peer has a new block 4055, then it won't send to me?
14:58:37 <gingeropolous> or does this mechanism "fib" to a peer and say "yeah i totally haven't gotten a new block..."
14:58:51 <moneromooo> Hmm. Doesn't seem to do. Guess I never did it.
15:00:18 <sech1> I mean if you happen to send new blocks to some peer all the time, would that peer send blocks to you if it knows you already have them?
15:00:28 <moneromooo> No.
15:00:40 <sech1> so this scoring system could block such peer
15:00:46 <sech1> just because it has higher network latencies
15:01:08 -xmr-pr- moneromooo-monero opened pull request #6940: protocol: don't stem transactions to peers who don't relay blocks
15:01:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6940
15:01:29 <moneromooo> You wold not select that node  to test if you sent it the block.
15:01:35 <moneromooo> So I don't think it'd get dropped.
15:01:50 <sech1> ah, so you stop sending blocks to the nodes you test?
15:01:57 <moneromooo> Yes.
15:02:16 <moneromooo> And yes, it's easily bypassable.
15:03:39 <sech1> I'm more worried about false positives. False negatives will always happen with empirical tests.
15:04:25 <sech1> but forcing fake peers to relay blocks will certainly help the network :D
15:21:27 <gingeropolous> wownero is gonna implement
15:33:07 <UkoeHB__> how do nodes handle ddos of invalid tx? blacklist sender?
15:37:55 <moneromooo> Depends why the tx isn't valid. If really really invalid, it'll end up blocked in many cases.
15:46:26 <moneromooo> If I'm a node that has no incoming txes, I never the stem phases tx. It's intended, but it means a large part of the network is not used for dandelion routing.
15:48:04 <moneromooo> In particular, since spies always allow incoming, it gives them a larger percentarge of that dandelion sub network.
16:19:14 <kayront> so i've enabled inbound p2p connections over tor after discussing it here, and i'm seeing WAY more (like x20-x30) connections to my monero daemon vs bitcoin
16:19:18 <kayront> .. that strikes me as a bit strange
17:11:33 <yanmaani> gingeropolous: What if you just have 5000ms latency to network say? Like if you're using Tor with a bad circuit.
17:12:53 <yanmaani> Wouldn't setting some sort of per-ASN limit cut down on the spy problem? Instead of saying "select 1 random peer", say "select 1 random peer weighted by how many peers I have who are in its ASN".
17:13:46 <moneromooo> It would.
17:14:12 <yanmaani> so if I have 83 Hetzner peers, 24 OVH peers, 4 OvO peers, and 23 random peers each on unique residential IP blocks, the probability of me picking a given residential node is going to be 83 times higher than Hetzner.
17:14:17 <sech1> I think Bitcoin already has this type of filtering
17:14:57 <sech1> Residential nodes usually have their ports blocked
17:15:14 <sech1> For example I'm behind 2 NATs, no way to set up port passthrough
17:32:05 <gingeropolous> u don't have access to the first NAT?
17:39:15 <sech1> No, first NAT is off limits to me
17:39:26 <sech1> 2nd NAT is my router
18:43:33 <dEBRUYNE> vtnerd: Please prioritize investigating #6929
18:43:45 <dEBRUYNE> Getting numerous reports per day of people having their transactions stuck or failed
20:09:00 <luigi1111w> any feedback on ccs 138?
20:09:04 <selsta> I have been running the "detect and drop asshole peers" and checked every dropped peer against my list and did not have any false positives
20:28:34 <gingeropolous> 6939?
20:33:01 <selsta> gingeropolous: 6936
20:33:08 <selsta> did not tests PRs from today yet
20:33:12 <selsta> test*
21:11:53 <selsta> moneromooo: your patches all include if boost > 106600, but reproducible builds use 106400
21:12:53 <selsta> we can bump the boost version for depends / gitian, or do you intend on changing this?
21:21:22 <moneromooo> The make_address_v4 function appears in 1.66 AFAICT.
21:21:41 <moneromooo> I suppose I could copy it.
21:21:54 * moneromooo looks
21:29:18 <moneromooo> Actually 1.66 is from 2017, good enough.
21:44:07 <selsta> good enough meaning we should update depends boost.mk file?
21:44:29 <moneromooo> Yes.
21:45:33 <selsta> TheCharlatan: do you think this will bump our minimum glibc https://github.com/monero-project/monero/pull/6693 ?
21:46:03 <moneromooo> Actually, looks like this function's extractable...
21:46:17 <TheCharlatan> Probably not, but could check.
21:46:28 <selsta> extracting the function would be ideal, if possible
21:48:40 <moneromooo> I'll make a PR, doesn't looks like it's pulling anything funky.
21:49:13 <selsta> ty
21:49:35 <moneromooo> And obviously they have a custom licence...
22:02:16 <selsta> boost license should be compatible if the header is included
22:06:11 <moneromooo> done
22:06:23 <hyc> don't forget to create MONERO
22:06:39 <selsta> ty
22:12:34 <selsta> I would like to do a point release with mooo’s latest PRs relatively soon, seeing that we get a lot of reports of failed transactions
22:14:45 <moneromooo> They would not fix the failed ones, just the after-three-minutes ones.
22:15:08 <moneromooo> (unless the reason is 100% eclipsed nodes ?)
22:15:13 <hyc> do users know that their txns haven't failed, and are just taking 3 minutes?
22:15:23 <selsta> hyc: no, there is a bug that makes them fail
22:15:28 <selsta> not only long delay
22:15:45 <hyc> right, but how do users know the difference btw the two conditions?
22:16:01 <moneromooo> Wait an hour :P
22:16:08 -xmr-pr- moneromooo-monero opened pull request #6942: p2p: rewrite boost's make_address_v4 to cater for < 1.66
22:16:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6942
22:17:02 <selsta> moneromooo: the fail issue seems related to propagation after a timeout, so if we have less timeouts the issue should happen less often
22:17:04 <selsta> hopefully :D
22:18:32 <moneromooo> Would be nice to have people give opinions on how hard to club these nodes. Currently it's very slow.
22:19:02 <selsta> hyc: yea not ideal, though we don’t display it as failed currently for the first 4.5 minutes https://github.com/monero-project/monero/pull/6914
22:19:17 <moneromooo> I could test more than one peer per block (say, current out peers / 8 + 1 or so). This increases the probability that the peer also tests us at the same time -> both get a score drop.
22:19:47 <moneromooo> I could also test txes, but that's probably exploitable I think.
22:20:25 <selsta> moneromooo: does banning a node remove them from your peer list?
22:20:32 <moneromooo> Also, sweet spot between banning for a day and banning forever. The banm will happn hours after start already.
22:20:41 <moneromooo> I don't think it does.
22:20:43 * moneromooo goes look
22:21:15 <selsta> because if we ban these nodes from seed nodes (and also remove them from peer list), plus having your PRs should be okay for now IMO
22:21:19 <moneromooo> Doesn't appear to.
22:21:25 <selsta> better to not set it too aggressive for now
22:21:26 <iDunk> I see 6936 as an addition to 6920. 6920 (The Club) + 6936 (Heuristic).
22:22:02 <selsta> is it a lot of working removing peers if you manually ban them?
22:22:13 <selsta> code wise
22:22:37 <moneromooo> No.
22:22:57 <moneromooo> Could move them to grey, only white is sent.
22:23:03 <selsta> sounds good
22:23:44 <selsta> iDunk: yep agree
22:42:05 <selsta> okay we have everything PRed now for a further point release
22:42:26 <selsta> moneromooo: can you fix tests compilation with 6936?
22:46:08 -xmr-pr- moneromooo-monero opened pull request #6943: p2p: remove banned peers from the white list
22:46:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6943
23:35:49 <selsta> iDunk: what do you think about this comment? https://github.com/monero-project/monero/pull/6920/files#r512230265
23:36:09 <selsta> I don’t care which format we use.
23:40:00 <iDunk> I actually prefer that the ban list is a separate file. Future additions could be subnet banning and 6936 writing to the ban list file.
23:41:33 <iDunk> Btw, I have 0 bans with 6936.
23:42:12 <selsta> start monerod like this: ./monerod --log-level 0,net.cn:INFO,net.p2p.msg:INFO
23:42:20 <selsta> tail -f ~/.bitmonero/bitmonero.log | grep -E --line-buffered "bad peer"\|"waiting"
23:42:34 <selsta> afaik it will only get banned if a peer gets dropped twice which will take a while
23:42:58 <iDunk> I mean, I know it drops connections, but I'd expect "bans" to list any bans.