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.
* Save created recurring info
* Add to confirm dialog
* Update RPI at confirm
* Make singleton
* Add history to recurring payments
* USD/ZEC switch
* Fix check state
* recurring item serialization
* Add recurring payments to file
* Refactor
* Address view model
* Wire up dialog
* Update windows installer logos
* Store all payments in the store
* Save table geometry
* Add recurring payments view
* Add deletion
* Add recurring payment execution
* Add donation address to address book
* Add multiple payment handling
* Disable recurring for multiple payments
* Handle pay last
* Handle pay all
* Reomve frequency
* Enable recurring payments only for testnet
* For testing, allow payments in 5 min intervals
* Fix request money amounts