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.)
within the gap. Also support paging for `get_known_ephemeral_addresses`.
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
enabled. (I got this right in a previous commit but broke it when
refactoring the proposal error handling.)
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
unconditionally.
This removes a bunch of `#[cfg(feature = "transparent-inputs")]`
conditionals, with negligible (if any, after compiler optimization)
overhead. It also requires callers of functions with an
`ephemeral_parameters` parameter to do the intended thing to work
with "transparent-inputs" either enabled or disabled.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
See #1316 for re-adding it.
The previous code was essentially dead because it had no side effects
other than potentially returning an error. That error is unnecessary
and incorrect when we are not actually performing dust spends.
When we re-enable them, we should not try to make dust spends in
any transaction with non-default `ephemeral_parameters`, or if the
`dust_output_policy` is `DustAction::AddDustToFee`. That would
guarantee that we will always have a shielded change output, which
makes the calculations more tractable and excludes some potentially
complicated interactions.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
This now only supports a single ephemeral input and/or output when
constructing a proposal (multiple ephemeral outputs are still supported
when creating transactions).
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Jack Grigg
Kris Nuttycombe
Andrew Arnott
Daira-Emma Hopwood