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.

s/d b/d /peopl/

Oh, look, a stray slash.

vtnerd: you may want to check 6940 does not break something. The intent is to change the connections considered for stem phase destinations.

But what if a peer doesn't relay blocks to you because you always relay blocks to that peer first?

then that peer isn't really integrated into the network

What does "But what if a peer doesn't relay blocks to you because you always relay blocks to that peer first?" mean ?

it means that the peer is using you as its only connection to the network

Ah. Then it'll get dropped.

which means it isn't worthy of receiving a tx

( maybe? )

It sure is pointless to send stem txes to it.

And boy, do I hate this hard to read C++ style with structrures with operator() on them.

i mean, does a peer first check whether a peer has a lower blockheight before sending a block?

or it just blasts blocks to all of its peers

I tihnk it might test whether it's close enough, from memory.

Saves bandwidth if you think the peer will just drop it.

Something like a few hundred IIRC.

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?

or does this mechanism "fib" to a peer and say "yeah i totally haven't gotten a new block..."

Hmm. Doesn't seem to do. Guess I never did it.

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?

No.

so this scoring system could block such peer

just because it has higher network latencies

You wold not select that node to test if you sent it the block.

So I don't think it'd get dropped.

ah, so you stop sending blocks to the nodes you test?

Yes.

And yes, it's easily bypassable.

I'm more worried about false positives. False negatives will always happen with empirical tests.

but forcing fake peers to relay blocks will certainly help the network :D

wownero is gonna implement

how do nodes handle ddos of invalid tx? blacklist sender?

Depends why the tx isn't valid. If really really invalid, it'll end up blocked in many cases.

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.

In particular, since spies always allow incoming, it gives them a larger percentarge of that dandelion sub network.

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

.. that strikes me as a bit strange

gingeropolous: What if you just have 5000ms latency to network say? Like if you're using Tor with a bad circuit.

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

It would.

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.

I think Bitcoin already has this type of filtering

Residential nodes usually have their ports blocked

For example I'm behind 2 NATs, no way to set up port passthrough

u don't have access to the first NAT?

No, first NAT is off limits to me

2nd NAT is my router

vtnerd: Please prioritize investigating #6929

Getting numerous reports per day of people having their transactions stuck or failed

any feedback on ccs 138?

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

6939?

gingeropolous: 6936

did not tests PRs from today yet

test*

moneromooo: your patches all include if boost > 106600, but reproducible builds use 106400

we can bump the boost version for depends / gitian, or do you intend on changing this?

The make_address_v4 function appears in 1.66 AFAICT.

I suppose I could copy it.

Actually 1.66 is from 2017, good enough.

good enough meaning we should update depends boost.mk file?

Yes.

TheCharlatan: do you think this will bump our minimum glibc monero-project/monero #6693 ?

Actually, looks like this function's extractable...

Probably not, but could check.

extracting the function would be ideal, if possible

I'll make a PR, doesn't looks like it's pulling anything funky.

ty

And obviously they have a custom licence...

boost license should be compatible if the header is included

done

don't forget to create MONERO

ty

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

They would not fix the failed ones, just the after-three-minutes ones.

(unless the reason is 100% eclipsed nodes ?)

do users know that their txns haven't failed, and are just taking 3 minutes?

hyc: no, there is a bug that makes them fail

not only long delay

right, but how do users know the difference btw the two conditions?

Wait an hour :P

moneromooo: the fail issue seems related to propagation after a timeout, so if we have less timeouts the issue should happen less often

hopefully :D

Would be nice to have people give opinions on how hard to club these nodes. Currently it's very slow.

hyc: yea not ideal, though we don’t display it as failed currently for the first 4.5 minutes monero-project/monero #6914

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.

I could also test txes, but that's probably exploitable I think.

moneromooo: does banning a node remove them from your peer list?

Also, sweet spot between banning for a day and banning forever. The banm will happn hours after start already.

I don't think it does.

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

Doesn't appear to.

better to not set it too aggressive for now

I see 6936 as an addition to 6920. 6920 (The Club) + 6936 (Heuristic).

is it a lot of working removing peers if you manually ban them?

code wise

No.

Could move them to grey, only white is sent.

sounds good

iDunk: yep agree

okay we have everything PRed now for a further point release

moneromooo: can you fix tests compilation with 6936?

iDunk: what do you think about this comment? monero-project/monero #6920/files#r512230265

I don’t care which format we use.

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.

Btw, I have 0 bans with 6936.

start monerod like this: ./monerod --log-level 0,net.cn:INFO,net.p2p.msg:INFO

tail -f ~/.bitmonero/bitmonero.log | grep -E --line-buffered "bad peer"\|"waiting"

afaik it will only get banned if a peer gets dropped twice which will take a while

I mean, I know it drops connections, but I'd expect "bans" to list any bans.