Flowee experimented with a 'metablock' a piece of data stored next to
the blocks with some metadata it discovered during validation.
One of those pieces of info is the txid, which turned out to be too big
to store here (16GB or so added).
This change removes the txid but it does keep the script-flags and the
fees for each transaction (8 bytes per tx) which adds maybe 3GB to the
entire chain.
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.
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.
This test tests the new Mining::SubmitBlock feature.
We also test the GetBlock with the new FilterOnScriptType feature.
Some new helper methods in the messageBuilder and FastBlock are also
used and tested.
The test starts to become long to run and using the one main.cpp
hack we had removes our ability to select one test to run, so lets
go back to one executable per class.
People all over the Internet, including on the BCH spec, seem confused
about these enum values. They think they are opcodes.
So lets be clear and rename them to the thing they are. Placeholders or
a return-code.
as the expected behavior of 'get*' is a const method, it is harmful to
name a method such when it actually alters the state of the method such
that subsequent calls will produce a different result.
The CAmount name is not helpful as its just an int64_t and not a
class, like the name implies. There were a handful of places where
it was passed in as const-ref, as a good example of this actually
creating sub-par code.
tomFlowee