In case the configure step found the QtMultimedia libs, we also
include the camera / QR-scanner functionality in the desktop
app since users may use a laptop which contains a camera.
This completely re-designed the 'import wallet' screens on
mobile.
We use the various new features available now, most importantly the
ability to detect derivation and start-height from an electrum
indexing server.
We now get an actual endpoint from the IndexerServices which is handed
to the ImportHandler for remote services.
This also includes a bunch of bugfixes and basic 'make it work' stuff.
This does not hardcode any indexers, as that would be fragile as
well as painting a bulls-eye on the backs of the server operators
for ddos targets.
Instead this reuses the same concept from Satoshi's Bitcoin. We have
DNS feeds (currently only one) maintained by a crawler.
This finds us a handful of Electrum servers.
We connect to one of those to find more servers, notice that this is
not SSL encrypted because we only have an IP address at that time
while SSL wants a hostname.
This quick connection over plainnet is there just to fetch the
server list known to the server, we can then open an SSL connection
to any of those.
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.
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.
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.
Simplify the loop by using lock() on the std::shared_ptr, which doesn't
throw.
Also follow the API change in the libs and some deeper introspection for
the actual connection status.
* make it much faster for large transactions to open by not drawing and
then hiding the inputs/outputs that are not relevant to us.
* Allow expanding cloaked addresses by clicking on them.
* instead of a right mouse button menu, show a copy icon next to each
address.
* Add the chainprefix to the clipboard on copy.
This now finds if there is a single output address we can honstly point
at and say "this is the beneficiary of this transaction" and we return
this.
This will be in the context of the wallet it is in, naturally.
A peer that has not yet handshaked is now show in this view, giving a
better indication of what is going on on platforms that do not have easy
access to a log file.
This makes sure that we update the last-mined-date also when a
transaction is simply confirmed that was already in the wallet.
This only really shows if you were offline and only later broadcast that
transaction, which was unusual enough for me to never notice before :-)
tomFlowee