Previously we were reconstructing the height on wallet load by looking
up the `blockHash` field of `CMerkleTx` to find the transaction's height
in the main chain. However, this field is updated whenever `AddToWallet`
is called, while the transaction's height and note positions need to be
kept in sync with `SetBestChain`, which is only called once every 10
minutes. In the case that a reorg occurs between `SetBestChain` and the
node shutting down, the resulting height on wallet load would be
inconsistent. As with note positions, any inconsistency should be
resolved by the post-load wallet rescan, which rewinds the Orchard
witness tree and unsets any position information.
Part of zcash/zcash#5784.
We add both C++ client version information (enabling version-specific
changes if necessary, matching the rest of the C++ wallet), and record
version information (enabling local serialization format changes).
Part of zcash/zcash#5784.
We rewrite the entire witness tree each time we update the wallet's best
chain state, and we need the note positions to always be consistent with
the tree state (otherwise mined notes become unspendable after the node
restarts).
The test fails during the final `z_sendmany`, because it is selecting a
note that was detected before restarting the node. Because we force the
wallet to call `SetBestChain` on every block, the wallet doesn't need to
rescan on restart, and thus doesn't repopulate the `position` field of
the in-memory note.
This issue went unnoticed in existing tests that exercise node restarts,
because the RPC tests are fast enough that they never pass the 10-minute
timeout for writing the wallet state. This commit adds a regtest-only
config option that disables the lazy writing.
The filter that restricted the restore of default Sapling addresses to
the wallet, which limited the restoration to those addresses associated
with the legacy key, was too restrictive; it meant that imported
addresses were not restored to the wallet. That check has been inverted,
such that we now restore the default address for any key that is not
associated with the mnemonic seed.
It is possible for an address to be generated for a UFVK that
contains an Orchard FVK, but where the address does not contain
an Orchard receiver. Cache restoration was failing on startup
because we failed to allow for this case.
The test was creating a fake shielding transaction, but by using a
single null `COutPoint` it was accidentally trying to create a coinbase
transaction, which was then rejected by the consistency checks on the
Rust side (which require that no inputs be provided for a coinbase
transaction, which by definition has no real inputs).