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.
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.
This updates UnifiedFullViewingKey to conform to ZIP 316, and
adds types that facilitate this support. These types should likely
be factored out from `zcash_client_backend` into `zcash_primitives`
along with the remainder of the existing unified address support.
Add retrieval of transparent UTXOs to WalletRead
Co-authored-by: Kris Nuttycombe <kris@electriccoin.co>
Co-authored-by: Kevin Gorham <anothergmale@gmail.com>
In the interest of making the library usable for both
testnet and mainnet without recompilation, static resolution
of network parameters has been replaced with a parameter passed
to the relevant functions. This also moves addres prefix constants
into the network parameters.
This enforces the MUST requirement in ZIP 32. A panic is used instead of
an error because this should be considered an implementation error.
Ideally the type system would prevent this from occurring at all.
Closes#125.