Make it clear that CWallet::GenerateNewZKey is Sprout specific
Closes https://github.com/zcash/zcash/issues/3577
When adding sapling support we had considered making the method `GenerateNewZKey` generic, but it ended up making more sense to add a second method `GenerateNewSaplingZKey` for sapling support.
This PR changes the name of `GenerateNewZKey` to `GenerateNewSproutZKey` and changes the return type from `libzcash::PaymentAddress` to `libzcash::SproutPaymentAddress` to make it more clear that this is what the method does.
Clarify in sendmany/z_sendmany rpc docs that amounts are not FP
Fixes#3539
I clarified in the docs that only 8 digits of precision are allowed. For example, if you try 9 digits you will get:
```
zcash-cli z_sendmany $TADDR "[{\"address\":\"$ZADDR\",\"amount\":0.123456789}]"
error code: -3
error message:
Invalid amount
```
Better error message when sending to both sprout and sapling
When trying to send to both Sprout and Sapling (not currently supported with z_sendmany) we were getting the following error in our operation result: `general exception: boost::bad_get: failed value get using boost::get`.
This PR changes this to fail with a better error message before the async operation begins:
```
error code: -8
error message:
Cannot send to both Sprout and Sapling addresses using z_sendmany
```
During a rescan, a CWalletTx was persisted to disk before it had its
note data set. This meant that upon restart, the CWalletTx would
potentially be missing its nullifiers causing the wallet's balance
to include notes which had already been spent.
The resolution is to ensure that after a rescan, a CWalletTx is
persisted after it has had its nullifiers set correctly.
Co-authored-by: Eirik Ogilvie-Wigley <eirik@z.cash>
The undecoded wallet transaction is logged before proceeding, so later
recovery of metadata might be possible. But the fact that the user is
using -zapwallettxes is a clear indicator that they want
transactions removed from their wallet, so this is the priority.
If 2.0.0 nodes upgrade to 2.0.1 after Sapling has activated, the v4 Sapling
transactions in their wallet will be treated as corrupt, and a rescan will be
triggered which will overwrite the old-format transactions with the new
Sapling-aware format.
This helps prevent users from triggering an assert if they pass in
Sapling addresses to RPC calls: z_mergetoaddress, z_importviewingkey
and z_exportviewingkey.
