Repository navigation
Improve Peer Discovery #430
Description
I am behind a NAT. The time spent running a node is irrelevant to the number of peer connections I get. I only ever get the connections to peers supplied by the --peers argument.
I should be able to initiate connections to peers whom I learned about from the bootstrap peers. But for some reason that is not happening.
Activity
dan-da commentedon Feb 13, 2025
I am seeing this also. Yeah it should be that my node (behind NAT) learns about new peers from the first (--peers) it connects to, and then connects to the new ones, and so on, up to --max-num-peers.
this should be a pretty high prio to fix.
gump1995 commentedon Feb 14, 2025
中国用户连接不上。请求帮助
aszepieniec commentedon Feb 14, 2025
Noted. Do you think it is because of NAT? If not, can you speculate on what the cause might be? In that case I guess it should be a separate issue.
aszepieniec commentedon Feb 14, 2025
This is not quite true: I noticed I got a fourth connection after only specifying three peers through the CLI.
Still, peer discovery is worth improving. Compared to other cryptocurrencies I've tried, it is slow.
aszepieniec commentedon Jun 15, 2025
Four months later, peer discovery continues to be pretty bad. Yes we have had other, higher-priority issues to focus on, but maybe part of the reason why no external contributors decided to take this task on is because of its poor definition. So in the hope to attract external contributors' attention (and otherwise to track our own progress) here is a proposed decomposition into subtasks.
aszepieniec commentedon Jun 15, 2025
PeerMessages without breaking.--peersin CLI.)skaunov commentedon Jul 4, 2025
Am I correct it's best to start with connections relaying (hole punching). What are the other nice to begin with parts?
aszepieniec commentedon Jul 6, 2025
Personally, I prefer fixing existing issues over developing new features. With that in mind, I would prioritize the last bullet point, fixing #488 and that probably involves fixing the first bullet point also.
aszepieniec commentedon Aug 23, 2025
I wanted to register for the record some interesting behavior. I am running a node on my desktop computer. I specified one bootstrapper node through the CLI. For several hours now, I am connected to only that bootstrapper node. The log looks like this:
I think this is what's going on:
Come to think of it, I vaguely recall something about avoiding connections to mutual peers. So then [::ffff:58.6.138.203]:9798 might only be used as an intermediate connection to get its peer list. This might explain why the node does not recognize the persistent failure. Of course, if this intermediate connection fails, this avoid-mutual-peers mechanism cannot proceed.
Based on this understanding I would organize tasks as follows (in addition to the tasks listed above):
As a side note, the difficulty I am having to establish that or any connection makes good testing ground for hole punching.
jan-ferdinand commentedon Dec 1, 2025
There are additional ideas on how to improve peer discovery and bootstrapping in this comment.
aszepieniec commentedon Jan 29, 2026
Time to close this thread. Most, if not all, of the feature-deficiencies are addressed by the Libp2p Network Stack #828. Not all todos in this thread were closed but the integration of the libp2p network stack does call their motivation into question. If any issues persist, open a new GitHub Issue.