These traits introduce a problem, in that constraints on a method cannot
be conditionally required based upon the presence or absence of a
feature flag. Instead, we make the methods previously introduced by
the removed traits present in all cases on the `WalletRead` and
`WalletWrite` traits, but ensure that their implementations return
an error if the caller attempts to use them in a wallet that has not
been configured with support for transparent inputs functionality.
Due to how the wallets retrieved unspent transparent outputs from the
light wallet server, the account associated with a particular UTXO may
not be known by the light wallet. Instead of requiring the caller to
perform a separate lookup and match the address of the received UTXO
with a known account, it's simpler to perform this lookup internally at
the time of insertion or update.
In order to make this operation more efficient, the `addresses_table`
migration is modified to add a column to cache the transparent receiver
so that it may be used in the joins in the UTXO insert and update
operations.
Since our migrations form a DAG, it doesn't make sense to only allow a
single migration to be specified for wallet initialization; instead,
allow multiple migrations so that one can hit all the desired leaves.
This adds sent and received note count information, transaction fees,
account information, and makes the information returned about sent
notes and received notes consistent with one another.
The currently deprecated implementations of `insert_sent_utxo`,
`insert_sent_note`, `put_sent_utxo` and `put_sent_note` all store to the
same `sent_notes` table internally. Since there's no immediate plan to
change this arrangement, it's better to have a single pair of internal
`insert_sent_output` and `put_sent_output` methods instead.
The previous approach to UTXO handling involved UTXO data being
deleted from the wallet after the relevant UTXOs had been spent.
However, this means that we can no longer accurately compute
transaction fees for the transactions spending those UTXOs.
The `net_value` of the resulting rows in v_transactions will be
null.
The implementation of `io:Read` for `ResponseLazyReader` used to return
only one byte regardless of the size of the provided `buf`, which
significantly degraded the performance of loading the response.
This change makes use of the provided `buf`. On my machine with Rust
1.64, the downloading speed went up from ~100 KiB/s to ~2 MiB/s.
However, as before this change, the process still uses 100% of a single
CPU thread when downloading the response. The most likely reason is that
we still manually read each byte of the response. I can download the
same data with ~ 50 MiB/s on my machine using a different HTTP client.
This fix seems to be sufficient for now.
dependabot[bot]
Kris Nuttycombe
str4d
Kris Nuttycombe
Daira Hopwood
Marek