v4.1.0

Notable changes

Migration to Clang and static libc++

zcashd now builds its C++ (and C) dependencies entirely with a pinned version
of Clang, and statically links libc++ instead of dynamically linking libstdc++.
This migration enables us to reliably use newer C++ features while supporting
older LTS platforms, be more confident in the compiler's optimisations, and
leverage security features such as sanitisers and efficient fuzzing. In future,
this will also allow optimizing across the boundary between Rust and C++.

The system compiler is still used to compile a few native dependencies (used by
the build machine to then compile zcashd for the target machine). These will
likely also be migrated to use the pinned Clang in a future release.

Fast sync for initial block download

The -ibdskiptxverification flag allows faster synchronization during initial
block sync, by skipping transaction verification and instead verifying only PoW.
Note that this mode requires checkpoints to be enabled, to make sure that each
block under inspection is an ancestor of the latest checkpoint.

Convenient testing for invalid note plaintexts

After the mainnet activation of Canopy (block 1046400), correct wallet software
will no longer produce v1 note plaintexts (with a lead byte of 0x01). However,
v1 note plaintexts will continue to be accepted for a grace period of 32256
blocks (about 4 weeks), as specified in ZIP 212.
The new receiveunsafe log category complains if an invalid note plaintext is
received.

Additional lightwalletd and light client RPCs

• lightwalletd is now able to retrieve all UTXOs related to a t-address through
  the getaddressutxos RPC. (Previously, this was only available to the Insight
  Explorer.)
• The new z_gettreestate RPC returns the Sprout and Sapling treestate at a
  given block height or block hash. This makes it easier for light clients to
  generate checkpoints.

Update/removal of several cryptographic dependencies

This release updates secp256k1 to enable the GLV endomorphism optimisation by
default, after the recent expiry of the GLV patents. It also removes OpenSSL,
and replaces libsodium BLAKE2b usage with the blake2b_simd Rust crate.

v4.0.0

Notable changes

The mainnet activation of the Canopy network upgrade is supported by the 4.0.0
release, with an activation height of 1046400, which should occur roughly in the
middle of November — following the targeted EOS halt of our 3.1.0 release.
Please upgrade to this release, or any subsequent release, in order to follow
the Canopy network upgrade.

The following ZIPs are being deployed as part of this upgrade:

• ZIP 207: Funding Streams in conjunction with ZIP 214: Consensus rules for a Zcash Development Fund
• ZIP 211: Disabling Addition of New Value to the Sprout Value Pool
• ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext
• ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules

In order to help the ecosystem prepare for the mainnet activiation, Canopy has
already been activated on the Zcash testnet. Any node version 3.1.0 or higher,
including this release, supports the Canopy activation on testnet.

Disabling new value in the Sprout value pool

After the mainnet activation of Canopy, it will not be possible to send funds to
Sprout z-addresses from any other kind of address, as described in ZIP 211.
It will still be possible to send funds from a Sprout z-address and to send
funds between Sprout addresses. Users of Sprout z-addresses are encouraged to
use Sapling z-addresses instead, and to migrate their remaining Sprout funds
into a Sapling z-address using the migration utility in zcashd: set migrate=1
in your zcash.conf file, or use the z_setmigration RPC.

New logging system

The zcashd logging system is now powered by the Rust tracing crate. This
has two main benefits:

• tracing supports the concept of "spans", which represent periods of time
  with a beginning and end. These enable logging additional information about
  temporality and causality of events. (Regular log lines, which represent
  moments in time, are called events in tracing.)
• Spans and events are structured, and can record typed data in addition to text
  messages. This structure can then be filtered dynamically.

The existing -debug=target config flags are mapped to tracing log filters,
and will continue to correctly enable additional logging when starting zcashd.
A new setlogfilter RPC method has been introduced that enables reconfiguring
the log filter at runtime. See zcash-cli help setlogfilter for its syntax.

As a minor note, zcashd no longer reopens the debug.log file on SIGHUP.
This behaviour was originally introduced in upstream Bitcoin Core to support log
rotation using external tools. tracing supports log rotation internally (which
is currently disabled), as well as a variety of interesting backends (such as
journald and OpenTelemetry integration); we are investigating how these might
be exposed in future releases.

Compatibility

macOS versions earlier than 10.12 (Sierra) are no longer supported.

v3.1.0

Notable changes

Network Upgrade 4: Canopy

The code preparations for the Canopy network upgrade are finished and included in this release. The following ZIPs are being deployed:

• ZIP 207: Funding Streams
• ZIP 211: Disabling Addition of New Value to the Sprout Value Pool
• ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext
• ZIP 214: Consensus rules for a Zcash Development Fund
• ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules

Canopy will activate on testnet at height 1028500, and can also be activated at a specific height in regtest mode by setting the config option -nuparams=0xe9ff75a6:HEIGHT. Note that v3.1.0 enables Canopy support on the testnet.

Canopy will activate on mainnet at height 1046400.

See ZIP 251 for additional information about the deployment process for Canopy.

Debian 8 "Jessie" will no longer be supported after v3.1.0, due to its end-of-life on June 30th, 2020. This will allow us to direct more resources to supporting Debian 10 Buster, other Linux distributions, and other platforms such as Windows and macOS.

Flush witness data to disk only when it's consistent

This fix prevents the wallet database from getting into an inconsistent state. By flushing witness data to disk from the wallet thread instead of the main thread, we ensure that the on-disk block height is always the same as the witness data height. Previously, the database occasionally got into a state where the latest block height was one ahead of the witness data. This then triggered an assertion failure in CWallet::IncrementNoteWitnesses() upon restarting after a zcashd shutdown.

Note that this code change will not automatically repair a data directory that has been affected by this problem; that requires starting zcashd with the -rescan or -reindex options.

New DNS seeders

DNS seeders hosted at "zfnd.org" and "yolo.money" have been added to the list in chainparams.cpp. They're running CoreDNS with a Zcash crawler plugin, the result of a Zcash Foundation in-house development effort to replace zcash-seeder with something memory-safe and easier to maintain.

These are validly operated seeders per the existing policy. For general questions related to either seeder, contact george@zfnd.org or mention @gtank in the Zcash Foundation's Discord. For bug reports, open an issue on the dnsseeder repo.

Changed command-line options

• -debuglogfile=<file> can be used to specify an alternative debug logging file.

RPC methods

• joinSplitPubKey and joinSplitSig have been added to verbose transaction outputs. This enables the transaction's binary form to be fully reconstructed from the RPC output.
• The output of getblockchaininfo now includes an estimatedheight parameter. This can be shown in UIs as an indication of the current chain height while zcashd is syncing, but should not be relied upon when creating transactions.

Metrics screen

• A progress bar is now visible when in Initial Block Download mode, showing both the prefetched headers and validated blocks. It is only printed for TTY output. Additionally, the "not mining" message is no longer shown on mainnet, as the built-in CPU miner is not effective at the current network difficulty.
• The number of block headers prefetched during Initial Block Download is now displayed alongside the number of validated blocks. With current compile-time defaults, a Zcash node prefetches up to 160 block headers per request without a limit on how far it can prefetch, but only up to 16 full blocks at a time.

v3.0.0

The mainnet activation of the Heartwood network upgrade is supported by this
release, with an activation height of 903000, which should occur in the middle
of July — following the targeted EOS halt of our 2.1.2-3 release. Please upgrade
to this release, or any subsequent release, in order to follow the Heartwood
network upgrade.

The following two ZIPs are being deployed as part of this upgrade:

• ZIP 213: Shielded Coinbase
• ZIP 221: FlyClient - Consensus-Layer Changes

In order to help the ecosystem prepare for the mainnet activiation, Heartwood
has already been activated on the Zcash testnet. Any node version 2.1.2 or
higher, including this release, supports the Heartwood activation on testnet.

Mining to Sapling addresses

After the mainnet activation of Heartwood, miners can mine directly into a
Sapling shielded address. Miners should wait until after Heartwood activation
before they make changes to their configuration to leverage this new feature.
After activation of Heartwood, miners can add mineraddress=SAPLING_ADDRESS to
their zcash.conf file, where SAPLING_ADDRESS represents a Sapling address
that can be generated locally with the z_getnewaddress RPC command. Restart
your node, and block templates produced by the getblocktemplate RPC command
will now have coinbase transactions that mine directly into this shielded
address.

v2.1.2-3

This release fixes a crash on testnet that v2.1.2 nodes are likely to experience on startup. This release also allows nodes that did not follow the testnet activation of Heartwood to properly roll back and follow the Heartwood activation on testnet.

In addition, we have ensured that this release’s end-of-service halt is in the middle of July, just prior to our anticipated activation of Heartwood on mainnet.

We recommend that anyone testing their integration with Heartwood should upgrade to this release.

As a reminder, 2.1.2 included the following major changes:

• Support for Sapling viewing keys (specifically, Sapling extended full viewing keys, as described in ZIP 32), has been added to the wallet. Nodes will track both sent and received transactions for any Sapling addresses associated with the imported Sapling viewing keys.

• Removal of time adjustment and the -maxtimeadjustment= option. Prior to v2.1.1-1, zcashd would adjust the local time that it used by up to 70 minutes, according to a median of the times sent by the first 200 peers to connect to it. This mechanism was inherently insecure, since an adversary making multiple connections to the node could effectively control its time within that +/- 70 minute window (this is called a "timejacking attack"). As a simplification the time adjustment code has now been completely removed, together with -maxtimeadjustment=. Node operators should instead ensure that their local time is set reasonably accurately.

• View shielded information in wallet transactions. In previous zcashd versions, there were no RPC methods that directly returned details about spends, or anything equivalent to the gettransaction method (which returns transparent information about in-wallet transactions). This release introduces a new RPC method z_viewtransaction to fill that gap.

• Better error messages for rejected transactions after network upgrades. Starting from this release, zcashd nodes will re-verify invalid transparent and Sprout signatures against the consensus branch ID from before the most recent network upgrade. If the signature then becomes valid, the transaction will be rejected with the error message old-consensus-branch-id. This error can be handled specifically by wallet providers to inform the user that they need to upgrade their wallet software.

• A new config option -txexpirynotify has been added that will cause zcashd to execute a command when a transaction in the mempool expires.

• The z_importkey and z_importviewingkey RPC methods now return the type of the imported spending or viewing key (sprout or sapling), and the corresponding payment address.

• Negative heights are now permitted in getblock and getblockhash, to select blocks backwards from the chain tip. A height of -1 corresponds to the last known valid block on the main chain.

• A new RPC method getexperimentalfeatures returns the list of enabled experimental features.

• The --enable-lcov, --disable-tests, and --disable-mining flags for zcutil/build.sh have been removed. You can pass these flags instead by using the CONFIGURE_FLAGS environment variable. Also, the build system no longer defaults to verbose output.

v2.1.2

Notable changes

Network Upgrade 3: Heartwood

The code preparations for the Heartwood network upgrade are finished and
included in this release. The following ZIPs are being deployed:

• ZIP 213: Shielded Coinbase
• ZIP 221: FlyClient - Consensus-Layer Changes

Heartwood will activate on testnet at height 903800, and can also be activated
at a specific height in regtest mode by setting the config option
-nuparams=f5b9230b:HEIGHT.

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

See ZIP 250 for additional information about the
deployment process for Heartwood.

Mining to Sapling addresses

Miners and mining pools that wish to test the new "shielded coinbase" support on
the Heartwood testnet can generate a new Sapling address with z_getnewaddress,
add the config option mineraddress=SAPLING_ADDRESS to their zcash.conf file,
and then restart their zcashd node. getblocktemplate will then return
coinbase transactions containing a shielded miner output.

Note that mineraddress should only be set to a Sapling address after the
Heartwood network upgrade has activated; setting a Sapling address prior to
Heartwood activation will cause getblocktemplate to return block templates
that cannot be mined.

Sapling viewing keys support

Support for Sapling viewing keys (specifically, Sapling extended full viewing
keys, as described in ZIP 32), has been added to
the wallet. Nodes will track both sent and received transactions for any Sapling
addresses associated with the imported Sapling viewing keys.

• Use the z_exportviewingkey RPC method to obtain the viewing key for a
  shielded address in a node's wallet. For Sapling addresses, these always begin
  with "zxviews" (or "zxviewtestsapling" for testnet addresses).

• Use z_importviewingkey to import a viewing key into another node. Imported
  Sapling viewing keys will be stored in the wallet, and remembered across
  restarts.

• z_getbalance will show the balance of a Sapling address associated with an
  imported Sapling viewing key. Balances for Sapling viewing keys will be
  included in the output of z_gettotalbalance when the includeWatchonly
  parameter is set to true.

• RPC methods for viewing shielded transaction information (such as
  z_listreceivedbyaddress) will return information for Sapling addresses
  associated with imported Sapling viewing keys.

Details about what information can be viewed with these Sapling viewing keys,
and what guarantees you have about that information, can be found in
ZIP 310.

Removal of time adjustment and the -maxtimeadjustment= option

Prior to v2.1.1-1, zcashd would adjust the local time that it used by up
to 70 minutes, according to a median of the times sent by the first 200 peers
to connect to it. This mechanism was inherently insecure, since an adversary
making multiple connections to the node could effectively control its time
within that +/- 70 minute window (this is called a "timejacking attack").

In the v2.1.1-1 security release, in addition to other mitigations for
timejacking attacks, the maximum time adjustment was set to zero by default.
This effectively disabled time adjustment; however, a -maxtimeadjustment=
option was provided to override this default.

As a simplification the time adjustment code has now been completely removed,
together with -maxtimeadjustment=. Node operators should instead ensure that
their local time is set reasonably accurately.

If it appears that the node has a significantly different time than its peers,
a warning will still be logged and indicated on the metrics screen if enabled.

View shielded information in wallet transactions

In previous zcashd versions, to obtain information about shielded transactions
you would use either the z_listreceivedbyaddress RPC method (which returns all
notes received by an address) or z_listunspent (which returns unspent notes,
optionally filtered by addresses). There were no RPC methods that directly
returned details about spends, or anything equivalent to the gettransaction
method (which returns transparent information about in-wallet transactions).

This release introduces a new RPC method z_viewtransaction to fill that gap.
Given the ID of a transaction in the wallet, it decrypts the transaction and
returns detailed shielded information for all decryptable new and spent notes,
including:

• The address that each note belongs to.
• Values in both decimal ZEC/TAZ and zatoshis.
• The ID of the transaction that each spent note was received in.
• An outgoing flag on each new note, which will be true if the output is not
  for an address in the wallet.
• A memoStr field for each new note, containing its text memo (if its memo
  field contains a valid UTF-8 string).

Information will be shown for any address that appears in z_listaddresses;
this includes watch-only addresses linked to viewing keys imported with
z_importviewingkey, as well as addresses with spending keys (both generated
with z_getnewaddress and imported with z_importkey).

Better error messages for rejected transactions after network upgrades

The Zcash network upgrade process includes several features designed to protect users. One of these is the "consensus branch ID", which prevents transactions created after a network upgrade has activated from being replayed on another chain (that might have occurred due to, for example, a friendly fork). This is known as "two-way replay protection", and is a core requirement by various members of the cryptocurrency ecosystem for supporting "hard fork"-style changes like our network upgrades.

One downside of the way replay protection is implemented in Zcash, is that there is no visible difference between a transaction being rejected by a zcashd node due to targeting a different branch, and being rejected due to an invalid signature. This has caused issues in the past when a user had not upgraded their wallet software, or when a wallet lacked support for the new network upgrade's consensus branch ID; the resulting error messages when users tried to create transactions were non-intuitive, and particularly cryptic for transparent transactions.

Starting from this release, zcashd nodes will re-verify invalid transparent and Sprout signatures against the consensus branch ID from before the most recent network upgrade. If the signature then becomes valid, the transaction will be rejected with the error message old-consensus-branch-id. This error can be handled specifically by wallet providers to inform the user that they need to upgrade their wallet software.

Wallet software can also automatically obtain the latest consensus branch ID from their (up-to-date) zcashd node, by calling getblockchaininfo and looking at {'consensus': {'nextblock': BRANCH_ID, ...}, ...} in the JSON
output.

Expired transactions notifications

A new config option -txexpirynotify has been added that will cause zcashd to
execute a command when a transaction in the mempool expires. This can be used to
notify external systems about transaction expiry, similar to the existing
-blocknotify config option that notifies when the chain tip changes.

RPC methods

• The z_importkey and z_importviewingkey RPC methods now return the type of
  the imported spending or viewing key (sprout or sapling), and the
  corresponding payment address.

• Negative heights are now permitted in getblock and getblockhash, to select
  blocks backwards from the chain tip. A height of -1 corresponds to the last
  known valid block on the main chain.

• A new RPC method getexperimentalfeatures returns the list of enabled
  experimental features.

Build system

• The --enable-lcov, --disable-tests, and --disable-mining flags for
  zcutil/build.sh have been removed. You can pass these flags instead by using
  the CONFIGURE_FLAGS environment variable. For example, to enable coverage
  instrumentation (thus enabling "make cov" to work), call:

  CONFIGURE_FLAGS="--enable-lcov --disable-hardening" ./zcutil/build.sh
  

• The build system no longer defaults to verbose output. You can re-enable
  verbose output with ./zcutil/build.sh V=1

v2.1.1-1

This release fixes a security issue described at
https://z.cash/support/security/announcements/security-announcement-2020-02-06/ .

This release also adds a -maxtimeadjustment option to set the maximum time, in
seconds, by which the node's clock can be adjusted based on the clocks of its
peer nodes. This option defaults to 0, meaning that no such adjustment is performed.
This is a change from the previous behaviour, which was to adjust the clock by up
to 70 minutes forward or backward. The maximum setting for this option is now
25 minutes (1500 seconds).

Fix for incorrect banning of nodes during syncing

After activation of the Blossom network upgrade, a node that is syncing the
block chain from before Blossom would incorrectly ban peers that send it a
Blossom transaction. This resulted in slower and less reliable syncing (#4283).

v2.1.1

Notable changes

z_mergetoaddress promoted out of experimental status

The z_mergetoaddress API merges funds from t-addresses, z-addresses, or both,
and sends them to a single t-address or z-address. It was added in v1.0.15 as an
experimental feature, to simplify the process of combining many small UTXOs and
notes into a few larger ones.

In this release we are promoting z_mergetoaddress out of experimental status.
It is now a stable RPC, and any future changes to it will only be additive. See
zcash-cli help z_mergetoaddress for API details and usage.

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).

Option parsing behavior

Command line options are now parsed strictly in the order in which they are
specified. It used to be the case that -X -noX ends up, unintuitively, with X
set, as -X had precedence over -noX. This is no longer the case. Like for
other software, the last specified value for an option will hold.

Low-level RPC changes

• Bare multisig outputs to our keys are no longer automatically treated as
  incoming payments. As this feature was only available for multisig outputs for
  which you had all private keys in your wallet, there was generally no use for
  them compared to single-key schemes. Furthermore, no address format for such
  outputs is defined, and wallet software can't easily send to it. These outputs
  will no longer show up in listtransactions, listunspent, or contribute to
  your balance, unless they are explicitly watched (using importaddress or
  importmulti with hex script argument). signrawtransaction* also still
  works for them.

v2.1.0-1

Electric Coin Co. became aware of the following security announcement on the bitcoin-dev mailing list on 8th November: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017453.html

Upon investigation, the team found that versions of zcashd prior to 2.1.0-1 suffered from the above bug, CVE-2017-18350. Nodes in the affected configuration (with a SOCKS proxy enabled) could be compromised by an attacker executing arbitrary code in the context of the zcashd daemon, allowing them to violate user privacy, steal user funds, or perform other unauthorized actions on the machine. The affected configuration is not the default.

zcashd version 2.1.0-1 contains a fix for this issue, and we recommend updating all affected nodes as soon as possible.

v2.1.0

Blossom network upgrade

The mainnet activation of the Blossom network upgrade is supported by this release, with an activation height of 653600, which should occur in early December — roughly one day following the targeted EOS halt of our 2.0.7-3 release. Please upgrade to this release, or any subsequent release, in order to follow the Blossom network upgrade.

The Blossom network upgrade implements ZIP 208 which shortens block times from 150s to 75s.

DoS Mitigation: Mempool Size Limit and Random Drop

This release adds a mechanism for preventing nodes from running out of memory in the situation where an attacker is trying to overwhelm the network with transactions. This is achieved by keeping track of and limiting the total cost and evictionWeight of all transactions in the mempool. The cost of a transaction is determined by its size in bytes, and its evictionWeight is a function of the transaction's cost and its fee. The maximum total cost is configurable via the parameter mempooltxcostlimit which defaults to 80,000,000 (up to 20,000 txs). If a node's total mempool cost exceeds this limit the node will evict a random transaction, preferentially picking larger transactions and ones with below the standard fee. To prevent a node from re-accepting evicted transactions, it keeps track of ones that it has evicted recently. By default, a transaction will be considered recently evicted for 60 minutes, but this can be configured with the parameter mempoolevictionmemoryminutes.

For full details see ZIP 401.

Asynchronous Operations Incorrectly Reporting Success

We fixed an issue where asynchronous operations were sometimes reporting success when they had actually failed. One way this could occur was when trying to use z_sendmany to create a transaction spending coinbase funds in a way where change would be generated (not a valid use of z_sendmany). In this case the operation would erroneously report success, and the only way to see that the transaction had actually failed was to look in the debug.log file. Such operations will now correctly report that they have failed.

Fake chain detection during initial block download

One of the mechanisms that zcashd uses to detect whether it is in "initial block download" (IBD) mode is to compare the active chain's cumulative work against a hard-coded "minimum chain work" value. This mechanism (inherited from Bitcoin Core) means that once a node exits IBD mode, it is either on the main chain, or a fake alternate chain with similar amounts of work. In the latter case, the node has most likely become the victim of a 50% + 1 adversary.

Starting from this release, zcashd additionally hard-codes the block hashes for the activation blocks of each past network upgrade (NU). During initial chain synchronization, and after the active chain has reached "minimum chain work", the node checks the blocks at each NU activation height against the hard-coded hashes. If any of them do not match, the node will immediately alert the user and shut down for safety.

Disabling old Sprout proofs

As part of our ongoing work to clean up the codebase and minimise the security surface of zcashd, we are removing libsnark from the codebase, and dropping support for creating and verifying old Sprout proofs. Funds stored in Sprout addresses are not affected, as they are spent using the hybrid Sprout circuit (built using bellman) that was deployed during the Sapling network upgrade.

This change has several implications:

• zcashd no longer verifies old Sprout proofs, and will instead assume they are valid. This has a minor implication for nodes: during initial block download, an adversary could feed the node fake blocks containing invalid old Sprout proofs, and the node would accept the fake chain as valid. However, as soon as the active chain contains at least as much work as the hard-coded "minimum chain work" value, the node will detect this situation and shut down.

• Shielded transactions can no longer be created before Sapling has activated. This does not affect Zcash itself, but will affect downstream codebases that have not yet activated Sapling (or that start a new chain after this point and do not activate Sapling from launch). Note that the old Sprout circuit is vulnerable to counterfeiting and should not be used in current deployments.

• Starting from this release, the circuit parameters from the original Sprout MPC are no longer required to start zcashd, and will not be downloaded by fetch-params.sh. They are not being automatically deleted at this time.

We would like to take a moment to thank the libsnark authors and contributors. It was vital to the success of Zcash, and the development of zero-knowledge proofs in general, to have this code available and usable.