This sets up a basic system for creating modules on top of the flowee
pay static lib in a way that is ensured to be isolated (modules can't
accidentally use each other's classes)
The setup is made such that the buildsystem does the hard work on
plugging in a new module, making it so that all you need to do is create
a new dir and a "{something}ModuleInfo.h" file and it will get compiled
in.
The point there is to make it not have any merge conflicts and just make
it dead easy to get started.
In our wallet we very rarely end up in a situation where we have to ask
the same transactions twice from a peer due to us having generated a
bunch of new keys from a HD wallet in the middle of a series we asked
that peer. Making the filter we sent at the start of the series be
outdated halfway through.
This is now handled properly.
This adds a unit test which tests that we now reach the right balance
and can add the same block multiple times without it failing.
Fixes: #12
Slowly the amount of cpp sources has been growing to the point
where its just too much to store in the root of the project.
I think they are more happy in a subdir as well, getting an elevated
position for themselves.
For the 'fullyEncrypted' option we now simply fully
encrypt the entire blob of both the secrets file as well
as the wallet.dat (which transactions we own).
We encrypt using a standard AES256 encryption scheme.
The key is 256 bits and we derive that from a user provided password
which we double-hash (sha256). Additionally we use a randomly generated
salt for a specific wallet that is fed into the hashing algo as well.
This version simply encrypts the private keys of a wallet, which makes
it quite basic. A good start.
When the wallet contains fused transactions we select UTXOs a bit
different in order to maximize privacy.
Additionally this prefers an UTXO that is closest in value to the paid
amount.
To avoid recompiles and such generally to simplify stuff, this
moves all the code into a static lib that is then linked with
by the various apps (including tests).
As transactions are found on the blockchain we remember the signature
type used in order to avoid one private key to be used for both types of
signatures, which can cause compromised keys.
This changes the default generated wallet to be a HD wallet.
We also add a helper class to configure newly created wallets from QML.
This finishes up the new wallet panel to have all the visible features
actually do something.
For each transaction allow to click on it and show lots of further
details about it.
This also fixes various bugs and adds some basic helper methods in
various places.
The QML is barely functional, getting the right data exposed was the
only goal today.
When a transaction is received by the p2pnet layer via a simple INV/
GetData we now process this and properly lock the outputs it spent to
avoid creating double spending transactions.
One task is left: properly recognize when a mined transaction
invalidates another transaction (like an unconfirmed one) and update the
datastructures.
tomFlowee
TomZ