Rename the FS_ZIP214_ECC funding stream to FS_ZIP214_BP
See also https://github.com/zcash/zips/pull/412 .
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Flush witness data when consistent (part 2)
Closes#4680. After CWallet::ChainTipAdded() updates the witness data, it may flush it to disk (SetBestChain()); make sure the locator part is consistent with the witnesses (height).
After CWallet::ChainTipAdded() updates the witness data, it
may flush it to disk (SetBestChain()); make sure the locator
part is consistent with the witnesses (height).
Add funding streams to consensus parameters.
Add funding stream payments to coinbase txns generated by the miner.
* Reduce valueBalance for shielded outputs to funding streams.
* Ensure we produce binding signatures in any case where shielded
outputs go to either a funding stream or the miner.
Enable Heartwood activation on mainnet
This sets the Heartwood activation height to `903000`, which follows the deprecation height of `v2.1.2-3` (which is set to deprecate on block `901475`, roughly 31 hours earlier, sometime mid-July).
Add support for Sapling full viewing keys
This PR adds Sapling support to `z_exportviewingkey` and `z_importviewingkey`, and stores imported Sapling viewing keys in the wallet.
Closes#3060.
Change "protect" terminology to "shield"
Closes https://github.com/zcash/zcash/issues/2149
Note: Renamed `wallet_protectcoinbase.py` to `wallet_shieldingcoinbase.py` because there was an existing file also named `wallet_shieldcoinbase.py`.
Reject blocks that violate turnstile
This is an implementation of a consensus rule which marks blocks as invalid if they would lead to a turnstile violation in the Sprout or Shielded value pools. The motivations and deployment details can be found in the [accompanying ZIP draft](https://github.com/zcash/zips/pull/210).
**This PR only introduces the rule for testnet at the moment.**
We achieve the institution of this rule in three ways:
1. Nodes prior to #2795 did not record the "delta" in the Sprout value pool balance as part of the on-disk block index. This was a long time ago, though, and all nodes that are consensus-compatible with the network today have been recording this value for newer blocks. However, the value is absent from older block indexes unless the node has reindexed or synchronized from scratch in the time since. We shouldn't need to require nodes to reindex in order to enforce this consensus rule. We avoid this problem by falling back on a hardcoded Sprout shielded value pool balance in a very recent block.
2. If during `ConnectBlock` we observe that the resulting shielded value pool balance of Sprout or Sapling is negative, we reject the block.
3. During the miner's block assembly process the miner will skip over transactions if adding them to the assembled block might violate the turnstile, since the resulting block would be invalid. This means that theoretical transactions violating the turnstile would still be relayed in the network (and made available in users' memory pools) and so a turnstile violation would have some visibility outside of block relay.
## Smoke Testing
It's really tricky to test the behavior that automatically falls back to hardcoded shielded value pool balances in our architecture because it's very testnet-specific and node-version-specific. However, we can do some smoke tests to see that everything is working.
I modified the serialization of `CDiskBlockIndex` to serialize `boost::none` for `nSproutValue`
```
if ((s.GetType() & SER_DISK) && (nVersion >= SPROUT_VALUE_VERSION)) {
boost::optional<CAmount> nSproutValueFake = boost::none;
READWRITE(nSproutValueFake);
}
```
and then began a reindex of my node which I interruped around height 130k on testnet. I then restored the original serialization and resumed the reindex; I have thus _roughly_ simulated a older node "upgrading" to a newer node that records the deltas when processing new blocks. My node showed pool monitoring was disabled, as expected, for Sprout. I confirmed that some blocks following the reindex had nonzero Sprout `valueDelta` from `getblock`, as expected. I finished the reindex, restarted the node, and confirmed that the serialization worked for newer blocks but not older blocks by querying `getblock`, simply as a reassurance.
Finally, I introduced the code in this PR and reloaded the node. The desired behavior (that the chain began to be "monitored" again) worked, and the values were consistent with the hardcoded constant. I then made a payment to a Sprout z-addr from the transparent pool and the pool value increased as expected, as reported by `getblockchaininfo`. I reindexed the node again to exercise the remaining logic and check for turnstile violations throughout the history of testnet; there were none.
The min-difficulty change is a bilateral consensus rule change, and so
must be conditionally enabled in order for the earlier section of the
chain to synchronise.
Technically this could be implemented as a network upgrade, but as this will
never be deployed to mainnet, a targeted fork will suffice.
The wallet now only stores Sapling extended spending keys, and thus can
only be used with keys generated from an HDSeed via ZIP 32.
Note that not all Sapling keys in the wallet will correspond to the
wallet's HDSeed, as a standalone Sapling xsk can be imported via
z_importkey. However, it must have been generated from a seed itself,
and thus is more likely to be backed up elsewhere.
This introduces a 'minimum chain work' chainparam which is intended
to be the known amount of work in the chain for the network at the
time of software release. If you don't have this much work, you're
not yet caught up.
This is used instead of the count of blocks test from checkpoints.
This criteria is trivial to keep updated as there is no element of
subjectivity, trust, or position dependence to it. It is also a more
reliable metric of sync status than a block count.
After discussion in #7164 I think this is better.
Max tip age was introduced in #5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.
Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.
170004 is the protocol version for the NODE_BLOOM change, which is being
"released" in this RC. The activation height is being set in the final release,
which means that we may end up with both RC and final release versions online
when Overwinter activates. Bumping the protocol version for Overwinter enables
RC nodes to be correctly disconnected.