#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>
Dockerfiles for zcashd CI builds
Please ensure this checklist is followed for any pull requests for this repo. This checklist must be checked by both the PR creator and by anyone who reviews the PR.
* [ ] Relevant documentation for this PR has to be completed and reviewed by @mdr0id before the PR can be merged
* [ ] A test plan for the PR must be documented in the PR notes and included in the test plan for the next regular release
As a note, all buildbot tests need to be passing and all appropriate code reviews need to be done before this PR can be merged
This PR is intended to move the existing buildbot worker docker images into this repo, and provide for a way to build gitian-builder images.
The included README.md describes the purpose and an example script.
When this is merged the existing buildbot CI will be updated to start using these images.
Added Dockerfile to contrib with README
Please ensure this checklist is followed for any pull requests for this repo. This checklist must be checked by both the PR creator and by anyone who reviews the PR.
* [ ] Relevant documentation for this PR has to be completed and reviewed by @mdr0id before the PR can be merged
* [ ] A test plan for the PR must be documented in the PR notes and included in the test plan for the next regular release
As a note, all buildbot tests need to be passing and all appropriate code reviews need to be done before this PR can be merged
Reproduce and fix off-by-one error in reorg logic (#4119)
This attempts to reproduce #4119 using a simple chain split.It currently seems to trigger a different issue, an assertion failure in `CheckBlockIndex` when restarting
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.
Fix advertised version
Closes https://github.com/zcash/zcash/issues/4375 by adding the `-` character to the list of safe ones.
Now i can see stuff like the following in the logs:
```
...
2020-04-13 14:19:37 receive version message: /MagicBean:2.1.1-1/: version 170009, blocks=795400, us=[2800:a4:316b:8e00:ceb:c7b4:3481:197f]:59754, peer=2
...
```
API call `getpeerinfo` will also gets fixed.
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
Homu
ebfull
Daira Hopwood
Jack Grigg
Kris Nuttycombe
Kris Nuttycombe
Ben Wilson
Tim Ruffing
Aaron Clauson
Adam Langley
Thomas Snider