Zcash 2.0.1

This release is the first Sapling RPC supported version of the Zcash node software!

Sapling Activation

Mainnet

This release is consensus-compatible with the Sapling network upgrade and adds significant support in the zcashd wallet RPC. We’re encouraging all users and miners to upgrade as soon as possible. The first block of Sapling will be block 419200, which is expected to be mined on the 28th of October 2018, the second anniversary of Zcash’s official launch. More information on the upcoming Sapling network upgrade can be found below:

• Sapling Network Upgrade
• Sapling Turnstile
• Network Upgrade Dev Guide

Testnet

Sapling has activated on the testnet at block 280000. If you are running a v2.0.1 node, you no longer need to specify -experimentalfeatures and -developersapling to use Sapling functionality on testnet. If you are running an older v2.0.0 node, please upgrade to version v2.0.1 which introduced a consensus rule change to allow min difficulty blocks to be mined from block 299188, thereby splitting the chain.

Other Notable Changes

Sapling RPC Support

This release contains support for Sapling RPC functionality on mainnet, enabling the sending of Sapling shielded funds.

Hierarchical Deterministic Key Generation

All Sapling addresses will use hierarchical deterministic key generation according to ZIP 32 (keypath m/32'/133'/k' on mainnet). Transparent and Sprout addresses will still use traditional key generation.

Backups of HD wallets, regardless of when they have been created, can therefore be used to re-generate all possible Sapling private keys, even the ones which haven't already been generated during the time of the backup. Regular backups are still necessary, however, in order to ensure that transparent and Sprout addresses are not lost.

A future release will support the importing and restoration of HD wallets.

Fix Signing Raw Transactions with Unsynced Offline Nodes

In signrawtransaction we determine the consensus branch ID (which we then later use to construct the transaction) using the chain height. We now also consider the APPROX_RELEASE_HEIGHT , as this is a better estimation than 0 for the height of the chain if we are unsynced. We have also added an additional parameter to signrawtransaction to allow manually overriding the consensus branch ID that zcashd determines we are on.

Summary of the Changes Included in this Release

1. Allow minimum-difficulty blocks on testnet (#3559)
2. Enable Sapling features on mainnet (#3537)
3. Use ZIP 32 for all Sapling spending keys (#3492)
4. Fix signing raw transaction with unsynced offline node (#3520)
5. Sapling support for persisting wallet to disk (#3517)
6. Add Sapling RPC support to z_shieldcoinbase (#3518)
7. Add Sapling RPC support to z_listunspent (#3510)
8. Add Sapling RPC support to z_listreceivedbyaddress (#3499)
9. Add Sapling RPC support to z_importwallet and z_exportwallet (#3491)
10. Add Sapling RPC support to z_sendmany (#3489)
11. Add Sapling RPC support to z_getbalance and z_gettotalbalance (#3436)
12. Track Sapling notes and nullifiers in the wallet (in-memory only, no persistence to disk) (#3422)
13. Make NU peer management logic upgrade-agnostic (#3512)
14. Generate an ovk to encrypt outCiphertext for Sapling t-addr senders (#3516)
15. Windows cross-compile support (#3172)

For a more complete list of changes, please see the 2.0.1 milestone.

For information on specific Sapling RPC parameter changes, please see the Network Upgrade Developer guide on using zcashd unmodified .

Zcash 2.0.0

This release is the first Sapling-compatible version of the Zcash node software!

Sapling Activation

Mainnet

This release is consensus-compatible with the Sapling network upgrade, and so we’re encouraging all users and miners to upgrade as soon as possible. The first block of Sapling will be block 419200, which is expected to be mined on the 28th of October 2018, the second anniversary of Zcash’s official launch. You can read more about the Sapling network upgrade here or on the Sapling Network Upgrade page.

Testnet

Sapling will activate on the testnet at block 280000, which is expected about a week after this release. Sapling had previously activated on testnet, but because changes were made to the consensus rules your node will automatically roll back and proceed on the Overwinter testnet branch until Sapling activates again at the new height.

Other Notable Changes

Experimental Sapling RPC Support

This release contains only experimental support for Sapling RPC functionality. Full support for Sapling RPC functionality will appear in the 2.0.1 release.

Developers must specify -experimentalfeatures and -developersapling to use the existing functionality on testnet after activation. Alternatively, developers can use these features in regtest mode.

Fix Peer Banning Bug Introduced In Overwinter

After Overwinter activation, nodes syncing from a block height prior to the activation height (347500) experienced slow syncing due to a peer banning mechanism that was introduced to mitigate against a class of DoS attacks from Sprout nodes. This fix replaces the use of peer banning with behavior to ignore invalid transactions.

Summary of the Changes Included in this Release

1. Set the Sapling activation height for mainnet and testnet. (#3469)
2. Adopted the official Sapling system parameters. (#3448)
3. Added support for rollbacks of testnet. (#3443)
4. Added experimental wallet support for Sapling z-addresses. (#3273, #3353, #3392, #3429, #3396, #3458)
5. Added experimental support for building Sapling transactions. (#3417)
6. Added experimental support for Sapling note encryption and decryption. (#3324, #3391)
7. Accept the transaction expiry height as a parameter to RPC call createrawtransaction. (#3336)
8. Prepared the codebase for ZIP 32 integration, including bumping the Rust compiler version to 1.28. (#3447)
9. Begin checking the zk-SNARK parameter hash when loaded into memory. (#3441)
10. Always record the best Sapling anchor on disk even if it is for the empty tree, because rollbacks may occur. (#3463)
11. Fixed a bug where nodes may ban peers during synchronization before network upgrade activation. (#3410)
12. Backport upstream improvements to InitialBlockDownload. (#3263)
13. Update the mainnet checkpoints to improve the speed of initial synchronization. (#3246)

For a more complete list of changes, see the 2.0.0 milestone.

Zcash 1.1.2

Hot on the heels of Zcon0 comes a new release of the Zcash node software (Overwinter-compatible). This release focused on implementing internal changes necessary for Sapling, with development progressing in tandem with the librustzcash and sapling-crypto libraries.

Developer tips for Overwinter network upgrade

Overwinter activated successfully at block 347500 with most of the ecosystem upgrading smoothly. Some common issues we helped third parties with both before and after activation, were:

1. When using an offline node to sign raw transactions, the offline node needs to be synced past the Overwinter activation block height, so that the correct consensus branch id is used.

2. With the new Overwinter signature hashing scheme, when passing in the prevtxs parameter to signrawtransaction, the amount field must be specified. Previously this was not mandatory.

3. When developing custom code to perform the Overwinter signature hashing scheme, a common issue has been mixing up the endianness of fields.

See our previous blog post and the Overwinter Network Upgrade page for more information.

Other notable changes

Removal of option -disabledeprecation

In release 1.0.9 we implemented end-of-support (EOS) halt for zcashd software
versions made by the Zcash Company. The configuration option
-disabledeprecation was added as a way for users to specifically choose to
stay on a particular software version. However, it incorrectly implied that
deprecated releases would still be supported.

This release removes the -disabledeprecation option, so that zcashd software
versions made by the Zcash Company will always shut down in accordance with the
defined EOS policy (currently 16 weeks after release). Users who wish to
use a different policy must now specifically choose to either:

• edit and compile the source code themselves, or
• obtain a software version from someone else who has done so (and obtain
  support from them).

Either way, it is much clearer that the software they are running is not
supported by the Zcash Company.

Summary of the changes included in this release

1. Removed configuration option for turning off EOS halt, previously known as auto-senescence. (#3137)
2. Data field hashFinalSaplingRoot has been added to RPC call getblocktemplate. (#3299)
3. Data field finalsaplingroot has been added to RPC calls getblockheader and getblock. (#3337)
4. We added encodings for Sapling addresses. (#3326)
5. We added a class for Sapling notes. (#3272)
6. We created tests for Sapling anchors. (#3258)
7. Test vectors were created for components of Sapling keys. (#3332)
8. The help message of RPC call signmessage has been clarified. (#3259)
9. Some tests were updated with fixes. (#3303, #3320).
10. We performed some refactoring for code clean up. (#3237, #3321, #3322)

For a more complete list of changes, see our 1.1.2 milestone.

Zcash 1.1.1

This release is an Overwinter-compatible version of the Zcash node software, with initial support for Sapling consensus rules and a Sapling testnet activation height set to block 252500.

Overwinter network upgrade

The first block of Overwinter will be block 347500, which is expected to be mined on the 25th of June 2018. Please upgrade to this release, or any release from v1.1.0 onwards, in order to follow the Overwinter network upgrade. See our previous blog post and the Overwinter Network Upgrade page for more information.

Developers preparing for Sapling

Sapling network upgrade

The consensus code preparations for the Sapling network upgrade, as described
in ZIP 243 and the
Sapling spec
are finished and included in this release. Sapling support in the wallet and
RPC is ongoing, and is expected to land in master over the next few weeks.

The Sapling MPC is currently
working on producing the final Sapling parameters. In the meantime, Sapling will
activate on testnet with dummy Sapling parameters at height 252500. This
activation will be temporary, and the testnet will be rolled back by version
2.0.0 so that both mainnet and testnet will be using the same parameters.
Users who want to continue testing Overwinter should continue to run version
1.1.0 on testnet, and then upgrade to 2.0.0 (which will be released after
Overwinter activates).

Sapling can also be activated at a specific height in regtest mode by
setting the config options -nuparams=5ba81b19:HEIGHT -nuparams=76b809bb:HEIGHT.
These config options will change when the testnet is rolled back for 2.0.0
(because the branch ID for Sapling will change, due to us following the safe
upgrade conventions we introduced in Overwinter).

Users running testnet or regtest nodes will need to run
./zcutil/fetch-params.sh --testnet (for users building from source) or
zcash-fetch-params --testnet (for binary / Debian users).

As a reminder, because the Sapling activation height is not yet specified for
mainnet, version 1.1.1 will behave similarly as other pre-Sapling releases even
after a future activation of Sapling on the network. Upgrading from 1.1.1 will
be required in order to follow the Sapling network upgrade on mainnet.

Sapling transaction format

Once Sapling has activated, transactions must use the new v4 format (including
coinbase transactions). All RPC methods that create new transactions (such as
createrawtransaction and getblocktemplate) will create v4 transactions once
the Sapling activation height has been reached.

Other notable changes

zcash-cli: arguments privacy

The RPC command line client gained a new argument, -stdin
to read extra arguments from standard input, one per line until EOF/Ctrl-D.
For example:

$ src/zcash-cli -stdin z_importkey
mysecretzkey
yes
200000
^D (Ctrl-D)

It is recommended to use this for sensitive information such as private keys, as
command-line arguments can usually be read from the process table by any user on
the system.

Asm representations of scriptSig signatures now contain SIGHASH type decodes

The asm property of each scriptSig now contains the decoded signature hash
type for each signature that provides a valid defined hash type.

The following items contain assembly representations of scriptSig signatures
and are affected by this change:

• RPC getrawtransaction
• RPC decoderawtransaction
• REST /rest/tx/ (JSON format)
• REST /rest/block/ (JSON format when including extended tx details)
• zcash-tx -json

For example, the scriptSig.asm property of a transaction input that
previously showed an assembly representation of:

304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001

now shows as:

304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL]

Note that the output of the RPC decodescript did not change because it is
configured specifically to process scriptPubKey and not scriptSig scripts.

Summary of the changes included in this release

1. We set the Sapling testnet activation height to block 252500. (#3305)
2. We removed the 100kB transaction size limit from Sapling activation. (#3212)
3. We implemented Sapling consensus rules. (#3207, #3220, #3232, #3255, #3275)
4. We implemented Sapling merkle tree, nullifiers and added supported for v4 transactions and loading Sapling parameters. (#3170, #3191, #3197, #3169, #3185)
5. We implemented ZIP 243 for Sapling signature hashing. (#3233)
6. We updated support for Sprout shielded transactions to use the Groth16 proving system when Sapling activates (#3251)
7. We backported transparent address refactors, and are in the process of adding support for Sapling keys, addresses and notes. (#3206, #3234, #3123, #3228, #3202, #3242)
8. We extended a mempool eviction RPC test to cover Sapling activation. (#3074)
9. We backported improvements to RPC call getblock. (#3179)
10. We updated the Payment API documentation. (#3264)
11. We resolved Least Authority auditor issues C, D and E. (#3160, #3181, #3183)
12. We updated the build process to use Rust 1.26 stable. (#3271)
13. We fixed bugs on several unsupported platforms. (#2784, #3153, #3227)
14. We extended Sprout tests to other epochs. (#3157)
15. We backported improvements to zcash-cli, serialization, out-of-memory error reporting and the configuration option uacomment. (#3086, #3180, #3193, #2813)

For a more complete list of changes, see our 1.1.1 milestone.

Zcash 1.1.0

This release is the first Overwinter-compatible version of the Zcash node software! It also includes various bug fixes, improvements for the z_mergetoaddress RPC method, and the NODE_BLOOM service bit.

Overwinter network upgrade

The first block of Overwinter will be block 347500, which is expected to be mined on the 25th of June 2018, just before noon EDT / 16:00 UTC. Please upgrade to this release, or any subsequent release, in order to follow the Overwinter network upgrade. See our previous blog post and the Overwinter Network Upgrade page for more information.

Other notable changes

-mempooltxinputlimit deprecation

The configuration option -mempooltxinputlimit was added in release 1.0.10 as a short-term fix for the quadratic hashing problem inherited from Bitcoin. At the time, transactions with many inputs were causing performance issues for miners. Since then, several performance improvements have been merged from the Bitcoin Core codebase that significantly reduce these issues.

The Overwinter network upgrade includes changes that solve the quadratic hashing problem. As a result, -mempooltxinputlimit will no longer be needed. A transaction with 1000 inputs will take just as long to validate as 10 transactions with 100 inputs each. Starting from this release, -mempooltxinputlimit will be enforced before the Overwinter activation height is reached, but will be ignored once Overwinter activates. The option will be removed entirely in a future release after Overwinter has activated.

NODE_BLOOM service bit

Support for the NODE_BLOOM service bit, as described in BIP 111, has been added to the P2P protocol code.

BIP 111 defines a service bit to allow peers to advertise that they support Bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol version to allow peers to identify old nodes which allow Bloom filtering of the connection despite lacking the new service bit.

In this version, it is only enforced for peers that send protocol versions >=170004. For the next major version it is planned that this restriction will be removed. It is recommended to update SPV clients to check for the NODE_BLOOM service bit for nodes that report version 170004 or newer.

Summary of the changes included in this release

1. We set the Overwinter mainnet activation height. (#3165)
2. We deprecated -mempooltxinputlimit. (#3098)
3. We pulled in support for the NODE_BLOOM service bit. (#2814)
4. We fixed a bug in the block index rewinding code added in 1.0.15. (#3132, #3166)
5. We fixed a bug in z_mergetoaddress when running it several times in parallel. (#3106)
6. We fixed a bug where mainnet auto-senescence heights were applied to testnet and regtest. (#3069)
7. We fixed bugs on several unsupported platforms. (#2820, #2965, #3089, #3117)
8. We made Rust compilation mandatory. (#3127)
9. We added support for Rust crates to the depends system. (#3096)
10. We upgraded OpenSSL to 1.1.0h. (#3130)
11. We improved the error message for "absurdly high fees". (#3111)
12. We added logging of expired transactions. (#3090)

For a more complete list of changes, see our 1.1.0 milestone.

Zcash 1.0.15

This release contains the Overwinter consensus rules with a testnet activation height. It also includes various bug fixes, and adds an experimental RPC method for merging UTXOs and notes.

Notable changes

Overwinter network upgrade

The code preparations for the Overwinter network upgrade, as described in ZIP 200, ZIP 201, ZIP 202, ZIP 203, and ZIP 143 are finished and included in this release. Overwinter will activate on testnet at height 207500, and can also be activated at a specific height in regtest mode by setting the config option -nuparams=5ba81b19:HEIGHT.

However, because the Overwinter activation height is not yet specified for mainnet, version 1.0.15 will behave similarly as other pre-Overwinter releases even after a future activation of Overwinter on the network. Upgrading from 1.0.15 will be required in order to follow the Overwinter network upgrade on mainnet.

Overwinter transaction format

Once Overwinter has activated, transactions must use the new v3 format (including coinbase transactions). All RPC methods that create new transactions (such as createrawtransaction and getblocktemplate) will create v3 transactions once the Overwinter activation height has been reached.

Overwinter transaction expiry

Overwinter transactions created by zcashd will also have a default expiry height set (the block height after which the transaction becomes invalid) of 20 blocks after the height of the next block. This can be configured with the config option -txexpirydelta.

UTXO and note merging

In order to simplify the process of combining many small UTXOs and notes into a few larger ones, a new RPC method z_mergetoaddress has been added as an experimental feature. It merges funds from t-addresses, z-addresses, or both, and sends them to a single t-address or z-address. To test it out, set the config option -zmergetoaddress (as well as enabling experimental features). We encourage mining pools and exchanges to test it out over the next few weeks, and give feedback, before we make it a fully-supported RPC method in an upcoming release.

Unlike most other RPC methods, z_mergetoaddress operates over a particular quantity of UTXOs and notes, instead of a particular amount of ZEC. By default, it will merge 50 UTXOs and 10 notes at a time; these limits can be adjusted with the parameters transparent_limit and shielded_limit.

z_mergetoaddress also returns the number of UTXOs and notes remaining in the given addresses, which can be used to automate the merging process (for example, merging until the number of UTXOs falls below some value).

UTXO memory accounting

The default -dbcache has been changed in this release to 450MiB. Users can set -dbcache to a higher value (e.g. to keep the UTXO set more fully cached in memory). Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter.

Additional information relating to running on low-memory systems can be found here: reducing-memory-usage.md.

Summary of the changes included in this release

• We implemented the Overwinter network upgrade consensus rules and transaction version. (#2874, #2898, #2903, #2925, #3002)
• We added logic to the mempool to evict transactions that can't be mined into the current branch. (#2940)
• We added logic to preferentially evict pre-Overwinter nodes shortly before activation, and disconnect from them after activation. (#2919)
• We added information about network upgrades and version deprecation to the RPC interface. (#2808, #2839)
• We fixed a bug where a block index field was not being read from disk. (#2931, #2977, #2993)
• We implemented a roll-back limit for reorganization and branch rewinding of 100 blocks. (#2463)
• We added z_mergetoaddress as an experimental feature. (#2797)
• We increased the default value of -dbcache. (#2873)

Zcash 1.0.14

This release contains new features, bug fixes, and documentation improvements.

Notable changes

Incoming viewing keys

Support for incoming viewing keys, as described in the Zcash protocol spec, has been added to the wallet.

Use the z_exportviewingkey RPC method to obtain the incoming viewing key for a z-address in a node's wallet. For Sprout z-addresses, these always begin with "ZiVK" (or "ZiVt" for testnet z-addresses). Use z_importviewingkey to import these into another node.

A node that possesses an incoming viewing key for a z-address can view all past transactions received by that address, as well as all future transactions sent to it, by using z_listreceivedbyaddress. They cannot spend any funds from the address. This is similar to the behaviour of "watch-only" t-addresses.

z_gettotalbalance now has an additional boolean parameter for including the balance of "watch-only" addresses (both transparent and shielded), which is set to false by default. z_getbalance has also been updated to work with watch-only addresses.

• Caution: for z-addresses, these balances will not be accurate if any funds have been sent from the address. This is because incoming viewing keys cannot detect spends, and so the "balance" is just the sum of all received notes, including ones that have been spent. Some future use-cases for incoming viewing keys will include synchronization data to keep their balances accurate (e.g. #2542).

Sprout circuit value tracking

Nodes can now track the total amount of shielded ZEC inside the Sprout circuit. This is measured by adding up the ZEC moving between the Transparent Value Pool and JoinSplits (see Anatomy of a Zcash Transaction). getblockchaininfo shows the total for the entire chain, while getblock will show the total as of a specific block.

To enable this monitoring on a specific node, it must be re-indexed. This will take several hours to complete, but otherwise will not affect any other node data.

Summary of the changes included in this release

1. We fixed a non-exploitable buffer overflow in libsnark. (#2800)
2. We added support for incoming viewing keys. (#2143)
3. We added tracking of the total shielded value inside the Sprout circuit, which can be enabled by re-indexing. (#2795)
4. We modified dumpwallet and z_exportwallet to prevent them overwriting existing files. (#2741)
5. We fixed bugs on several unsupported platforms. (#2700, #2752, #2786)
6. We improved various parts of the help text and documentation. (#2724, #2744)

For a more complete list of changes, see our 1.0.14 milestone.

Zcash 1.0.13

This release introduces new features, performance improvements and bug fixes. Our new low memory prover reduces memory usage by 43% when generating a shielded transaction, from 3 GB to 1.7 GB. An experimental feature, payment disclosure, can help services better manage their shielded payments. We also now fully support the z_shieldcoinbase RPC call to help miners sweep up and shield their coinbase rewards.

Summary of the changes included in this release:

1. Auto-senescence cycle has been reduced from 18 to 16 weeks. (#2733)
2. Low-memory prover reduces JoinSplit creation memory usage from 3 GB to 1.7GB. (#2670, stats)
3. Payment disclosure has been added as an experimental feature with new RPC calls z_getpaymentdisclosure and z_validatepaymentdisclosure (#2519). This feature enables a sender to prove that a payment was made to a recipient, which can help services better manage their shielded payments. See the documentation for a full explanation of this new feature.
4. z_shieldcoinbase is now a fully supported RPC call (#2692). See an explanation of this command here.
5. Libsnark has been brought into the source repository tree. (#2652)
6. Fixed potential shutdown errors have been fixed. (#2555)
7. User interface messages have been cleaned up. (#2548, #2150, #2649)
8. The extended QA tests have been migrated to Zcash. (#2533)
9. A workaround has been implemented in the test wallet_protectcoinbase, which was previously failing on some platforms. (#2698)
10. Benchmarking has been updated with new performance measurements and fixes. (#2645, #2659, #2377, #2687, #2665)

For a more complete list of changes, see our 1.0.13 milestone.

Zcash 1.0.12

This release includes bug fixes and usability improvements. It also adds a new RPC method z_shieldcoinbase as an experimental feature, for easily shielding coinbase UTXOs. We encourage mining pools and exchanges to test it out over the next few weeks, and give feedback, before we make it a fully-supported RPC method in an upcoming release.

Summary of the changes included in this release:

1. We added z_shieldcoinbase as an experimental feature. (#2615)
2. We changed the importprivkey RPC method to return the public address corresponding to the imported key. (#2616)
3. We fixed build issues encountered when using GCC 7. (#2545)
4. We added support for fetching the public network parameters from IPFS. (#2597)

For a more complete list of changes, see our 1.0.12 milestone.

Zcash 1.0.11

This release includes bug fixes and usability improvements.

Summary of the changes included in this release:

1. We fixed a 401 Unauthorized bug encountered when using some JSON-RPC libraries. (#2529)
2. We changed z_sendmany to fail with an error if the user sets minconf=0 when sending from z-addresses. (#2525, #2526)
3. We extended the listunspent RPC method to specify whether outputs were from a coinbase transaction, to help users identify t-addresses that need to have their contents shielded. (#2522)
4. We added a block download progress indicator to the metrics UI. (#2484)
5. We removed UPnP support (which was already off by default) for security reasons. (#2504)

For a more complete list of changes, see our 1.0.11 milestone.