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
```
Resolves Sapling nullifier persistence issue when importing a key.
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 balance to include
notes which had already been spent.
The resolution is to force a CWalletTx to be persisted after it has had
its nullifiers set correctly, before the note witnesses are updated.
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 original commitments were SHA256 outputs, and some were outside the
scalar field. This didn't affect the Merkle hash, which drops the high
bit from each commitment, but it does affect the creation of the Merkle
path in Rust, which requires path nodes to be valid scalars.
Here, we explicitly drop the high bit of all test vector commitments,
as well as reducing the two that remain outside the field. The test
vectors still pass, and can now also be used in the Rust implementation.
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.
Allow minimum-difficulty blocks on testnet
This is a consensus rule change on testnet that will result in a chain split (leaving the stuck chain, as desired).
Reverts #2766 and part of #1338.
Closes#3552.