If we are doing an expected rollback that changes the consensus
branch ID for some upgrade (or introduces one that wasn't present
at the equivalent height) this will occur because
`SelectHistoryCache` selects the tree for the new consensus
branch ID, not the one that existed on the chain being rolled
back.
In the vicinity of a network upgrade, a zcashd node may receive headers
for a non-upgrading chain from its non-upgraded peers (e.g. if the block
at the NU activation height is found more quickly by the non-upgrading
chain). In this situation, the node will end up with two headers at the
NU activation height (and possibly for subsequent block heights).
In the case of Heartwood, the block headers from the non-upgrading chain
do not satisfy the Heartwood header consistency check in
CBlockTreeDB::LoadBlockIndexGuts. In this commit, we restrict the
Heartwood consistency checks to block index objects that were created by
clients that are CHAIN_HISTORY_ROOT_VERSION or better.
Release v2.1.2
Includes **testnet** activation of Heartwood (NU3) on block `903800` -- approx May 6th, 4pm MST. Does **not** include mainnet activation, that's planned for `3.0.0`. See release notes for other cool changes.
- hashFinalSaplingRoot is now always set to hashLightClientRoot before
Heartwood activation (regardless of whether or not that is the correct
Sapling root), and set to the Sapling root after Heartwood activation
only for blocks that have been passed to ConnectBlock() at least once.
- hashChainHistoryRoot is now always set "correctly" (either null, or
identical to hashLightClientRoot).
We rely on the fact that block headers are downloaded in order, and we
therefore always know the height of a block header, in order to check
whether Heartwood is active for a particular header.
Compute more structures in CTxMemPool::DynamicMemoryUsage()
Closes https://github.com/zcash/zcash/issues/4224
Added more structures to the computation of the mempool memory size as indicated in the issue. RPC call `getmempoolinfo` is the only place where this is used to get the `usage` result.
Lock with cs_main inside gtests that request chain state
Fix https://github.com/zcash/zcash/issues/4389
- Used the lock from boost tests where `chainActive.Height()` is being called: https://github.com/zcash/zcash/blob/master/src/wallet/test/rpc_wallet_tests.cpp#L1323
- I found no other place in the gtests where `chainActive` is used apart from just the same tests `chainActive.Height()` is called. It seems chain state is only used when we fake mine transactions and these are all inside `test_wallet.cpp`.
I might be missing some other patterns to look at, please let me know if so.
consensus: From Heartwood activation, use Rust Equihash validator
The C++ and Rust Equihash validators are intended to have an identical
set of valid Equihash solutions, so this should merely be an
implementation detail. However, deploying the Rust validator at the same
time as a network upgrade reduces the risk of an unintentional consensus
divergence due to undocumented behaviour in either implementation.
Once Heartwood has activated on mainnet, we can verify that all
pre-Heartwood blocks satisfy the Rust validator, and then remove the C++
validator and make Equihash-checking non-contextual again.
Replaces zcash/zcash#2851.
The C++ and Rust Equihash validators are intended to have an identical
set of valid Equihash solutions, so this should merely be an
implementation detail. However, deploying the Rust validator at the same
time as a network upgrade reduces the risk of an unintentional consensus
divergence due to undocumented behaviour in either implementation.
Once Heartwood has activated on mainnet, we can verify that all
pre-Heartwood blocks satisfy the Rust validator, and then remove the C++
validator and make Equihash-checking non-contextual again.
This requires moving CheckEquihashSolution() to
ContextualCheckBlockHeader() for all but the genesis block, which has no
effect on consensus; it just means that an invalid Equihash solution is
rejected slightly later in the block validation process.
Quoting the documentation for `std::vector::operator[]`:
Portable programs should never call this function with an argument
n that is out of range, since this causes undefined behavior.
This test was doing just that: performing checks on a non-existent
second Sapling witness (duplicating the Sprout logic that checked two
notes, one of which was in the wallet). The test was instead reading
arbitrary memory after the witness that did exist; in most cases, this
memory was interpreted as a `boost::none` as expected, but in some cases
the memory was interpreted as a "real" witness.
Closeszcash/zcash#4445.
Co-authored-by: Ying Tong <yingtong@ethereum.org>
The mempool timestamps are local to each node, and if the testing
machine is under load, they can potentially differ by a second.
Closeszcash/zcash#4439.
Co-authored-by: Ying Tong <yingtong@ethereum.org>