In HD wallets we get an issue where not-yet-generated keys are needed in
the merkle-block request and we notice this as a chunk of blocks is
being downloaded.
This is solved with some extra code.
Also avoid re-uploading the bloom filter during initial sync.
We connect to the "first" priority stated segments first, in order to
allow the UX to be made much better since it may take a bit of time to
find peers.
The uint256 and CKeyID classes are the same baseclass with template
differences only, which makes them fragile to use for overloading.
As such rename the convenience overload slightly.
this adds a listener interface and a way to emit the callbacks on
changing of the filter.
This also adds a mutex since we expect the Peer to use the filter which
will likely live in its own thread.
This makes the class thread safe and re-entrant.
Notice that we use a recursive mutex to allow various usecase on
altering the bloom filter.
The most involved one is a complete replacement which calls clear and
then various calls to add() style methods.
Second is a single 'add' which can be done without the clear first.
The second needs an explicit lock in the add() methods, which would
deadlock in the first usecase if I didn't pick the recursive mutex.
Instead of forwarding one transaction at a time as the peer sends them
to us, bundle them in a group of transactions known to be merkle-checked
and all belonging together in one block.
Since the peer has no obligation (and with CTOR even less) to send the
transactions in natural order, we should get them per block so we know
all transactions forwarded have parents.
We reuse the NetworkManager lower level code in order to connect
to the Bitcoin P2P network.
This implements the basics for anyone wanting to be a player on
this network.
tomFlowee
TomZ