- 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")
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...
Protocol Buffers interaction is just another serialization standard,
while its widespread it has fortunately mostly been kept out of
anything relevant or important. Mostly due to the fact that is
really quite bad from a technical perspective.
This adds simple and basic support for creating and parsing
protocol buffer messages, mostly to allow interoperability.
If you want quality: use the MessagBuilder/MessageParser ones instead.
The unit tests testing base58 encoding were using univalue JSON
parsing, since we deprecatd univalue to be a hub-private lib
this has now been ported to Qts JSON parser.
Which also makes the clunky cmake hack nice to replace with the
QRC files concept.
As I was in there anyway, the base58 methods being global scope
C-style methods has now been fixed by putting them in a namespace.
The leveldb and univalue 3rd party libraries are not installed and
not needed by anyone outside of the Hub.
So move them there, making it easier for 3rd party usage.
This sanity check might avoid issues in future code by not assuming a
log channel (or anything it depends on) will avoid using logging at the
moment it is shutting down.
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.
Since the default copy constructor of the HDMasterKey uses the copy
constructor of CKey, make the latter have a copy constructor explicitly
defined as well.
setting an incorrect value should not keep the old data after we already
update the fValid boolean.
That would give the user the impression that the data was removed while
it really isn't.
This adds support for the
Lexicographical Indexing of Transaction Inputs and Outputs
anonimize concepts of transactions directly in the transaction builder.
tomFlowee
Calin Culianu