(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.
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
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.
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.)
Kris Nuttycombe
Daira-Emma Hopwood
Jack Grigg
Kris Nuttycombe
zancas
Oscar Pepper
Andrew Arnott