Fix inconsistent -O1/-O2, fix libzcash flags, add -fwrapv -fno-strict-aliasing
Closes#1168. In that ticket I decided the optimization flags for dependencies are out of scope, i.e. we go with whatever the upstream package maintainer chose.
New private/public key pairs for broadcasting alert messages
Implements #424
Fixes and integrates method of sending alerts as described by upstream here:
- https://gist.github.com/laanwj/0e689cfa37b52bcbbb44
To send an alert:
- Copy private keys into alertkeys.h.
- Modify alert parameters and message found in sendalert.cpp
- Build and run to send the alert e.g. ./zcashd -printtoconsole -sendalert
Tested and verified with local nodes on alpha 6 testnet.
CPourTx structural changes
* Enable binary serialization of proofs and the proving key (closes#799) and make the proofs fixed-size.
* Reorder fields of CPourTx to match the spec (closes#927)
Run `zcash-gtest` in `make check` and fix performance tests.
* gtest tests weren't being run by make check
* performance tests were broken
* We need to automatically upload graphs of performance, [see this PR](https://github.com/Electric-Coin-Company/bbotzc/pull/15).
* Moves zerocash tests into `zcash`'s full test suite, we're removing them anyway later and it'd be nice to remove them in the PR instead of from buildbot
Implement and integrate new Incremental Merkle Tree
This supersedes #823.
----
This is an implementation of a new incremental merkle tree with
* no memory safety issues
* a more sensible internal design
* better space efficiency (tree representation, witnessing)
* simpler API
It is intended that this tracks the behavior of the previous tree, which it does, as verified by tests. I even wrote a little circuit for testing that all the paths work.
This PR also integrates the tree into the codebase and deprecates the old tree in almost all of our code. (I left it alone in `zerocashTest` but everything else has been changed.)
This change is compatible with the testnet but you will need to clear your *local* blockchain data out since the serialized representation of the merkle tree is now different.
Closes#517, Closes#519, Closes#591, Closes#460, Closes#473
This is a new implementation of the incremental merkle tree used by our
scheme to witness commitments to spendable value. It serves as a fixed-sized
accumulator.
This new construction has a much simpler API surface area, avoids memory
safety issues, remains pruned at all times, avoids serialization edge cases,
has more efficient insertion, and is abstract over the depth and hash
function used at the type level.
Further, it lays the groundwork for efficient "fast-forwarding" of witnesses
into the tree as the treestate is updated.
