This is done in several steps:
1. Separate my height from the remote peer heights.
Instead of assuming we have one height, recognize that a peer may
not be at the tip at the same time we are. We monitor headers/invs
to update the 'peerHeight' variable.
2. Ask for merkle blocks from a peer to the maximum height of that
peer (but not later than what we validated to be true).
This avoids us asking past the remotes tip which they didn't like.
3. Redo the SyncSPVAction to use all this and make it much more
reliable in finding peers to download from and getting all the
changes as fast as possible.
We already had in place the blockSizeAcceptLimit as the limit
on messages, which is now the only limit.
In practice this means when the operator sets the maximum mining
size that we adjust the blockSizeAcceptLimit, if they only set the
blockSizeAcceptLimit, we use that (plus a margin) to limit messages
both on the p2p layer and on the RPC (JSON) layer we change the
limit to be twice the blockSizeAcceptLimit (copied those numbers
from BCHN).
In most cases headers would be automatically downloaded if we didn't
connect to that peer for a while, but that is not a guarentee so lets
make sure we actually start downloading headers from any peer we can :)
This is a feature request following the fact that some sysops use a
symlink for the unspent dir and don't want the reindex to delete the
symlink itself.
This implements the sendTransaction command using the async framework,
allowing clients to benefit from multi-core systems to process
transactions in parallel when being submitted to the Hub.
This fixes the logic that finds out it should resume an interrupted
process. The code had false positives in case of a message split over
multiple TCP frames.
TomZ