`Wallet::append_bundle_commitments` should never be called twice on the
same bundle, as that breaks sequentiality requirements (which we already
check for), so it is safe to assert that the inserted values do not
overwrite any existing data.
In `ScanForWalletTransactions` we skip forward from `pindexStart` to a block
near our wallet birthday. But we use this as the basis for deciding the value
of `performOrchardWalletUpdates` later, which is wrong because our wallet
birthday might be beyond the NU5 activation height. The result is that we
won't actually perform the required scanning (mainly witnessing and so forth)
needed to spend notes in our wallet.
The 13.0.1-1 MSYS2 binaries cause linker errors due to missing `new` and
`delete` symbols. This commit partially reverts the LLVM 13.0.1 upgrade:
Windows cross-compilation still uses `clang 13.0.1`, but is compiled
against `libc++ 13.0.0`.
(cherry picked from commit fdb5709e7e)
We have a pending PR to address the `native_ccache` and `googletest`
dependencies, and we aren't going to touch `bdb`.
(cherry picked from commit 4c49af7750)
If we no longer have any checkpoints in the Orchard wallet, we must
skip the check against the prior note commitment tree root because
we know that the Orchard wallet's state may be for a chain that is
being reorg'ed away. This is safe because we know that we will have
removed all information from the wallet that we need to perform spends
from that state, and we also know that when we start rolling forward
along the new chain that we will overwrite the initial state of the
Orchard note commitment tree.
When initializing a new Orchard wallet after NU5 activation, it is
not valid to start from the empty note commitment tree; instead,
the note commitment tree needs to be initialized from the state of
the global Orchard Merkle frontier.
In addition, this change necessitates a change to how rewinds work,
such that in a rollback scenario with a newly initialized wallet
that does not have sufficient checkpoints to fully satisfy a requested
rewind, the rewind is allowed to proceed so long as it does not
invalidate any persisted witness data.
If a new Orchard wallet is created after the first Orchard spend
post NU5 activation, it causes an assertion failure because the root
of the wallet's empty note commitment tree does not match the global
note commitment tree root.
This more accurately reflects its meaning, as it corresponds to the most
recently persisted best chain (i.e. the chain tip that the wallet will
return to on restart), rather than the chain tip to which the in-memory
wallet state has been synced.
The comment on `view.SetBackend(dummy)` was removed when we backported
upstream locking PRs in zcash/zcash#5017. The upstream commit in
question removed a locking scope but did not remove the reference to
that scope in the comment. Our backport removed the outdated comment,
but should have modified it instead, because otherwise the existence of
`view.SetBackend(dummy)` is very confusing (as it disconnects the cache
from `pcoinsTip`, on the assumption that everything we need from it has
been cached via calls to `CCoinsViewCache::HaveCoins` and
`CCoinsViewCache::HaveShieldedRequirements`).