Remove "revoked" node ID -> node address mappings in NodeGraph

[joshuakarp]

The buckets database used to store node ID -> node address (host:port) mappings is a fixed-size structure, of n buckets containing k mappings each.

Because a public key can be revoked and refreshed, and the node ID is the public key fingerprint, there is the potential for a keynode to require a new node ID (and thus, new certificate/s as well).

This introduces a trade-off:

• We introduce a redundant key-value pair in our buckets database, where two node IDs are mapping to the same host and port. After learning of the updated node ID, do we remove this node ID from the database altogether? Furthermore, we can have malicious actors that repeatedly perform this action, and congest the network's node databases, by introducing a multitude of keys that map to the same host and port.
• But, other systems may require a legitimate earlier node ID -> node address mapping in order to connect (as they may not know about the newest node ID)
  • NOTE: do we actually want this node ID to be considered valid anymore though? That is, If the public key has been refreshed, would we not want to remove this node ID -> node address mapping entirely? Essentially, when a public key is refreshed, we would therefore consider it as a "new node" in the network, where all other nodes are unaware of it.
  • Perhaps we still do. While the node ID may be considered as compromised, the host and port that it maps to would likely remain unchanged?

[joshuakarp]

This issue needs significantly more fleshing out and discussion.

As far as I'm aware, there are 2 situations where our root keypair will be changed (and therefore, will propagate to a change in the node ID):

1. Keypair reset: a "clean break" from the previous root keypair. The previous keypair is no longer valid at all.
2. Keypair renew: a "progression" from the previous root keypair. The previous keypair/s is valid until the root certificate expires(?).

Therefore, on keypair reset, the previous node ID is immediately considered to no longer be valid. Conversely, on keypair renewal, the previous node ID will be considered valid until (I believe) the certificate referring to that node ID expires (but, we should favour the newer node ID over the older one where possible).

We'll need to figure out how to communicate the fact that the node ID has been changed.

We should look into the current process we use for verification of certificate on connection establishment. This seems like the most opportune moment to communicate this to some other connecting node. However, I imagine this would not work for some node attempting to connect to a now invalid node ID. For a clean keypair reset, we'd need to figure out a mechanism to eventually "garbage collect" these revoked node IDs from the NodeGraphs on each keynode.

[joshuakarp]

Note however, this issue only produces a minor optimisation, and potentially not something we should be prioritising time for right now. We'd consider a keypair reset/renewal to be a rare operation, so it wouldn't be a serious issue of a handful of "old" node IDs being present in a NodeGraph. However, a malicious agent could potentially use this. We haven't looked into DHT poisoning yet with respect to our Kademlia system, so this is still something that will need to be considered down the track.

[joshuakarp]

For this reason, I don't think this should be an essential part of our nodes refactoring process.

[CMCDragonkai]

Need to deal with the case when the NodeId changes, and how does other nodes end up "revoking" or "forgetting" the old NodeId.

[CMCDragonkai]

Atm, this is just done through the natural invalidation process of the node graph. There's no specific garbage collection policy. I believe we need further simulation before we can see if this requires a specific removal policy implementation, and we will likely need a single consistent queue to centralise the execution. #329.