clipboards based addresses are a lot less secure, physically, than
scanning a QR.
So the user really should validate the payment and thus we turn off
instaPay in those cases.
A Payment object now has a user-typed address,
a formattedAddress which is a properly formatted cash-address
and last a 'niceAddress' which is the same cash-address but without the
chain prefix.
This cleans up the usage and removes some code from the GUI that did the
string manipulation there.
A payment request, for instance a QR code, which includes an amount to
be paid is expected to not change the to-be-paid amount, uses being
dropped
in the price editing UI is therefore a bit weird. Almost an
anti-pattern.
This honors that concept and when the price is included in the scanned
QR, we change the UI layout to removed the editing widgets and show
static display widgets instead.
This also adds a header menu item to edit the amount to be paid and
get back to the old UI.
Additionally, a new UI is added to show the address we are about to pay
to, likewise reachable from the header menu.
The basic usecases of instapay is that the payment request is filled in
one go (from QR for instance) and thus we try to send.
If that fails (not enough funds or whatever), we disable instapay in
order to avoid 'magic happens' user experiences.
The headers and such items now get localized on the history pages.
We use static strings for the formats to avoid every call converting a c
string to a utf16 qstring, which takes an allocate and a conversion.
A tiny little amount of data kept in global memory to avoid a large
number of mallocs is a net gain, I'm pretty sure.
The design of HD wallets always has a gap, a number of addresses past
the last used one we optimistically also look at.
My code assumed that there would be only one gap, at the end while the
number of skipped addresses were near zero.
Some other wallet, however, had multiple large gaps which messed up the
algorithm.
Now we restart counting gap-addresses every time an address is used in
the sequence.
Fixes#12
This should fix the problem of a certain established wallet not
importing properly.
That wallet has shown to jump 15 or 20 addresses over the gap, which
made me wonder if that actually is a privacy issue and the conclusion is
that, no, if there is no matching transaction on chain, there is no
privacy leakage from just sending the bloom filter and thus the gap has
been increased for main.
Lets face it, listing loads of addresses is not readable. People can't
really get meaning out of that, its just 'data' after one or two.
Showing the hd-path-id (main or change) and an integer is going to be
much more useful for many UX situations, so we provide that information
for the UI to display that instead.
Naturally, the actual address is still available for copy/pasting etc.
This solves the UX issue that the touch-screen keyboard would
overlap on our main content and that we could actally not input
a price properly on mobile at all.
We ship our own font to not have to depend on the host system's
installed fonts for 'special' characters like arrows and stars.
This is a font forked from the Gnu-free font people, only since that one
is 2MB this is a very much stripped down version with just all the fun
stuff left.
A wallet can permanently be labeled a 'private wallet' which is a simple
boolean.
Then when you may need to hand over your phone to a clerk, all you do is
quickly enable the 'private mode' which is sufficiently deep in the menu
to make it hidden.
The effect is that all wallets marked private will be hidden for the
duration of that feature being on.
This fixes some cornercases and makes the test
a) properly data-driven (don't use 'today').
b) much more extensive.
This also removes some duplicate code and fixes some bugs in the actual
model it tests.
We now handle correctly user input that we can expect when they manually
enter the mnemonic via an on-screen keyboard.
This includes spacing, line feeds and uppercasing of the first word.
tomFlowee