Windows cross-compile has currently-unavoidable warnings. Upstream Bitcoin Core
has them as well. For now, let's remove this from the default configuration, and
add it to the Linux and OSX CI builders (so we effectively still enforce it for
merged PRs).
By using the flags defined through ./configure instead, libzcash will react to
configuration and build system changes (such as PIC_FLAGS being empty for
Windows builds).
Set Sapling mainnet activation height
In mainnet, block #419200 is expected to appear on October 28, 2018, Zcash's birthday.
In testnet, block #280000 is expected about a week from now. (Current height is ~275249, plus 4032 blocks for a week, plus a little more just to make the number nice.)
These are the activation heights for Sapling in mainnet and testnet, respectively. Protocol version is also changed.
Always write the empty root down as the best root, since we may roll back
In [`3577de83`](3577de83aa) we started not writing the Sapling empty root down as the "best" anchor because we had changed the encodings and didn't want users who compiled from master to have inconsistent coindb's in the future if the encoding changed again for some reason.
However, if we don't write the empty root down then during rollbacks to Sapling activation we leave the best anchor on disk different from what's in the cache, which will trigger an assertion.
This reverts the change from `3577de83` since we've settled on the encodings.
ZIP 32 preparations
Includes Makefile changes cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849
Part of #3380.
Wallet must come before crypto, otherwise linking fails on some platforms.
Includes a tangentially-related general cleanup rather than making the Makefile
sloppier.
Update CCryptoKeyStore with Sapling support
Sapling crypter overrides for various `CCryptoKeyStore` functions such as:
- `HaveSaplingSpendingKey()`
- `GetSaplingSpendingKey()`
Also includes some changes to prepare for diversified addresses and ZIP 32.
Closes#3389