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.
The backend has the historical prices in its database, we ask for it by
timestamp the by default it returns the nearest value. Typically within
24 hours.
But if the database doesn't have the data, or its very inaccurate, this
may casue confusion.
So we now have a new API call that returns zero instead of an inaccurate
historical price. Allowing us to prefer not showing anything over plain
false data.
We now skip building (and sending) of the bloom filter until we have
finished the initial blockheader sync. (only relevant for newly created
wallets).
Additionally we update the WalletInfo with our inital blockheight as
soon as we know about it.
The downside of having the application singleton be the owner of the
wallets is that the destructor won't get called until after main() has
been completed.
And that means that globals deletion order becomes an issue, which is
messy and should be avoided.
This change splits out the saving and deletion of wallets & p2p layer,
making use of the Qt application object signal to delete wallets just
before the QtGuiApplication object destructs. Which is _inside_ of
main().
This merges the paymentAmount and effectiveBchAmount methods because they
did 99% the same.
Same with the paymentAmountFiat and effectiveFiatAmount.
This removes the 'effective*' set of properties.
Add a property 'fees' to the TransactionInfo class and use it.
This also changes the GUI behavior of the 'sent' field a little.
In the GUI we now show the amount actually meant to arrive on the other
address(es) instead of the amount our wallet became more empty.
This makes a lot of sense if you look at your transaction and compare to
an invoice, now the 'sent' field will match that invoice and it will
match what the receiver actually received.
to reset the payment removes all user set properties, giving you a clean
payment object.
Since the exchange rate is both not user-set and also not something that
is expected to change between one payment and the next, it is now no
longer cleared on reset().
For the payment object it now is possible to insta-commit to changes and
as such always prepare a transaction ready to be sent with the latest of
the settings.
This is enabled with a boolean property 'autoPrepare' (default off).
The Payment::paymentAmount() method is for the usecase where the GUI
doesn't care about the input/output details.
Its unused in the desktop GUI.
This method now takes into account the concept of 'max', returning the
full wallet amount if its set.
Provide a QML point where a different locale can be given for a different
currency. This then swaps out the historical file to the new one and
fetches from the online stream in that currency.
Instead of recalculating every single block, we now use the existing
locking of UTXOs feature to lock coinbase outputs to a certain
maturation height.
This is the traditional trade-off where we store some more data to
avoid work in the common codepath.
We now show the estimated tip until the headers chain has been synched.
This follows p2pnet listener interfaces changes.
This uses the nicer interfaces setup to make available for FloweePay
the signal that we have reached the tip of the headerChain
tomFlowee