This is purely a future-proofing measure, don't accept transactions that
are likely to be handled differently than todays transactions.
Since the May 2023 upgrade versions other than 1 or two are not allowed
on-chain, but before that some version 4 transactions were mined (and some
negative numbered ones longer ago).
Talks about a version 10 transaction has started, so make sure this software,
if it is still running at someone's machine, will already reject higher
version transactions because we can't know if they are compatible or not.
Last year I increased the bloom filters to make sure that bcom wallets
could be imported with their weird behavior.
The side-effect has been that wallets imported that have 3K addresses
and up start to have massive amounts of false-positives on their bloom
filter during import.
So while the hacks done before were for wallet vendors intentionally
keeping their list of private keys small (100 or so), we know we can
thus turn off said weird workarounds when the wallet is in actual fact
much larger. And thus save bandwidth.
This now uses a shared-pointer and moves the creation to the point where
we know the new data is actually a transaction for us, avoiding work
when the bloom filter caught a transaction not actually for us.
Now we view the creation of more private keys, and how many, as a
separate concept as the bloom-filter 'gap' counts.
This cleans up the concepts of bloom filters, we now use the
design as documented on;
https://codeberg.org/Flowee/pay/wiki/dev/bloom
This removes the 'debug' logging (again) in non-debug builds,
but it also adds a new 'debugFile' argument where the user can
point to the logs.conf (as used by all flowee server components)
which allows setting of log levels per section, and more.
The isSingleAccount property controls if the UI is simple or more
complex.
The single account setup doesn't show you that you have any concept on
differnt accounts at all. No account chooser etc.
On Desktop, however, we choose to always show the archived wallets
anyway. Even though its not in-your-face. Which makes the behavior
between those UIs slightly different.
The addition of the limitedArchiveView property is meant to
facilitate that.
The page-up/page-down now actually scroll a significant chunk of a
page and not an annoyingly small distance.
As we scroll, we make it a point to show the ScrollBar-thumb in order
to give the user feedback on where in the list they are.
We simply use the font size, which is our basic scaling system anyway.
This avoids sizing issues for really large fonts when items start taking
multiple lines.
General cleanup.
Qt5 had the need to add versions to imports, this has (for
very good reasons) been removed from Qt6.
This removed the versions from the import lines.
The main font on Android seems to not ship with 'semi-bold' on
various devices. Which means that the title just was the same
as the content and while I like subtlety, in this case if failed.
Better to go with bold than with no difference at all...
Additionally small spacing / sizing fixes.
We now fix archive being there when it makes sense, and
also fix the focus being lost after toggling the archivi-ness of a
wallet. Which means that hitting 'Ctrl-Q' will correctly close the app
after.
When a wallet is updating we may get a lot of new transactions added in
a short amount of time, this avoids calling updateMap for each one in
turn and instead triggers an update only if there isn't one in-flight.
This takes advantage of the fact that the wallet does its update in a
different thread than the UI-one.
The newer Android versions overlay a "Flowee Pay pasted from your
clipboard" text.
The location is dependent on model, but generally it is located at the
bottom.
So avoid the chance when the paste button is under that helpful OS text.
As we still support older versions of Qt, this moves to load
the MultiEffect (blurring specifically) dynamically and avoids
the entire project failing if the effects module is not found.
The effects module was introduced in Qt6.5
When an input used in a transaction comes from a cash-fusion
transaction, we now put the CF logo next to it in order to
make this fact clear to the user and allow them to understand
how tracable this specific payment was.
tomFlowee