This was only used to provide example code for Sapling usage of
the `NoteEncryption` struct; this example code has been moved
to `sapling::note_encryption`.
This removes the dependency on `SaplingIvk::to_repr()`, and enables us
to alter the type of `D::IncomingViewingKey` to improve the performance
of batch scanning.
For the welding rig, we already annotate the viewing keys with
`AccountId`, so we use `(AccountId, Scope)` as the tag.
The `zcashd` Rust code relies on being able to construct the Sapling
types transparently. This part of the "public API" of the crate was
broken when the `NullifierDerivingKey` newtype was introduced. We do
want to migrate to all of these types having stronger type safety
guarantees (by only constructing them via constructors), but that should
be done consistently across the types. For now we maintain the existing
API by changing `NullifierDerivingKey` to be a transparent newtype.
This updates `shield_transparent_funds` to look up the internal
(change) address for the account specified, and use that as the
destination for shielding transparent funds.
Fixed#614
Nullifier computation only requires the nullifier deriving key,
not the entire Sapling viewing key. This separation of concerns
will be needed for batch decryption when wallet-internal keys
will need to be considered.
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.
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`.
Daira Hopwood
Kris Nuttycombe
Jack Grigg
Kris Nuttycombe
ebfull