Fixes: #16
* Don't store the initial dummy value '100,-' in the history.
* Don't store the 404 server reply as a price file.
* On switching of currency, instantly try downloading the
historical prices instead of waiting for the next restart.
We introduce a new WalletkeyView which is a class that provides a
thread-safe view on a single private-key in the wallet. Detecting all
transactions depositing money in that key and thus being an ideal
backend for the PaymentRequest.
This mostly removes the less than successful architecture.
This architecture stems from my first attempts at mixing C++ and QML, and
its not great.
As we can see from the removals, it touches a lot of places and
especially the wallet owning them is messy, but in QML we have to do a
lot of null pointer checks, also not exactly readable.
Lets try something different.
When the wallet already noticed a new block but the blockchain database
doesn't have it, we should just bail.
The only way this is likely to happen is because a previous run of the
wallet didn't write out its data. We keep the assert for that case, but
in release builds we are now more robust.
QML tends to call our getters even in unrealistic scenarios, which means
an extra check is useful to avoid hitting an assert, or doing an out-of-
bounds access.
Ah, seems that the signal 'ApplicationActive' is also sent at the app startup,
which this code didn't handle too well.
Now we ignore this signal until we are property started.
Fixes: #14
During import we now always send all change addresses to be monitored
for activity, even if they are empty.
The behavior of not reusing an address after its been emptied is not
universal and as such the import should account for this.
The privacy issue is really not harmed by this during import, as we
basically send all the addresses in a relatively short timespan to the
peer anyway.
Don't do any work when the transactions that are being added are all
already known.
This is common when we send a merkleblock request to some peer after we
already have received the answer before. For instance when we double
check nothing is being omitted by some other peer.
Since recently the wallet can delete stuff, we need the model to
be more robust in accepting data not being there.
The "async" statement refers to the fact that the wallet acts
one messages from the network, which may be in any thread.
The signals from the wallet get handled by the WalletHistoryModel in the
Qt-UI-thread, asynchronous.
If we are lacking transactions this may cause some data inconsistencies
for the UI. Possibly causing a nullptr dereference.
This helps with early detection.
Now the wallet handles inserts-in-place by making removing and then
re-adding of transactions, the 'txIndex' is no longer guarenteed to live
forever.
So we now tell the world, and specifically the history model, about the
removal of txIIndexes.
One notable behavior change is that we increase the 'change' gap
considerably for wallets that are known to have 'cashfusion'
transactions as those use a lot of change addresses.
This chang also increases the normal gap to avoid people losing history
when importing from another wallet.
When we notice we used all HD keys on finding a transaction, we check
it again after creating a bunch of extra keys.
Now we also use the re-created comment which is where fusion transactions
place the amount of outputs matched.
This is a purely visual change.
tomFlowee