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.
Currently only unauthenticated connections are supported (i.e. no API
keys can be configured). However, AFAICT none of these exchanges provide
non-IP-based rate limits for authenticated connections to public APIs,
so authentication wouldn't help to make connections over Tor more
reliable.
Jack Grigg
Daira-Emma Hopwood
Kris Nuttycombe
Andrew Arnott