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.
This avoids a naming conflict with a p2p class BlockHeader.
Notice that the block data structures are mostly still private API, they
are in the utils dir but headers are not installed, nobody has needed
them so far.
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.
On connect, we should ask for a HEADERS overview from the remote peer,
even if we aren't fully at the tip yet.
Also remove some old lookup no longer used.
Sometimes a node would not be online for a while and we'd incorrectly
ban them for a long time when we just need to mark them as not-
reachable-right-now.
This avoids checkers being worries about the inconsistency of a
specific copy-constructor but a generic assignment operator.
The assignment operator can be generic because locking doesn't
care what the content is.
This introduces a Mnemonic class for BIP39 (seed words)
validation as well as a HDMasterKey class with provides the
BIP32 & BIP43 support.
All tests went into the apputils unit test.
The API-wise nice addition of base58 encoding learning about
private keys has as a downside that external projects get the
surprise of pulling in a lot more code.
Those that want to avoid this, while not using private keys, can
simply add
add_definitions(-DNPRIVKEY) # avoid private-key using code
to their CMake file.
The first bunch of times we want to reconnect much faster so we have less
downtime and faster response.
After a while it goes up to a slower timeout in order to not overload
logs and other such.
tomFlowee