v5.9.0

Notable changes

License documentation has been updated to account for the orchard crate now being licensed under "MIT OR Apache-2.0".

Platform Support

• Debian 11 (Bookworm) is now a Tier 1 platform.

• Intel macOS will be formally downgraded to a Tier 3 platform in the next release. Previously it has informally been at both Tier 1 (because builds and tests were run in CI) and Tier 3 (because no packages were provided). However, we are currently unable to update the Clang and Rust compilers due to there being no Clang release built for Intel macOS from LLVM 16 onwards. Combined with the fact that the Intel Macbook was discontinued in 2021, this decision means that we will no longer be building zcashd natively on Intel macOS in CI for testing purposes. We will not be removing build system support (so builds may still function, and community patches to fix issues are welcomed).

v5.8.0

This is a maintenance release that updates dependencies and sets a new end-of-service height to help ensure continuity of services.

v5.7.0

Notable changes

Deprecation of fetch-params.sh

The fetch-params.sh script (also zcash-fetch-params) is now deprecated. The zcashd binary now bundles zk-SNARK parameters directly and so parameters do not need to be downloaded or stored separately. The script will now do nothing but state that it is deprecated; it will be removed in a future release.

Previously, parameters were stored by default in these locations:

• ~/.zcash-params (on Linux); or
• ~/Library/Application Support/ZcashParams (on Mac); or
• C:\Users\Username\AppData\Roaming\ZcashParams (on Windows)

Unless you need to generate transactions using the deprecated Sprout shielded pool, you can delete the parameter files stored in these directories to save space as they are no longer read or used by zcashd. If you do wish to use the Sprout pool, you will need the sprout-groth16.params file in the aforementioned directory. This file is currently available for download here.

Mempool metrics

zcashd now reports the following new metrics when -prometheusport is set:

• (gauge) zcash.mempool.actions.unpaid { "bk" = ["< 0.2", "< 0.4", "< 0.6", "< 0.8", "< 1"] }
• (gauge) zcash.mempool.actions.paid
• (gauge) zcash.mempool.size.weighted { "bk" = ["< 1", "1", "> 1", "> 2", "> 3"] }

The zcash.mempool.actions metrics count the number of logical actions across the transactions in the mempool, while zcash.mempool.size.weighted is a weight-bucketed version of the zcash.mempool.size.bytes metric.

The ZIP 317 weight ratio of a transaction is used to bucket its logical actions and byte size. A weight ratio of at least 1 means that the transaction's fee is at least the ZIP 317 conventional fee, and all of its logical actions are considered "paid". A weight ratio lower than 1 corresponds to the fraction of the transaction's logical actions that are "paid". The remaining fraction (i.e. 1 - weight ratio) are subject to the unpaid action limit that miners configure for their blocks with -blockunpaidactionlimit.

Zcashd hotfix release v5.6.1

Notable changes

Fixes

Fixes an issue introduced in v5.6.0 that could cause loss of data from the
wallet's Orchard note commitment tree. Users upgrading directly from v5.5.0
should upgrade directly to v5.6.1. Wallets that were previously upgraded to
v5.6.0 whose wallets contained unspent Orchard notes at the time of the upgrade
will be automatically re-scanned on startup to repair the corrupted note
commitment tree.

Also, the height parameter to the getblocksubsidy RPC call had accidentally
been made required instead of optional as part of the v5.5.0 upgrade. This
hotfix restores height to being treated as an optional parameter.

v5.6.0

Change to Transaction Relay Policy

Transactions paying less than the ZIP 317 conventional fee to the extent that they have more than -txunpaidactionlimit unpaid actions (default: 50) will not be accepted to the mempool or relayed. For the default values of -txunpaidactionlimit and -blockunpaidactionlimit, these transactions would never be mined by the ZIP 317 block construction algorithm. (If the transaction has been prioritised by prioritisetransaction, the modified fee is used to calculate the number of unpaid actions.)

Removal of Fee Estimation

The estimatefee RPC call, which estimated the fee needed for a transaction to be included within a target number of blocks, has been removed. The fee that should be paid under normal circumstances is the ZIP 317 conventional fee; it is not possible to compute that without knowing the number of logical actions in a transaction, which was not an input to estimatefee. The fee_estimates.dat file is no longer used.

RPC Changes

A new RPC method, z_getsubtreesbyindex, has been added to the RPC interface. This method is only enabled when running with the -experimentalfeatures=1 and -lightwalletd=1 node configuration options. This method makes available to the caller precomputed node values within the Sapling and Orchard note commitment trees. Wallets can make use of these precomputed values to make their existing notes spendable without needing to fully scan the sub-trees whose roots correspond to the returned node values.

In conjunction with this change, the getblock RPC method now returns an additional trees field as part of its result. The value for this field is an object that contains the final sizes of the Sapling and Orchard note commitment trees after the block's note commitments have been appended to their respective trees.

Error reporting has also been improved for a number of RPC methods.

Privacy Policy Changes

The AllowRevealedSenders privacy policy no longer allows sending from multiple taddrs in the same transaction. This now requires AllowLinkingAccountAddresses. Care should be taken in using AllowLinkingAccountAddresses too broadly, as it can also result in linking UAs when transparent funds are sent from them. The practical effect is that an explicit privacy policy is always required for z_mergetoaddress, z_sendmany, and z_shieldcoinbase when sending from multiple taddrs, even when using wildcards like * and ANY_TADDR.

Wallet Updates

A number of libraries that zcashd relies upon have been updated as part of this release, including some changes that result in updates to wallet serialization formats for Orchard note commitment tree data. As always, it is recommended that users back up their wallets prior to upgrading to a new release to help guarantee the continued availability of their funds.

Platform Support

• Ubuntu 18.04 LTS has been removed from the list of supported platforms. It reached End of Support on May 31st 2023, and no longer satisfies our Tier 2 policy requirements.

v5.5.1

Fixes an issue that could cause a node to crash if the privacy policy does not include AllowRevealedRecipients when attempting to create a transaction that results in transparent change. See #6662 for details.

Also corrects an underestimate of the ZIP 317 conventional fee when spending UTXOs, which can result in mining of the transaction being delayed or blocked. See #6660 for details.

v5.5.0

Notable changes

RPC Changes

• getdeprecationinfo has several changes:
  • It now returns additional information about currently deprecated and disabled features.
  • A new end_of_service object that contains both the block height for end-of-service and the estimated time that the end-of-service halt is expected to occur. Note that this time is just an approximation and will change over time as the end-of-service block height approaches, due to the variability in block times. The end_of_service object is intended to replace the deprecationheight field; see the Deprecations section for additional detail.
  • This RPC method was previously only available for mainnet nodes; it is now also available for testnet and regtest nodes, in which case it does not return end-of-service halt information (as testnet and regtest nodes do not have an end-of-service halt feature.)
• Several z_sendmany, z_shieldcoinbase and z_mergetoaddress failures have moved from synchronous to asynchronous, so while you should already be checking the async operation status, there are now more cases that may trigger failure at that stage.
• The AllowRevealedRecipients privacy policy is now required in order to choose a transparent change address for a transaction. This will only occur when the wallet is unable to construct the transaction without selecting funds from the transparent pool, so the impact of this change is that for such transactions, the user must specify AllowFullyTransparent.
• The z_shieldcoinbase RPC method now supports an optional memo.
• The z_shieldcoinbase and z_mergetoaddress RPC methods now support an optional privacy policy.
• The z_mergetoaddress RPC method can now merge to UAs and can also send between different shielded pools (when AllowRevealedAmounts is specified).
• The estimatepriority RPC call has been removed.
• The priority_delta argument to the prioritisetransaction RPC call now has no effect and must be set to a dummy value (0 or null).

Changes to Transaction Fee Selection

• The zcashd wallet now uses the conventional transaction fee calculated according to ZIP 317 by default. This conventional fee will be used unless a fee is explicitly specified in an RPC call, or for the wallet's legacy transaction creation APIs (sendtoaddress, sendmany, and fundrawtransaction) when the -paytxfee option is set.
• The -mintxfee and -sendfreetransactions options have been removed. These options previously instructed the legacy transaction creation APIs to increase fees to this limit and to use a zero fee for "small" transactions that spend "old" inputs, respectively. They will now cause a warning on node startup if used.

Changes to Block Template Construction

We now use a new block template construction algorithm documented in ZIP 317.

• This algorithm no longer favours transactions that were previously considered "high priority" because they spent older inputs. The -blockprioritysize config option, which configured the portion of the block reserved for these transactions, has been removed and will now cause a warning if used.
• The -blockminsize option, which configured the size of a portion of the block to be filled regardless of transaction fees or priority, has also been removed and will cause a warning if used.
• A -blockunpaidactionlimit option has been added to control the limit on "unpaid actions" that will be accepted in a block for transactions paying less than the ZIP 317 fee. This defaults to 50.

Change to Transaction Relay Policy

The allowance for "free transactions" in mempool acceptance and relay has been removed. All transactions must pay at least the minimum relay threshold, currently100 zatoshis per 1000 bytes up to a maximum of 1000 zatoshis, in order to be accepted and relayed. (Individual nodes can change this using -minrelaytxfee but in practice the network default needs to be adhered to.) This policy is under review and might be made stricter; if that happens then the ZIP 317 conventional fee will still be sufficient for mempool acceptance and relay.

Removal of Priority Estimation

Estimation of "priority" needed for a transaction to be included within a target number of blocks, and the associated estimatepriority RPC call, have been removed. The format for fee_estimates.dat has also changed to no longer save these priority estimates. It will automatically be converted to the new format which is not readable by prior versions of the software. The -txconfirmtarget config option is now obsolete and has also been removed. It will cause a warning if used.

Deprecations

The following features have been deprecated, but remain available by default. These features may be disabled by setting -allowdeprecated=none. 18 weeks after this release, these features will be disabled by default and the following flags to -allowdeprecated will be required to permit their continued use:

• deprecationinfo_deprecationheight: The deprecationheight field of getdeprecationinfo has been deprecated and replaced by the end_of_service object.

v5.4.2

This hotfix remediates memory exhaustion vulnerabilities that zcashd inherited as a fork of bitcoind. These bugs could allow an attacker to use peer-to-peer messages to fill the memory of a node, resulting in a crash.

v5.3.3

This hotfix remediates memory exhaustion vulnerabilities that zcashd inherited as a fork of bitcoind. These bugs could allow an attacker to use peer-to-peer messages to fill the memory of a node, resulting in a crash.

v5.4.1

Notable changes

allowdeprecated in zcash.conf

In v5.0.0 a feature deprecation framework was released, to enable zcashd features to be formally deprecated and removed:

• In stage 1, a feature is marked as deprecated, but otherwise left as-is. It remains in this stage for at least 18 weeks.
• In stage 2, the feature is default-disabled, but can be re-enabled with the -allowdeprecated config option. It remains in this stage for at least 18 weeks.
• Finally, the feature is removed - either entirely, or (e.g. in the case of RPC methods that were inherited from Bitcoin Core) with a "tombstone" left to inform users of the removal (and what to use instead if applicable).

Config options can be specified either as a zcashd argument (-option=value) or in zcash.conf (as a option=value line). However, due to a bug in the implementation, allowdeprecated=feature lines in zcash.conf were ignored. The bug went unnoticed until v5.4.0, in which the first group of features moved from stage 1 to stage 2. This hotfix release fixes the bug.

Fixed RPC blocking and wallet view lag on reindex

The known issue reported in the v5.4.0 release notes has been fixed.