on with the Equihash solution trimming:
* (counter) `zcashd.debug.memory.allocated_equihash_solutions` -
the number of Equihash solutions that have ever been allocated;
* (counter) `zcashd.debug.memory.trimmed_equihash_solutions` -
the number of Equihash solutions that were trimmed;
* (counter) `zcashd.debug.blocktree.trimmed_equihash_read_dbindex` -
the number of times a block index entry needed to be reread to
construct a block header because a solution had been trimmed;
* (counter) `zcashd.debug.blocktree.write_batch` -
the number of block tree batch write operations (calls to
`CBlockTreeDB::WriteBatchSync`);
* (counter) `zcashd.debug.blocktree.write_batch_read_dbindex` -
the number of times a block index entry needed to be reread
before being written during a block tree batch write operation.
These metrics are specific to `zcashd`; they are primarily intended
for performance debugging of this feature and should not be considered
stable.
Co-authored-by: Jack Grigg <thestr4d@gmail.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
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.
- 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.
CBlockHeader.hashFinalSaplingRoot has been renamed to hashLightClient.
CBlockIndex now stores:
- hashLightClient as from the block header
- hashFinalSaplingRoot, which is accurate for all blocks prior to
Heartwood activation, and all blocks from Heartwood activation onward
that are connected at some point to the main chain in ConnectBlock().
- hashChainHistoryRoot, which is null prior to Heartwood activation, and
set per ZIP 221 from Heartwood activation.
The new block index fields are only written to disk for client version
2.1.2 and above, which will be the first Heartwood-aware clients (even
if Heartwood doesn't have an activation height).
Note that the MTP of a block is the median timestamp of the preceding 11 blocks, i.e. it is
typically (with no or only moderate timestamp manipulation) expected to be 6 block intervals
behind that block's timestamp, which *on average* is 450 seconds behind (after Blossom activation).
So the effective limit on future dating of timestamps is ~82.5 minutes. This makes it
exceptionally unlikely --even taking into account feasible timestamp manipulation of this
and previous blocks-- that the chain will stall because no block is found before the limit.
(This may rely on assumptions that do not hold for testnet.)
If an adversary were to have a sufficient fraction of mining power to engineer this situation
then there would be something seriously wrong, and arguably the chain should stall in that
case, pending manual intervention.
Co-authored-by: Jack Grigg <jack@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Break the circular dependency between main and txdb by:
- Moving `CBlockFileInfo` from `main.h` to `chain.h`. I think this makes
sense, as the other block-file stuff is there too.
- Moving `CDiskTxPos` from `main.h` to `txdb.h`. This type seems
specific to txdb.
- Pass a functor `insertBlockIndex` to `LoadBlockIndexGuts`. This leaves
it up to the caller how to insert block indices.
Zcash: This does not actually break the circular dependency for us yet, as we
still need to pull in bitcoin/bitcoin#7756 and bitcoin/bitcoin#7904.
Remove the nType and nVersion as parameters to all serialization methods
and functions. There is only one place where it's read and has an impact
(in CAddress), and even there it does not impact any of the recursively
invoked serializers.
Instead, the few places that need nType or nVersion are changed to read
it directly from the stream object, through GetType() and GetVersion()
methods which are added to all stream classes.
Block indices are flushed to disk when they are marked as dirty, and this
happens via enough distinct pathways that it would be sufficiently complex to
update nSproutValue via all of them. Thus it is necessary to be able to
serialize "no value" for writes by upgraded clients.
Delta values will be stored for new blocks; old blocks can be filled in by
re-indexing. The net value currently in the Sprout circuit is only calculated
when delta values for all previous blocks are present.
Bitwise logic combined with `<` with undefined signedness will
potentially results in undefined behavior. Fix this by defining the type
as a c++11 typed enum.
Fixes#6017.
The genesis blocks and miner tests have been regenerated, because changing the
block header serialisation format changes the block hash, and thus validity.
The Equihash solutions have been removed from the bloom test inputs for
simplicity (block validity is not checked there; only a valid serialisation is
necessary).
This field has no defined semantics. While it was added as a result of
discussions about merged mining in #724, this field will not necessarily ever be
used for that purpose.
The main and test networks are configured to use parameters that are currently
low-memory but usable with the basic solver; they will be increased once the
solver is optimised. The regtest network is configured to have extremely low
memory usage for speed.
Note that Bitcoin's double-hasher is used for the difficulty check. This does
not match the paper, but is simpler than changing the block header
serialization. Single hashing is kept for the EquiHash solver because there is
no requirement on execution time there, only on memory usage.
str4d
Kris Nuttycombe
Alfredo Garcia
Daira Hopwood
str4d
Jack Grigg
Wladimir J. van der Laan
Sean Bowe
Pieter Wuille