Circuit change for endianness
This PR changes the circuit, encodings and parameters to match the encodings specified in the protocol spec. You'll want to `rm ~/.zcash-params/*.params` and run `./zcutil/fetch-params.sh --testnet` to switch to the new parameters for testnet.
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.
Optimistically test the latch bool before taking the lock.
For all IsInitialBlockDownload calls after the first to return false,
this avoids the need to lock cs_main.
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.
Update Payment API
I included those missing commands to the API reference: `z_exportviewingkey`, `z_importviewingkey`, and `z_listunspent`.
Do you think we should include `z_mergetoaddress`, `z_getpaymentdisclosure`, and `z_validatepaymentdisclosure` too, despite they are experimental?
I included those missing commands to the API reference: `z_exportviewingkey`, `z_importviewingkey`, and `z_listunspent`.
Do you think we should include `z_mergetoaddress`, `z_getpaymentdisclosure`, and `z_validatepaymentdisclosure` too, despite they are experimental?
libzcash::PaymentAddress has been renamed to libzcash::SproutPaymentAddress,
and a new typedef boost::variant is now libzcash::PaymentAddress. Similarly
for ViewingKey and SpendingKey.
A new class InvalidEncoding is introduced as the default boost::variant
option for each address and key type; it is used during decoding instead
of boost::optional.
All address and key storage functions in the wallet have been modified to
refer specifically to the Sprout types, as they are used very precisely.
In most other cases, the more general type is leveraged as much as possible,
and we convert to the Sprout type when necessary. This will be subsequently
wrapped in, or replaced with, context-specific functions once Sapling
types are implemented.
Key encoding refactor
Includes code cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#11372
- Only the first three commits (the fourth commit depends on #2390)
Part of #3058.