* use metropolis-hastings random walk with random backtracking (variant of MRWB)
to sample the peer graph in as unbiased a way as we can. The only major
difference between this and MRWB is that we don't maintain a peer stack;
we just select a random peer instead of backtracking.
* keep the peer table and the peer database in sync--the table is the
cache-coherent copy.
* keep only 65536 peers. Hash the peer address and a nonce to select a
slot, and ping an old peer before evicting it on collision (and keep the
old peer on collision if it responds)
* a peer can ask for all other peers.
* remove up to 10 peers that are unhealthy per walk; add up to 10 new
peers that we discover on remote peer queries.
* use socket-determined peer address, not RPC-given peer address
* various code cleanups.
* push zonefiles if we receive them, and know of another peer that needs
them (i.e. should happen frequently near the chain tip)
* when getting the peer list, queue the requester for pinging
* move unit tests to integration test framework
* Atlas nodes are a lot like BitTorrent nodes, where the blockchain
gets used to encode the sequence of zonefiles (chunks) a peer goes and
fetches.
* Atlas nodes discover each other from a set of seed nodes, and try
to construct a K-regular network graph using a random walk through
the peers neighbor relations.
* Atlas nodes propagate peer information to each other in a "K-rarest
known peers that are alive" fashion, to encourage even peer mixing.
* Atlas nodes maintain a bitwise big-endian "zonefile inventory vector"
where bit i is set if the ith NAME_UPDATE's associated zonefile has
been obtained.
* Atlas nodes exchange zonefile inventory vectors amongst their
neighbors in an effort to find missing zonefiles. They obtain zonefiles
in a rarest-first fashion--i.e. the first missing zonefile to fetch
should be the one known by the least amount of neighbors.
* Atlas nodes occasionally refresh inventory vectors with neighbors to
ensure that knowledge of a zonefile propagates through the network.
This is mostly untested code, save for what the unit tests at the end of
the file cover. TODO: integrate with CircleCI
sig, then set it to "", not None. This hadn't been a problem before,
because all keys were p2pkh and always had public keys. With multisig
support, this will no longer be the case.
when generating the new config file (#229). However, don't add it if it
was already present in the config file, or if the config file already
exists (in which case, the appropriate action is to use the version
given, or back up the old config file).
from the data private key over the hash of the previous profile (or "") and new profile's
canonical serialization. This is meant to prevent malicious replay
attacks using stale profiles.
