We can't delete them completely, at least for a while, because we can't
know if the user has used the QR payment code we presented at the first
app startup.
We store a blockheight at which point a private key is created, allowing
us to skip merkle checks before that time.
This was was tricky for a not yet synched wallet because its blockchain
was stuck at height zero.
Causing us to sync everything anyway.
Now we store the timestamp of wallet create instead, until the time that
the blockchain is synched. After that we resolve the block that we need
to start sync from based on that timestamp.
This solves the issue where we expect too many blocks when a client is
restarted while being at the tip and there is more than 300 seconds
passed since the last block.
This now doesn't show we are waiting for blocks until an actual block is
mined by having a 25min variance allowance.
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.
* split the AccountInfo and Payment classes out into their own files.
* Start a 'color' file to switch between light and dark-theme.
* Start a new main GUI which isn't so hacky and ugly.
* Make this actually a desktop app, with menu and file->quit!
This is clearly beta-level quality, it won't lose your money, but
kittens can be killed if you use this in production! Don't do that!
This payment client uses the proper P2P client and does not require
any additional indexing services and therefor is very much geared
towards the most private it can be with SPV, while staying scalable and
nible.
The only GUI available right now is for the desktop, it should be pretty
simple to re-do a nice GUI for some mobile or similar form-factors.
That is one area that QML simply rocks in.
tomFlowee
TomZ