`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.
This also provides additional documentation for why it's necessary
to store ephemeral_addresses table entries at indicies that do not
correspond to valid addresses.
It was possible for `GreedyInputSelector` to crash if the change
strategy being used for input selection were to place a ZIP 320
ephemeral output anywhere but as the last element in the returned change
values. This has been replaced by an error; the error will also be
returned if the change strategy returns more than one ephemeral output
in the change values.
The `EphemeralParameters` type makes too many states representable, in
particular, it represents that it is possible for a proposal step to
have both ephemeral inputs and ephemeral outputs. This change reduces
the representable state space to make it so that only one or the other
is true, and also makes clear that the change memo must be attached to
the change output of the intermediate step, and not to the ultimate
output to the final recipient (where we expect there to be no shielded
change, and therefore it is not possible to attach a memo.)
Daira-Emma Hopwood
Kris Nuttycombe
Jack Grigg
Andrew Arnott