As we moved most of the creation of a BufferPool to be via the
Streaming::pool() method, which uses a thread-local, it makes sense
to start cleaning up the design and make it more modern C++.
The above mentioned method would return a reference and you'd see
loads of places use `auto &pool =` which is less than ideal.
As the number of places where we actually instantiate a BufferPool
goes down, the usage of some sort of smart pointer makes more sense.
This now makes all APIs use BufferPool be wrapped in a shared_ptr.
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.
This uses old methods from the ugly utilstrencodings files
and cleans them up to allow us to install this header file and
use these methods outside of theHub repo.
There factually is no difference between char and unsigned char
except in very rare cases (like bitshifting). But in APIs they
are incompatible, which is a pain...
tomFlowee
Calin Culianu