Discovery + ENR usability

[kdeme]

There has been some (sometimes blind) discussion on the usability issue of ENRs so I decided to write down to make it clear what is possible and what not.

First, to remove any confusion, in discovery v5:

1. An ENR is signed by the owner of that ENR (holder of the private key of the public key / NodeId that is listed in that ENR)
2. You don't need the full signed ENR of a node to send a message to that node.
3. You DO need the NodeId and public key (or just public key obviously) of the node you want to send the message to. NodeId for the packet-tag, but also the public key for the handshake.
4. You DO need the properly signed ENR of a node to make that node available for other peers (meaning, forwarding it on a findnode request).

Based on the above, what is not possible:

• provide some easy to type/remember address format such as a multiaddr format with only /ip4/127.0.0.1/udp/1234 to bootstrap from. This is not possible as you need the public key also.

What is possible:

1. Use another format that has the public key info, e.g. Enode, or a multiaddr with extra public key field. No proper ENR can be build from this though.
2. Use a multiaddr with all ENR fields (incl. signature) so the ENR can be fully rebuild.
3. Just use ENR.

Now, 1. Would require some modifications to discovery. Either we flag the bootstrap node as 'local only' so that we do not forward the half baked ENR that gets created from it (and probably create some new UnsignedENR type). Or we make some changes (e.g. UnsignedNode type) which allow us to ping or findNode this bootstrap node so that we can get the properly signed ENR from the bootstrap node first, before continuing with the discovery process. (ping might provide the ENR in the handshake but this depends on the starting seqNum of the ENR. findnode[0] should always provide the ENR).
2. Would be modifications that can actually live outside of discovery.

In my opinion, the problem we are solving with the above options is at most that of readability. As the pure usability problem of quickly connecting to some bootstrap from cli can not be solved with the above options. You still have the copy/paste over the ENR string as you used to do for the Enode string in the scenario of some quick connection testing, nothing really changes there in my opinion.
As 1. causes half baked ENRs which require you to re-request them or build in some hacks, I'd be inclined to say that it is perhaps not really worth it and better to use ENRs and get some tooling for them. 2. might be better, but you'll get some long and ugly multiaddrs, so I'm not sure it is an improvement.

Another item that might improve the usability is to get eip-1459 (DNS-based node lists) implemented.