kdeme

This issue is not 100% clear to me from its title and current description. First, what are we attempting to achieve? Speeding up the connection to good peers on a...

So the strange thing here is that it is a peer of a wrong network, see `Irrelevant peer` log, yet still we end up using it for syncing, which shouldn't...

So, from further placing logs in https://github.com/status-im/nimbus-eth2/blob/master/beacon_chain/eth2_network.nim#L424, I learned that it multiple disconnects are going on (from what I see, probably due to the fact that the peer connects again...

While the original cause of this issue has been resolved (connection to a peer from another network), I'm keeping this issue open as the actual flooding is not resolved. This...

Extra note: To investigate / PoC this, no actual (full) implementation of uTP would be needed

Some quick thoughts on the options I have in mind: 1. Use the `TalkReq` message type to encapsulate the uTP stream. As mentioned, this violates the current discv5 specification, as...

Current state: - Currently uTP is send over `TalkReq` messages (Option 1 from above comment): - `Talkresp` is send back empty, in order to satisfy discv5 (avoid routing table evictions),...

First item done by https://github.com/status-im/nimbus-eth1/commit/1e4f138574215fd796ab9f00a335991ba19153e0

Discv5 has the option the get the new IP:Port combination from information provided by its peers. Doesn't help for missing port mapping of course. For those set-ups where upnp/npmp is...

The original issue here was about "raw" (base class) Exceptions leaking. I don't like the proposed solution for this with two different modes. It is typically not so difficult to...