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).
This fixes an issue wherein transparent outputs of transactions added to
the wallet via `decrypt_and_store_transaction` would not be properly
recorded as UTXOs belonging to the wallet.
Part of #1434
zcash/librustzcash@72d8df8e68 altered the
`v_received_notes` view to include transparent coins (renaming it to
`v_received_outputs`), and updated `v_transactions` to not separately
query transparent coins. The latter queried `v_received_notes` twice,
once to fetch notes received in a transaction, and again to fetch notes
spent in a transaction. The spent notes were obtained by joining on
the junction table `v_received_note_spends` to get the spent-in
transaction's ID. The commit retained the junction table join, but
didn't use it due to a typo, leading to notes being "spent-in" the
transaction they were received in. This bug had several effects:
- `account_balance_delta` showed `+change` for transactions in which a
change note was received that had not yet been spent.
- `account_balance_delta` showed `0` for transactions in which all
received notes had been subsequently spent.
- Transactions that spent funds with no change were omitted.