Change lite server after sending a transaction for improved privacy #114

Done in a8fc12e0e2 by duke.

From the above commit log:

Assume Alice is using SDL for 1 hour and makes many transactions, perhaps using HushChat with Bob. The lite server she is connected to will know know that IP address A has created transaction id B, i.e. linkability of IP addresses to all the transaction ids that are created while she is connected. If Bob is connected to the same lite server for some or all of those transactions, the complete transaction graph is known : IP address A created txid B sending to IP address C which is the receiver of txid B. This is not good.

One improvement could be that we change lite servers on an interval, such as every 5 minutes. That would be better than nothing, but what seems to be even better is to change the lite server after every tx. This means that every time Alice (or Bob) makes a new transaction, they are potentially talking to a different lite server. It is potentially because it is possible that our randomly chosen new lite server is the same as our previous lite server. We could try to ensure that the new random server is different than our previous, but in edge case of only one server being up, the code gets annoying.

This commit implements changing to a likely different lite server after every transaction. In the worst case scenario, it reduces to the privacy of the old behavior, which is to leak all data to the current lite server. In the best case, we spread out metadata leakage to every lite server that is currently up. The average case is to spread out our metadata to more than just one lite server, which is a privacy win.

If stickyServer=1, this code is disabled, since it's better for somebody to connect to their own lite server and not leak any metadata to 3rd parties.

This algorithm should also be implemented in SDA.

As an aside, Zcash has ignored this problem for 2.5 years and only supports talking to a single lite wallet at a time (no random selection on startup) which provides further evidence that ZEC mainnet is a honeypot.

Done in https://git.hush.is/hush/SilentDragonLite/commit/a8fc12e0e2b2324db21407f4848f2d4aa59f4575 by duke. From the above commit log: ``` Assume Alice is using SDL for 1 hour and makes many transactions, perhaps using HushChat with Bob. The lite server she is connected to will know know that IP address A has created transaction id B, i.e. linkability of IP addresses to all the transaction ids that are created while she is connected. If Bob is connected to the same lite server for some or all of those transactions, the complete transaction graph is known : IP address A created txid B sending to IP address C which is the receiver of txid B. This is not good. One improvement could be that we change lite servers on an interval, such as every 5 minutes. That would be better than nothing, but what seems to be even better is to change the lite server after every tx. This means that every time Alice (or Bob) makes a new transaction, they are potentially talking to a different lite server. It is potentially because it is possible that our randomly chosen new lite server is the same as our previous lite server. We could try to ensure that the new random server is different than our previous, but in edge case of only one server being up, the code gets annoying. This commit implements changing to a likely different lite server after every transaction. In the worst case scenario, it reduces to the privacy of the old behavior, which is to leak all data to the current lite server. In the best case, we spread out metadata leakage to every lite server that is currently up. The average case is to spread out our metadata to more than just one lite server, which is a privacy win. If stickyServer=1, this code is disabled, since it's better for somebody to connect to their own lite server and not leak any metadata to 3rd parties. This algorithm should also be implemented in SDA. As an aside, Zcash has ignored this problem for 2.5 years and only supports talking to a single lite wallet at a time (no random selection on startup) which provides further evidence that ZEC mainnet is a honeypot. ```

Adding it to the release notes and closing.