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 :-)
We rename the enum and add some asserts indicating the new purpose.
This also makes the code more robust with a try/catch and fixes a
possible crash when a transaction doesn't have either a date or a
blockheight.
This changes two implementations of the BroadcastTxData baseclass
to now use one which is a lot more robust and thread-safe as
well as fixing various smaller issues.
This helps the user understand better what happened if the transaction
isn't known (yet) by the network, since the blockchair service gives a
weird (buggy) page in that case.
The final release should not include the example module as we aim
releases at normal people, not devs.
This makes the skipping of the example module part of the build
setup by simply passing in -Dskip_example=TRUE
to cmake.
The initial wallet is already made auto-archived after a couple of weeks
not receiving any funds. Avoiding it allocating peers.
This makes sure we also do not show it in the mobile UI in the wallets
screen.
This stores the time of a transaction in the store of the wallet, and
indeed sets it when it is added to the wallet first time.
For instance when we create it or when the tx is first sent to us at
initial broadcast.
We add some logic to the model in order to put a bit more effort into
finding times of a transaction that did not get mined and (before this
code) did not get its time of creation set. Mostly this is about
rejected transactions. And there we guestimate the time instead.
A wallet might get stuck in silly situations like starting up when
there is no block for a long time and then not actually being online
at the moment a new block gets mined.
This fix makes sure that at startup we 'unstuck' such a wallet without
there being a need for a new block to be mined while the app is running.
tomFlowee