This replaces the current wallet initialization code with a migration
that brings the database up to the state produced by release 0.3.0.
A subsequent commit will add migrations that correctly produce the
database state as of zcash/librustzcash@602270cb1f.
Fixes#369
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.
Add retrieval of transparent UTXOs to WalletRead
Co-authored-by: Kris Nuttycombe <kris@electriccoin.co>
Co-authored-by: Kevin Gorham <anothergmale@gmail.com>
Previously we were retrieving nullifiers for notes that were not
marked spent, but not checking against whether the spending
transaction had been included in a block.
`create_spend_to_address` was originally written only for sending to
Sapling addresses. It was later amended to support sending to
transparent addresses, but the assumption about there being a Sapling
output was not removed. This was not an issue for most transactions
because there would be change, but in the case of a z->t transaction
with no change, `create_spend_to_address` would reliably panic.
This commit fixes the bug by setting the output index for transparent
recipients to 0. The `output_index` field of `SentTransaction` is also
documented to correctly reflect its dependency on the type of
`recipient_address`.
The MemoBytes struct is a minimal wrapper around the memo bytes, and only
imposes the existence of null-padding for shorter memos. The only error
case is attempting to construct a memo that is too long. MemoBytes is
guaranteed to be round-trip encodable (modulo null padding).
The Memo enum implements the additional memo rules defined in ZIP 302,
interpreting the contents of a memo (for example, parsing it as text).