This follows the coding style guideline that the file that contains a
class should follow the exact name of this (main) class.
key.{h|cpp} -> PrivateKey.{h|cpp}
This follows the coding style guideline that the file that contains a
class should follow the exact name of this (main) class.
pubkey.{h|cpp} -> PublicKey.{h|cpp}
pubkey_utils.{h|cpp} -> PublicKeyUtils.{h|cpp}
The system writes a new file every single run (provided new headers were
received) and we sometimes compact them into a big file again.
The code forgot to remove the newly introduced info files of the old
files it compacted. Leaving confusing things happening after.
This solves that by making the first run remove all info files and re-
build them, adding a version byte to allow us freedom to do that in the
future again.
The bchd seed owner says that since there are no bchd nodes on main-chain
due to the code being outdated, the seed is empty.
We hope this will change in the future, but for now it makes no sense to
query it since it will just generate a fail.
This improves several corner cases on detecting if a peer we
are requesting headers from is actually giving them to us.
Specifically, the height could be zero for a genesis-only view, which
caused the detection to always give the higest score (height zero is
seen as special).
After a node is disconnected we now also reset the history in order to
let the new node get measured from only its own performance.
We optimistically create a new info file but as we start we might
instantly realize the file is useless and give up before having written
a single byte.
We now remove that file to avoid stale state.
Also be more verbose on warnings.
- Changed API for HDMasterKey::fromMnemonic to use an enum to specify
BIP39 vs Electrum format phrase
- Added unit test for this class to existing unit tests
These are almost identical to BIP39. They use the same word list except:
- The checksum is calculated differently
- Deriving the master key from them uses a different pbkdf512 salt
("electrum" vs "mnemonic")
The blockchain class can effectively now be shallow,
we can have a list of blockheaders of, for instance, the last year
alone. It builds on top of a known checkpoint (hardcoded block data)
and as long as we do not access block info that is unavailable, things
just work like normal.
We throw at the request of a blockheader that is too old.
Should the peer have been rejected on status or similar, we don't
register a successful connection and avoid the peer from being selected
again since then we don't remove the punishment done on connection
start.
Protobuf seems to have an incompatible cmake every single release,
which makes including it with cmake itself stupid and indeed lead
to linking or even compile errors.
So, the point of not wanting to use protobuffers directly got again
proven in practice as its a messy thing in all regards.
This makes the unit test for our reimplementation of protobuf
parsing/building become optional. The unit test is the only one
that actually uses the protocol buffers stuff itself, as such
turning that off by default isolates our users from the mess it is.
tomFlowee
Calin Culianu