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.
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
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.)
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>
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>
is ephemeral.
This also fixes `try_into_standard_proposal` to allow decoding from the
protobuf representation into a proposal that uses references to prior
ephemeral transparent outputs, provided that the "transparent-inputs"
feature is enabled.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
now implement a different strategy for choosing whether there will be any
change, and its value. The aims are:
* Ensure that it is possible to create fully transparent transactions with
no change (this will be needed for ZIP 320). The `InsufficientFunds`
error in this case should have a `required` field that reflects the
additional amount needed, according to the fee calculated without an
extra change output.
* Avoid leaking information about note amounts in some cases: an adversary
that knew the number of external recipients and the sum of their outputs
was able to learn the sum of the inputs if no change output was present.
* Defend against losing money by using `DustAction::AddDustToFee` with a
too-high dust threshold.
* Ensure that if a "change memo" is requested, there will always be a
shielded change output in which to put it. Previously, this would not
be the case when using `DustAction::AddDustToFee`.
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
if a memo is given for the transparent pool. Use `ChangeValue::shielded`
to avoid this error case when creating a `ChangeValue` known to be for a
shielded pool.
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
changing its type from `ShieldedProtocol` to `PoolType`.
Also fix compilation errors when the "orchard" feature is used without
the "transparent-inputs" feature.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Prior to this change, the recipient of a sent transaction would always
be shown as the protocol-level address, instead of any unified address
intended as the recipient. Now, instead of reencoding the recipient
address, we use the original `ZcashAddress` value from the payment
request.
This implements the necessary state machine for taking a wallet in some
arbitrary synchronization status, and fully scanning (the remainder of)
the chain.
Closeszcash/librustzcash#1169.
Kris Nuttycombe
Daira-Emma Hopwood
Jack Grigg
Andrew Arnott
oscar-pepper