memory_cleanse backports
Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#10308
- bitcoin/bitcoin#11196
- bitcoin/bitcoin#11558
- Only the changes that did not conflict.
- bitcoin/bitcoin#16158
Part of #145.
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)`
So far, the documentation of memory_cleanse() is a verbatim copy of
the commit message in BoringSSL, where this code was originally
written. However, our code evolved since then, and the commit message
is not particularly helpful in the code but is rather of historical
interested in BoringSSL only.
This commit improves improves the comments around memory_cleanse()
and gives a better rationale for the method that we use. This commit
touches only comments.
Commit fbf327b13868861c2877c5754caf5a9816f2603c ("Minimal code
changes to allow msvc compilation.") was indeed minimal in terms
of lines touched. But as a result of that minimalism it changed the
logic in memory_cleanse() to first call std::memset() and then
additionally the MSVC-specific SecureZeroMemory() function, and it
also moved a comment to the wrong location.
This commit removes the superfluous call to std::memset() on MSVC
and ensures that the comment is in the right position again.
The implementation we currently use from OpenSSL prevents the compiler from optimizing away clensing operations on blocks of memory that are about to be released, but this protection is not extended to link-time optimization. This commit copies the solution cooked up by Google compiler engineers which uses inline assembly directives to instruct the compiler not to optimize out the call under any circumstances. As the code is in-lined, this has the added advantage of removing one more OpenSSL dependency.
Regarding license compatibility, Google's contributions to BoringSSL library, including this code, is made available under the ISC license, which is MIT compatible.
BoringSSL git commit: ad1907fe73334d6c696c8539646c21b11178f20f
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.