Skip to content

Conversation

@Davidson-Souza
Copy link
Member

If we have 10 non-utreexo peers and we lose our last utreexo connection, we'll stop downloading blocks. With this commit, even if we have 10 peers, we allow one extra connection if we need a utreexo peer.

If we have 10 non-utreexo peers and we lose our last utreexo connection,
we'll stop downloading blocks. With this commit, even if we have 10
peers, we allow one extra connection if we need a utreexo peer.
@Davidson-Souza Davidson-Souza force-pushed the fix/force-utreexo-peer branch from 9f57f7f to b6f37ea Compare July 25, 2024 17:47
@jaoleal
Copy link
Collaborator

jaoleal commented Jul 25, 2024

But if we do need at least one utreexo peer to ibd, would not be good to only stop searching for peers after a certain amount of utreexo ones ? Even if we discart the normals while doing so.
Like making a priority for utreexo peers.

@Davidson-Souza
Copy link
Member Author

This code is not IBD only. In fact, the problem is more likely to happen inside running_node after a few hours running.

Also, we should keep non-utreexo peers, or we risk not learning about new blocks if there's not bridges in our direct graph.

@jaoleal
Copy link
Collaborator

jaoleal commented Jul 25, 2024

Yes, but still making utreexo peers a priority a bad idea ?

@Davidson-Souza
Copy link
Member Author

Yes, but still making utreexo peers a priority a bad idea ?

We prioritize utreexo peers if we don't have any. After that, we pick any good peer because there aren't that many utreexo peers out there.

@Davidson-Souza Davidson-Souza merged commit e9ab6d9 into master Jul 26, 2024
@Davidson-Souza Davidson-Souza deleted the fix/force-utreexo-peer branch July 26, 2024 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants