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
Kris Nuttycombe
Daira-Emma Hopwood
Kris Nuttycombe
Jack Grigg
Andrew Arnott