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>
Add -lightwalletd experimental option
Similar to `-insightexplorer` but loading less indexes.
After testing and code review this should be able to close https://github.com/zcash/zcash/issues/4326
multiple debug categories documentation
The command line help is not clear on how to execute multiple but specific debug categories. Failed with stuff like `-zcashd -debug=category1, category2`, etc to find how to do it after some time.
The proposed line addition should help with that.
Check failing transparent and JoinSplit signatures against the previous network upgrade
This change improves usability across network upgrades, by informing
users when their new transactions are being created with the consensus
branch ID from the previous epoch.
We only check failing signatures against the previous epoch to minimise
the extra computational load on nodes.
A future refactor is needed to similarly check Sapling signatures.
Part of #4260.
depends: Fix OpenSSL download path
The top-level URL is only valid for the latest OpenSSL release. Each release series has its own URL subpath for downloading historic releases.
The previous version of full_test_suite.py directly called the test
binary, which was being compiled at the same time as the static library.
However, by passing the --tests argument to cargo, rustc was ignoring
several important release-profile configurations, and was also
attempting to link the test binary, which was breaking cross-compilation
builds.
This commit alters src/Makefile.am to only build the static library, and
leaves test compilation to the test runner itself. This ensures that the
tests are only compiled for native builds, when the tests will be run on
the same platform.
std::vector<T> is guaranteed to store T contiguously. However, there is
no guarantee that sizeof(std::array<unsigned char, N>) == N, which
prevents us from interpreting std::vector<std::array<unsigned char, N>>
as &[[u8; N]] on the Rust side of the FFI.
Instead, we define HistoryEntry as a struct wrapping a C array, which
(as checked by static_assert) contains no padding.
The "finalsaplingroothash" field of the getblocktemplate output is no
longer guaranteed to match the actual Sapling commitment tree root, and
has been deprecated. Users should migrate to "lightclientroothash".
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).
Jack Grigg
Homu
Dimitris Apostolou
Daira Hopwood
Alfredo Garcia
NikVolf
ca333