Finding peers to connect to after -onlynet changes may be problematic #26035

1. 
   vasild commented at 12:19 pm on September 7, 2022: contributor

   Expected behavior

   Bitcoin Core, ideally, should always have peers to try to connect to just like when started for the very first time (empty peers.dat). It should not be more difficult to find possible peers if it was ran before with a different -onlynet= setting.

   Actual behavior

   If addrman has some entries, even to only unreachable networks, due to previous runs and changes in -onlynet, then the fixed seeds will not be used.

   To reproduce

   Run with -onlynet=ipv4, change to -onlynet=i2p.

   To fix

   This problem is two-fold:

   1. Fixed seeds should be used if we have 0 reachable peers in addrman. I guess this condition should be relaxed, like discussed in #25678 (comment)

   https://github.com/bitcoin/bitcoin/blob/fc44d1796e4df5824423d7d13de3082fe204db7d/src/net.cpp#L1628

   2. Even if there are a few reachable peers in addrman, e.g. 0.1% it will take a long time before they are tried. The address selection logic can be improved. It is, simplified, like this (see lines 1797 and 1810):

   0select random address
   1if not reachable then try another random address
   

   Can be improved to “select random address, but only from reachable networks”.

   This problem is amplified by the fact that we do not save non-reachable addresses in addrman during p2p gossip (and also see #25678). Maybe we should reconsider that as a 3rd fixup, in addition to the above 2 - save even unreachable addresses in addrman during p2p gossip and fixed seeds loadup? What is the worst that can happen? We will have some wasted space in addrman if onlynet is never altered?

2. vasild added the label Bug on Sep 7, 2022
3. 
   kristapsk commented at 12:36 pm on September 7, 2022: contributor

   I had similar issue with Bitcoin Core on laptop, with -onlynet=onion, that wasn’t started for some time. In between Tor upgrade was done in the machine and later Bitcoin Core just continuously tried to connect to cached Tor v2 onion peers, which it, of course, was unable to do, as new versions of Tor support only v3 onions. I solved issue by manually adding some known Tor v3 peer, but some less tech savvy user could have got stuck there.
4. fanquake added the label P2P on Sep 7, 2022
5. 
   ghost commented at 3:35 pm on September 7, 2022: none

   I solved issue by manually adding some known Tor v3 peer, but some less tech savvy user could have got stuck there.

   Yes using onlynet, different combinations and fixing these issues is not easy for less tech savvy users.

6. 
   vasild commented at 4:02 pm on September 7, 2022: contributor

   A blatant way to workaround this is to delete peers.dat, but that is more for the brave and again not for the less tech savvy users. And has the obvious problem that all the addresses collected so far are lost.
7. 
   Sjors commented at 3:35 pm on September 8, 2022: member

   Both solutions in the first comment make sense, at least at first glance.
8. 
   mzumsande commented at 4:54 pm on September 8, 2022: contributor

   A very interesting long-term solution (not just for this problem, it would have several other benefits) would be to have a separate addrman for each network instead of one shared addrman.
9. bitcoin deleted a comment on Sep 8, 2022
10. 
    vasild commented at 7:16 am on September 16, 2022: contributor

    A possible improvement very much related to this: try to maintain at least 1 outbound connection to each reachable network.

    Currently the chance of selecting a peer from network X to connect to depends on how many such peers are in addrman, compared to all addrman entries. It is dominated by IPv4 peers.

11. 
    jonatack commented at 7:33 am on September 16, 2022: member

    Maybe related, and also to today’s bitcoin-core-dev IRC discussion that I’m reading, last week I synced up a new node from scratch, ran it with clearnet/tor/i2p services enabled, all listening, and didn’t see any I2P peers organically for several days until adding some manually with addnode.
12. 
    jonatack commented at 8:12 am on September 16, 2022: member

    have a separate addrman for each network

    Yes, this idea has been around for years. I recall @TheBlueMatt mentioning it as an aside in a review club session on ASMap in 2019 and @sipa on IRC after another session as well.

13. 
    kristapsk commented at 2:16 pm on September 16, 2022: contributor

    Trying to maintain at least 1 outbound connection to each reachable network sounds good idea to me. Not only because of this but also because of redundancy (imagine node configured as Tor and I2P only and Tor network is under heavy attack and not working normally at some moment, then you will have at least one I2P connection all the time and will continue to receive new blocks).
14. 
    Rspigler commented at 10:06 pm on September 16, 2022: contributor

    try to maintain at least 1 outbound connection to each reachable network.

    Concept ACK

    last week I synced up a new node from scratch, ran it with clearnet/tor/i2p services enabled, all listening, and didn’t see any I2P peers organically for several days until adding some manually with addnode.

    Yes, this is exactly what I did earlier this week and posted my issue on bitcoin-core-dev IRC. For network diversity I think this is a good idea

15. 
    Rspigler commented at 10:10 pm on September 16, 2022: contributor

    For the possible 3rd fixup:

    save even unreachable addresses in addrman during p2p gossip

    Would this mean that for example, i2p addresses are gossiped for nodes that only have ipv4 addresses? That would make incoming i2p connections easier to make

16. 
    vasild commented at 7:36 am on September 19, 2022: contributor

    Would this mean that for example, i2p addresses are gossiped for nodes that only have ipv4 addresses?

    I am not sure I understand the question, but there are a few things here, when we receive an address gossiped by somebody to us:

    1. Whether we gossip it to others 1.1. We do regardless of the address of the recipient, i.e. we could gossip I2P address to IPv4 peer (we do not know if that IPv4 peer has I2P connectivity or not) 1.2. If the address being gossiped is of unreachable network (from our point of view), then we gossip it less
    2. Whether we save it to our addrman 2.1. We only save addresses from reachable networks
17. 
    Rspigler commented at 10:18 pm on September 19, 2022: contributor

    Thank you for the explanation.

    What is the reasoning behind 1.2? Would it not benefit the network to have better gossiped addresses, especially for networks like I2P and CJDNS?

18. 
    mzumsande commented at 6:31 pm on September 23, 2022: contributor

    What is the reasoning behind 1.2? Would it not benefit the network to have better gossiped addresses, especially for networks like I2P and CJDNS?

    The general idea that addresses are more strongly gossiped among those nodes that actually can make use of them makes sense to me. Having all the clearnet-only nodes constantly exchanging I2P or onion addresses on the same scale as IPv4 seems a bit wasteful.

19. achow101 referenced this in commit ba3d32715f on Jan 31, 2023
20. 
    CocolinoFan commented at 1:22 pm on June 28, 2023: none

    100% agree my node is running for 5 days now on IPv4, i2p, cjdns and Tor. I have 75 in peers for IPv4 but 0 for the rest. I can manually add peers for i2p, cjdns and Tor but in my mind it should work like [vasild] said, maintain at least one connection to every available network.
21. 
    vasild commented at 2:31 pm on June 28, 2023: contributor

    @CocolinoFan what you describe is problem 2 from the OP. A fix for it is at #27213. It would be nice if you can test and/or review that.
22. 
    vasild commented at 7:57 am on August 12, 2024: contributor

    This has been fixed by:

    #26847 #27213

    closing as resolved.

23. vasild closed this on Aug 12, 2024

    ---

Contributors
vasild kristapsk ghost Sjors mzumsande jonatack Rspigler CocolinoFan

Labels
Bug P2P