Previously, `shield_transparent_funds` was only shielding funds
associated with the legacy default transparent address. This meant
that transparent funds sent to unified addresses could not reliably
be shielded, as a unified address will frequently be constructed
using a diversifier index greater than zero.
This modifies the `get_transparent_receivers` method to return address
metadata containing the account ID and diversifier index used to derive
each address along with the receiver.
The legacy transparent address is never added to the `addresses` table,
but we still need to be able to receive UTXOs sent to that address. So,
we add a special case for when a UTXO matches that legacy address, and
set the account ID to 0 manually.
In 47a0d0d2b7 `WalletWriteTransparent` was
merged into `WalletWrite`, including its associated type `UtxoRef`.
However, `shield_transparent_funds` placed a bound on this associated
type that was not moved to `WalletWrite`. This left the generic
parameter `U` unconstrained, which didn't cause a local failure because
the method has no local tests, but was immediately apparent when trying
to use the method in the mobile SDKs.
This modifies `decrypt_and_store_transaction` to check for inputs
to a transaction being decrypted that correspond to utxos known
to our wallet. For each such UTXO found, it is marked spent.
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.
Francisco Gindre
Kris Nuttycombe
Sean Bowe
str4d
dependabot[bot]
Kris Nuttycombe