To _really_ simulate the network, mocknet needs
to provide proper addrs and keys. Otherwise
services that depend on some of the network's
functionality (like exchanging keys) will fail oddly.
cc @maybebtc
Send + Recv compressed multiaddrs (bytes). this makes
for much smaller addresses, as string addresses are
inflated for human readability. compare:
```
consider: "/ip4/192.168.10.10/tcp/13456"
string: 0x2f6970342f3139322e3136382e31302e31302f7463702f3133343536
packed: 0x04c0a80a0a063490
```
Online record verification -- meaning record verification
that might cause messages to other peers -- presents a
way to perform an attack on a dht node: forge a record and
make the node attempt to fetch the public key to verify.
This becomes a very powerful amplification attack if
online verification is done for records _received passively_.
This means records that were received as the result of a
PUT_VALUE or ADD_PROVIDER. Thus we only accept records we
can verify offline (whose public keys we already have). In
practice this is not at all a problem for us, because
typical connections are encrypted: we've already exchanged
public keys.
Providers are records that need Addresses. The routing
system needs to provide -- not only the ID, but also --
the peer's Addresses. A peer.PeerInfo is a small struct
to pass around a peer.ID and []ma.Multiaddr.
RandPeerID generates random "valid" peer IDs. it does not
NEED to generate keys because it is as if we lost the key
right away. fine to read some randomness and hash it. to
generate proper keys and an ID, use:
sk, pk, _ := testutil.RandKeyPair()
id, _ := peer.IDFromPublicKey(pk)
Also added RandPeerIDFatal helper
PeerInfo is a small struct used to pass around a peer with
a set of addresses and keys. This is not meant to be a
complete view of the system, but rather to model updates to
the peerstore. It is used by things like the routing system.
