In monero, nodes broadcast addrs from their whitelist. Receiving nodes
save the information on their greylist.
This is to ensure that honest nodes only broadcast active (i.e. whitelist)
nodes to the network. Dishonest nodes can send garbage info through
the hostlist, and therefore all information received from other nodes
is considered hostile and placed in the greylist, until we independently
verify it is accessible via the refinery.
Previously, darkfi deviated from this design as follows:
* Since peers on the greylist that do not match our transports never
enter the refinery, we assume that the greylist consists of
unsupported transports.
* We broadcast the greylist in ProtocolAddr, in an attempt to
ensure that all transports are propagated.
Rather than simply assuming the greylist contains unsupported
transports, it is better to assume the greylist is hostile (since it
comes from other nodes).
We create a `darklist` specifically for storing unknown/ unsupported
transports. When we receive information from other peer, unsupported
addrs are added to our `darklist`, which is then broadcast to other
peers in ProtocolAddr. This fulfils to requirement (of broadcasting all
transports) without also involving honest peers in the propagating of
hostile info.
Specifically:
* Hostile peers can still broadcast garbage info in their gold, white
and dark lists.
* Since info from other nodes is potentially hostile, honest peers save
this info on their greylist and do not broadcast it to other peers
unless a) it passes the refinery b) we connect to in outbound session
c) we do not support this transport.
* There is a potential attack in which an attacker could fill their
darklist with garbage e.g. Nym addresses, and honest nodes that do not
support Nym will continue sharing these addresses via the dark list.
The hostile peers will continue to be shared until a Nym-supporting
node receives them and they pass via the refinery.
* Note that this attack is less severe, since providing the nodes stay
on the Dark list they are ignored by the refinery and outbound connect
loop and do not eat up resources of the node. The only time it will
potentially cause pressure on a node if is the e.g. Nym node receives
a list of hostile fake Nym addresses and they enter its greylist,
causing it to refine many garbage addresses and potentially slowing
its ability to make outbound connections. The latter can be prevented
by increasing the settings `anchor_connect_count` and
`white_connection_percent` (meaning outbound connections will not
select from the greylist, or select less).
* Since there exists a potential attack vector of garbage entries in the
Dark list, we limit the Dark list size to 1000 peers.
* This also means that supporting all transports is the best setup for a
since it increases the security of the network (wrt the dark list).
Previously we had decided on forcing whitelist entries through the
refinery on each new run, by writing them to the greylist on stop.
However, this is a bad design for the following reasons:
1. It deletes the work performed by the refinery, which is valuable and
should be preserved. The whitelist is expensive (i.e. 15s/ peer + bandwidth),
whereas the greylist is cheap (costs nothing to create). Therefore it's
important to retain the distinction even on stop().
2. It means that when we start a node, since we have no memory of white
hosts, the node will always try to connect to peers from the greylist.
Probably safe peers (white) are mixed with potentially hostile peers (grey),
so the node will struggle to form connections and DAG sync will fail.
3. Whitelist peers will be downgraded to Greylist if we cannot connect to
them in Outbound Session, so forcing them through the refinery is redundant.
