When we receive a known message (currently just avahello) we now
intantly ban and disconnect the peer, no need to
test compliance when they openly greet us saying they are not following
the same chain.
Tuesdays idea of adding some code into the SyncSPVAction didn't feel
right.
A second look made clear that bloom filter updates make much more sense
to go hand in hand with sending a mempool message. Especially since they
depend on each other on the server side.
To-rehash:
the wallet may decide at any time that a new bloom filter is needed. It
then uses the superclass (code in p2plib) PrivacySegment, to build that
filter. As part of that we get a lock object which, when going out of
scope, makes the peers that are subscribed to the privacySegment send
out the filter.
This separation of concerns means that the subclass wallet in the app
doens't know about peers or messages, only its superclass PrivacySegment
does.
What we did in this change is make the PrivacySegment class decide to
combine a bloom update with a mempool call. Typicall only once per
connection.
This means I can remove hacks in the SyncSPVAction which forced the
sending of the mempool message separately.
The job description of this component is to sync a wallet. Its means to
that end is to connect to peers.
Problem is that when we startup and the whole system is already in-sync,
then we forget to connect to peers. (that wasn't in the job description,
it just happened to be done as a sideeffect).
This changes the SyncSPVAction's job description to also make sure that
each wallet has the required number of peers.
We send a 'mempool' p2p command to a peer after we did a series of
merkleblock downloads.
This code adds the mempool p2p command to be sent to peers that didn't
participate in the merkleblock download and thus get the best out of all
our connected peers.
Now we have 3 more logically divided interfaces for the listener
pattern (callbacks).
A P2PNetInterface for peers maintainance.
A DataListenerInterface for the sections getting new data.
And last the new HeaderSyncInterface about the state of the
header-chain (application wide).
Makes the change from yesterday complete: we now
compress all the chunks into one periodically.
This, again, is done with a timeout instead of on-close.
We have 45 seconds as a timeout to balance between need to save and
waiting long enough to get additional headers should it
have been a while since last run.
This change makes it so that we rely less on the downloaded
blockheader data being only in memory and us saving it when
the client shuts down.
Instead, we save more regularly and we save smaller files
instead of always overwriting the complete downloaded headers.
Having less to save at shutdown is then a happy side-effect.
Version.h held mostly stuff for protocol.h, which is a hub-specific file.
The only thing that we actually use is the PROTOCOL_VERSION in our code
and as such that one moved to the interfaces dir.
What we did previously is load a static chain which was to avoid lots of
work by simply memory-mapping the data instead of inserting it in a
vector.
This improves upon that by also having a metadata file which holds the
block-hashes directly readable. This avoids us having to iterate over
the blockheaders and hashing them.
Additionally we now have a single chain-work field that is the total
amount added work for the headers. This saves us from doing 256-bit
divisions and work for each blockheader as well.
Result is that we make the statup mostly about memory moving and remove
all CPU intensive stuff. Going from 1450ms to 400ms on desktop.
I expect an even greater gain on mobile CPUs.
A peer that is behind is marked as "on a different chain", which is
ultimately correct, but the response to punish or ban them is too much.
We could very well reconnect later when the situation is resolved.
So, detect when a peer is simply behind and respond by disconnecting
without punishment.
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.
tomFlowee
Your Name