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.
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
This exports the payment-request address to the QML side.
We use this to show under the QR the address we are requesting to send
to.
This is quite useful for users wanting to manually check if things are
going well.
On the main screen, also known as the "Activity view" this allows the
user to choose to only see fiat or see both Bitcoin Cash and fiat values
listed next to each transaction.
This makes the payment detail (output) have the same property name as the
payment itself which was supposed to just be a proxy for a single-output
payment.
Consistency is good.
tomFlowee