Use a random peer ID for lookup check

[xinaxu]

This fixes #966

[Jorropo]

Thx for investigating this but I don't see why this solves the bug.
AFAIT the situation is:

• we are starting a new DHT out of thin air
• rust-libp2p starts and has 0 peers.
• go-libp2p-kad-dht do FindPeer on rust-libp2p to check if it is a valid node, rust-libp2p has no peer in bucket yet and returns nothing.

Even if we request an other peer id I don't see why rust-libp2p would be able to respond with anything.
Am I wrong somewhere ?

[Jorropo]

This an expensive CPU operation the bits argument is ignored for Ed25519:
https://github.com/libp2p/go-libp2p/blob/cbfd89676cb2e775441d158fb607d66a94241ae2/core/crypto/key.go#L112-L113

Alternatives:

• Do it once at init (meh but fine)
• Do it once in new and store it as a field
• Use our own Peer ID
• Use a hardcoded whatever Peer ID.

[guillaumemichel]

Use our own Peer ID

👍🏻 Let's use our own Peer ID.

---

Edit:
Using our own Peer ID will not work when creating a new DHT network with 2 go-libp2p-kad-dht nodes:

• A and B are running and have 0 connected peers
• A learns about B
• A sends a check request to B
• B has still an empty routing table (because it didn't check A yet).
• B won't include itself in the response, hence it sends an empty response.
• A doesn't add B in its routing table.
• B knows about A, and sends it a check request
• A still has en empty routing table (B check failed)
• ...

[guillaumemichel]

In the rust-libp2p implementation, only requesting for the recipient key will trigger an empty response. If any other key is requested, the node should answer with nodes from its routing table. So requesting any other key should allow go-libp2p-kad-dht nodes to add rust-libp2p nodes to their routing table.

* _we are starting a new DHT out of thin air_

* rust-libp2p starts and has 0 peers.

* go-libp2p-kad-dht do FindPeer on rust-libp2p to check if it is a valid node, rust-libp2p has no peer in bucket yet and returns nothing.

In this case, rust-libp2p would add go-libp2p-kad-dht in its routing table after the failed check is performed. When rust-libp2p buckets will refresh (e.g after 10 minutes), it will ping go-libp2p-kad-dht, which will learn again about rust-libp2p, and check it again. This time, rust-libp2p will be able to answer with the go-libp2p-kad-dht peer id.

I agree with @Jorropo that generating a new random key every time is too expensive.

[guillaumemichel]

Alternatively, we could run the lookupCheck only if the nodes has a non-empty routing table, or at least 5 (?) nodes in its routing table. The node shouldn't be picky if it doesn't have any peers yet.

[guillaumemichel]

Closing as #966 is now resolved