In zcash/zcash/pull/5544 we added an FFI method specific to the Orchard
part of the transaction builder, to enable passing the Orchard bundle on
the Rust side directly instead of using a partial serialization. We
passed the remainder of the transaction to the Rust side by serializing,
as we similarly do in `SignatureHash`. We then decomposed the parsed
transaction on the Rust side to insert the Orchard bundle. However, we
then used the `TxDigests` that was derived from the parsed transaction,
not the reconstructed one, which meant we produced an invalid sighash
when building Orchard-containing transactions.
The addition of `OrchardRawAddress` to `RecipientAddress` drives most of
the changes in this commit, which enable `z_sendmany` to send funds to
addresses in the Orchard pool once NU5 activates.
- We added `OrchardRawAddress` to the `Receiver` variant, which prevents
it from having a default constructor.
- We added `ReceiverType::Orchard`, which Clang warns is unused when we
use `ReceiverType` in a `switch` statement.
We also add Orchard-specific information to several RPCs in order for
tests to pass:
- `z_listunifiedreceivers`
- `z_getbalanceforaccount`
- `z_getbalanceforviewingkey`
We add the Orchard change address mapping on account creation, as we
only ever generate a single change address internally. External Orchard
receivers are added to the map when `z_getaddressforaccount` is called.
This commit also fixes two bugs in the handling of Orchard internal IVKs.
When adding a full viewing key to the Orchard (Rust) wallet, we need to
derive both the internal and external IVKs (and map them to the external
FVK so we effectively never expose the internal FVK). We were only
deriving the external IVK, meaning that trying to add the Orchard change
address to the wallet should have failed. However, in a separate bug the
C++ internal IVK derivation method was calling the Rust external IVK
derivation function, meaning that we were effectively using the external
Orchard address at index 0 _as_ the change Orchard address.
This ensures we have the same semantics for detecting Orchard and
Sapling receivers in UAs, even if the UA they are part of was derived
outside of the zcashd wallet.
The only place we were using the returned Unified Spending Key was in a
test, where we immediately converted it to a UFVK.
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
In cases where we want to be able to decode a string that
is known to be a unified address, it doesn't make sense to have
to route through KeyIO::DecodePaymentAddress and then return
an error depending upon the result type, when it's possible to
provide unified address parsing more directly.
KeyIO::DecodePaymentAddress has been modified to delegate
to UnifiedAddress::Parse
This tests the following operations:
* add a spending key to the wallet
* add notes from the Orchard bundle component of a transaction to the
wallet
* detect notes in the wallet that correspond to the spending key
* verify that notes that are not ours are not mistakenly labeled
as ours
Sean Bowe
Kris Nuttycombe
Jack Grigg
Taylor Hornby
str4d
Steven
Steven Smith
sasha
therealyingtong
Kris Nuttycombe
Larry Ruane