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>
`zcash_client_sqlite::wallet::transparent::ephemeral`. Also report the
account id and index for `SqliteClientError::ReachedGapLimit`.
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>
As part of this, we migrate to `secp256k1 0.27`. This version does not
bump `secp256k1-sys`, so remains compatible with the `libsecp256k1`
revision used in `zcashd`.
The `zcash_primitives::legacy::keys::AccountPrivKey` encoding also
changes to preserve the transparent extended key metadata. Previously
the type was documented as such, but only encoded the private key and
chain code; the new encoding now matches the documentation. As a side
effect, the unstable encoding of `zcash_keys::keys::UnifiedSpendingKey`
also changes.
Closeszcash/librustzcash#1407.
Closeszcash/librustzcash#1408.
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.
Previously, if the funding account for a received transaction output was
determined to be an account known to the wallet, the output was recorded
as though it were sent to an internal (change) address of the wallet.
This fixes an error wherein a note commitment in the last note
commitment position in a block was not being correctly marked as a
checkpoint.
This would occur when a block contained both Sapling and Orchard note
commitments, but the final transaction in the block contained only
either Sapling or Orchard note commitments, but not both.
Fixes#1302
During wallet migration in particular, the absence of _any_ accounts is
expected, and all seeds should be treated as relevant (because accounts
cannot be added before a wallet is initialized).
The blanket `impl Account<A> for (A, Option<UnifiedFullViewingKey>)` is
removed because we cannot know the UIVK for `(A, None)`. We instead
provide a blanket impl for `(A, UnifiedIncomingViewingKey)`. We also
move both of them behind `test-dependencies` because they are only
intended for testing purposes.
This should never have had the behavior of returning an error on a
missing txid in the first place; doing so conflates database corruption
or connectivity errors with the ordinary case where data may not be
available.