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
This modifies wallet scanning to perform per-block batched
decryption. It also alters the structure of the `ScanningKey`
trait to correctly include internal (change) keys in the scan
process.
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.
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.
We should attempt to avoid passing spending keys back and forth
across the FFI entirely, but in any case this is no longer the
correct type to use at this boundary; we should use the encoding
of the transparent component of a unified spending key instead.
Kris Nuttycombe
Kris Nuttycombe
Jack Grigg
Aditya Kulkarni
therealyingtong