While it is necessary in the worst case to perform `m * n` decryptions,
where `m` is the number of outputs being decrypted and `n` is the number
of IVKs, it is possible to stop performing trial decryptions when the
first successful decryption is performed. Also, it's inconvenient and
unnecessary to return the full cartesian product of these results, as
only one IVK will decrypt a given output. This commit modifies batch
trial decryption to stop on the first successful decryption, and instead
of returning the cartesian product of results we return the index of the
input IVK along with the output it decrypted. Note that this means that
trial decryption is not constant-time with respect to the number and/or
order of IVKs.
We use the `redjubjub` crate for batch validation, because the demo
batch validation API in `zcash_primitives::redjubjub` cannot be used
outside that crate, and using `redjubjub` enables this to be published
as a point release of `zcash_proofs`.
The new `SaplingVerificationContextInner` struct handles accumulation of
`cv`, and preparation of the inputs to proof and signature verification.
`SaplingVerificationContext` uses it to maintain its existing inline
unbatched verification API.
We also add support for parsing Orchard full viewing keys from encoded
UFVKs (rather than treating them as unknown). `UnifiedSpendingKey` still
does not have Orchard support, so `UnifiedFullViewingKey`s will be
generated without Orchard components.
Per ZIP 316, the Sapling FVK Encoding only includes `(ak, nk, ovk, dk)`
which is a subset of the Sapling `ExtendedFullViewingKey`. We therefore
need to use `DiversifiableFullViewingKey` inside `UnifiedFullViewingKey`
in order to make it parseable from the UFVK string encoding.
`zcash_client_sqlite::wallet::get_extended_full_viewing_keys` has been
removed as a consequence of this change: we can no longer reconstruct
the correct `ExtendedFullViewingKey` from the `UnifiedFullViewingKey`.
The account number is not stored in the ZIP 316 UFVK encoding, and in
general won't necessarily be known (e.g. if a UFVK is being imported
into a wallet).
`zcash_client_sqlite::wallet::init::init_accounts_table` reverts to its
previous behaviour of requiring the provided `&[UnifiedFullViewingKey]`
to be indexed by account number.
This is a breaking change to the database format. We don't have support
for migrations yet, so existing wallets won't work after this commit
until zcash/librustzcash#489 is done.
We can't use the real ZIP 316 encoding until `UnifiedFullViewingKey` has
been altered to not store a Sapling `ExtendedFullViewingKey`. But making
that change first requires fully migrating `zcash_client_sqlite` in the
same commit (as its entire API is built around `ExtendedFullViewingKey`).
Instead, we define a temporary fake encoding, to enable migrating the
`zcash_client_sqlite` APIs more incrementally.
After adding the `RecipientAddress::Unified` enum case, `Param::Addr`
is now much larger than the other `Param` cases. This change reduces the
size of the `Param` enum, fixing a clippy lint.
This, along with the corresponding `TryFromRawAddress` trait, enables
converting `ZcashAddress` into a network-agnostic type.
Closeszcash/librustzcash#564.
This enables the user-defined conversions to be fallible, which they
will almost always want to be (as address data needs to be validated
before it can be used).
Kris Nuttycombe
str4d
ebfull
Daira Hopwood
Nathan Wilcox
dependabot[bot]