#4499 was an insufficient fix, because it did not consider the case where
a post-Heartwood node wrote a block index object for a header from a
non-upgraded peer. In that case the version in the block index entry is
`>= CHAIN_HISTORY_ROOT_VERSION`, and so the fix in #4499 has no effect.
In addition, we should skip the consistency check when the index object
validity is not BLOCK_VALID_CONSENSUS.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
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.
Sean Bowe
Daira Hopwood
Jack Grigg
Homu
Taylor Hornby
Dimitris Apostolou