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`.
In a number of places, we transform other kinds of collections with
known length information into vectors simply to be able to use them with
`Vector::write` or `Vector::read`. We can avoid these extra allocations
by writing from iterators directly, and similarly by reading directly
into our desired collection types.
str4d
Kris Nuttycombe
Kris Nuttycombe
Daira Hopwood
ebfull