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).
`rust-toolchain.toml` is too old for the current proc-macros protocol
(specifically, the `--keep-going` flag was not stable in Rust 1.70, as
can be verified by `cargo +1.70.0 check --keep-going`).
This works around https://github.com/rust-lang/rust-analyzer/issues/17662 ,
and very likely future problems, because the rust-analyzer devs are quite
aggressive in depending on recent versions: "by policy we don't make any
attempts at supporting more than the last couple of stable releases"
according to https://github.com/rust-lang/rust-analyzer/issues/17662#issuecomment-2242265513 .
The toolchain we select in `rust-toolchain.toml` often lags behind that
intentionally, because we want to verify that we build with our MSRV.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
creating all of them. This avoids undesired retransmissions in case a
transaction is stored and the creation of a subsequent transaction fails.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
to construct a `SentTransaction`, and then call `wallet_db.store_sent_tx`
outside the `create_proposed_transaction` call.
This should have no semantic effect by itself, but is preparation to move
where we call `store_sent_tx`.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
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.
Kris Nuttycombe
Jack Grigg
Daira-Emma Hopwood
Andrew Arnott