Prioritize peers to resist eclipsing

[xloem]

An eclipse attack is when the client is provided with a mess of peers all of which misbehave, offering it a "virtual world" which is false. This can also happen by accident, in the case of a network split for example.

Resistance to this can be much stronger than simply keeping the longest-connected peers. Research into academically-reviewed solutions to these issues is the right way to go. I have not done this.

I at least, however, recommended prioritizing peers by behavior. Following priority list is in need of review:

1. The best peers are those which have provided us other peers that are behaving well. These peers are crucial to keep us in a working network. Ideally these peers also provide items 2 and 3.
2. Second-best peers are those which have provided us with valid blocks which contain all the transactions we have produced and broadcast since the block preceding and have the highest generating balance. This could be a % evenly distributed over the different keys signing the transactions, to resist identity censorship. Ideally these peers also provide item 3.
3. Third-best peers are those which provide blocks containing transactions for which we are the recipient, with similar concerns as item 2.
4. In the event of no transactions related to us in blocks on the network, peer is considered unsynchronized, and user is advised to visit faucet to verify they are on the network.

It would additionally be helpful to support proxy connections so other channels can be used in these events (web proxy, tor, i2p, sneakernet)

[xloem]

From chat: Qora/src/utils/PeersForSortComparator.java The formula by which selecting the best peers can be modified