The `FALSE` constant was introduced in sqlite version 3.23.0,
but Android does not support this version of sqlite until API
level 30; we support back to Android API 27 so we have to use
`0` as the constant for `FALSE` instead.
`lightwalletd` will return an error in the case that the requested end
height exceeds the chain tip. This should be considered a bug in
lightwalletd, but for now we will work around it in the wallet.
Prior to this change, the `mark_transparent_utxo_spent` method assumed
that the UTXO information for outputs belonging to the wallet would be
known to exist before their spends could be detected. However, this is
not true in transparent history recovery: the spends are detected first.
We now cache the information about those spends so that we can then
correctly record the spend when the output being spent is eventually
detected.
At present, data from this spend cache is never deleted. This is because
such deletions could undermine history recovery in some narrow cases
related to chain reorgs.
(if available) collides with an existing imported or derived FVK.
This does not check for collisions on IVK for `Incoming` accounts.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
This moves the tracking of whether or not a spending key is expected to
be available for an imported account into the `AccountSource::Imported`
variant.
This adds a mechanism that can be used by the backend to request
additional transaction data or status information from the client,
for the purpose of being to explore transparent transaction history
that is otherwise currently unavailable.
In the case that `decrypt_and_store_transaction` is being used to add
data for fully-transparent transactions to the database, it may be the
case that there is no existing relationship between a transaction and
the block height at which it was mined (unlike for transactions being
enhanced after discovery via block scanning.) This change makes it
possible to set the mined height for transactions that do not have any
shielded components that involve the wallet.
The test was previously shielding a 10,000 zatoshi transparent input,
which was precisely enough to pay the ZIP 317 fee, and resulted in a
"shielding" transaction that had one transparent input, and no outputs
of any kind. Under our new `is_shielding` definition in `v_transactions`
this would not be a shielding transaction (it is effectively a "donate
coin to miners" transaction).
Kris Nuttycombe
Jack Grigg
Daira-Emma Hopwood
Kris Nuttycombe
Alfredo Garcia