The following crates required explicit downgrades:
arrayvec v0.4.12 -> v0.4.11
autocfg v0.1.7 -> v0.1.6
c2-chacha v0.2.3 -> v0.2.2
ppv-lite86 v0.2.6 -> v0.2.5
proc-macro2 v1.0.10 -> v1.0.3
error: no matching package named `quote` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `ff_derive v0.6.0`
... which is depended on by `ff v0.6.0`
... which is depended on by `bellman v0.6.0`
... which is depended on by `librustzcash v0.2.0 (/home/nuttycom/work/zcash)`
Add confirmations, blockheight, blockindex and blocktime to z_listreceivedbyaddress
Fixes https://github.com/zcash/zcash/issues/3724
1- There was a PR to add confirmations to this call at https://github.com/zcash/zcash/pull/3836
I ported the commit from there and fixed test case by incrementing the confirmations as suggested at: https://github.com/zcash/zcash/pull/3836#issuecomment-499927807
2- Then added `blockheight`, `blockindex` and `blocktime`. To avoid some duplicated code (Sprout/Sapling) created a structure `trxblock`.
3- Original issue requests only time and blockindex however i think height is also important; if `blockindex` is the position of the transaction in the block then you are going to need also `height` to find it.
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.
Homu
Kris Nuttycombe
Alfredo Garcia
Sean Bowe
Daira Hopwood
Dimitris Apostolou
Jack Grigg
Taylor Hornby