the thousand 'new buckets' approach and each node being able to access only 64 of them, does not seem to be helping much, considering that all the nodes advertise incoming addresses without checking them.
It helps against a personal attack - without it one could connect to a victim node and immediately fill all of its "new" buckets with junk. It only slows down a network-wide junk spread.
Now imagine scenario that you're starting a new node, with a brand new IP.
It is going to have a hard time getting incoming connections anytime soon, considering that it competes with hundreds of thousands of fake IPs.
It is going to have a hard time getting incoming connections anytime soon, considering that it competes with hundreds of thousands of fake IPs.
Competes in which way? If a node has a set of 20 addresses, 19 of which are junk and just 1 real and it wants to connect to somebody, then after some failed attempts it is going to connect to the 1 real one. There is no hurry. Trying to connect to a non-listening node (junk) takes a few seconds.
Plus every node looses time trying to connect to these fake addresses.
Not sure what is the core's algo of choosing a new IP to connect to, but whatever it is, it will surely also have to deal with a lot of dead tries.
Not sure what is the core's algo of choosing a new IP to connect to, but whatever it is, it will surely also have to deal with a lot of dead tries.
Yes, the failed attempts will waste some time.
Opening new connections in Bitcoin Core happens in CConnman::ThreadOpenConnections():
https://github.com/bitcoin/bitcoin/blob/1488f55fa57a1400a57be837b574183f019c7855/src/net.cpp#L1832
the address to connect to is chosen by calling CAddrMan::Select():
https://github.com/bitcoin/bitcoin/blob/1488f55fa57a1400a57be837b574183f019c7855/src/net.cpp#L2047
with some further filtering afterwards. CAddrMan::Select() is defined here:
https://github.com/bitcoin/bitcoin/blob/1488f55fa57a1400a57be837b574183f019c7855/src/addrman.cpp#L413
it can chose from the "new" and "tried" tables.