v4.6.0-1

getblocktemplate regression fix

We added support for the NU5 consensus rules in v4.5.0, which alters the block header to contain a hashBlockCommitments value instead of the chain history root. However, the output of getblocktemplate wasn't returning this value; once NU5 activated, the blockcommitmentshash field was being set to "null" (all-zeroes).

In v4.6.0 we added full NU5 support to getblocktemplate, by adding a defaultroots field that gave default values for hashBlockCommitments and the components required to derive it. However, in doing so we introduced a regression in the (now-deprecated) legacy fields, where prior to NU5 activation they contained nonsense.

This release fixes the output of getblocktemplate to have the intended semantics for all fields:

• The blockcommitmentshash and authdataroot fields in defaultroots are now omitted from block templates for heights before NU5 activation.
• The legacy fields now always contain the default value to be placed into the block header (regaining their previous semantics).

v4.6.0

Notable changes

Wallet

From this release, newly-created wallets will save the chain name ("Zcash") and network identifier (e.g. "main") to the wallet.dat file. This will enable the zcashd node to check on subsequent starts that the wallet.dat file matches the node's configuration. Existing wallets will start saving this information in a later release.

libzcash_script

Two new APIs have been added to this library (zcash_script_legacy_sigop_count and zcash_script_legacy_sigop_count_precomputed), for counting the number of signature operations in the transparent inputs and outputs of a transaction. The presence of these APIs is indicated by a library API version of 2.

Updated RPCs

• The getblocktemplate RPC method output now includes a defaultroots field, which provides various tree roots and block commitments matching the contents of the block template. If any part of the block template marked as mutable in the RPC method output is mutated, these roots may need to be recomputed. For more information on the derivation process, see the block header changes in ZIP 244.

• Fixed an issue where ERROR: spent index not enabled would be logged unnecessarily on nodes that have either -insightexplorer or -lightwalletd configuration options enabled.

• The getmininginfo RPC now omits currentblocksize and currentblocktx when a block was never assembled via RPC on this node during its current process instantiation. (#5404)

v4.5.1-1

Notable changes

Added v5 transactions to standard rules

In v4.5.0 we added the v5 transaction format to the NU5 consensus rules for testnet. However, it was omitted from the standard rules, which meant that zcashd testnet nodes would not accept v5 transactions into their mempools, causing them to not be propagated or mined. This release updates the zcashd standard rules to accept v5 transactions alongside v4 transactions.

New listaddresses RPC method

The listaddresses endpoint has been added to the RPC API. This method allows the caller to obtain addresses managed by the wallet, grouped by the source of the address, including both those addresses generated by the wallet and those associated with imported viewing or spending keys. This provides functionality that replaces and subsumes the previously removed getaddressesbyaccount method.

v4.5.1

TL;DR: This is a required update for all testnet nodes, and is highly recommended for mainnet nodes if you are using the getbalance RPC method.

If you are running zcashd in Docker, you may need to upgrade Docker to a recent version. Version 19.03.12 is reported to work.

Notable changes

Fixed bugs in the testnet Orchard circuit

In the zcashd v4.5.0 release notes we indicated that a testnet rollback might occur to update the consensus rules, if we needed to make backwards-incompatible changes. Shortly after zcashd v4.5.0 was released, during another internal review of the Orchard circuit, we identified two bugs that would affect the upcoming testnet activation of NU5:

• The diversifier base g_d_old, for the note being spent, is required to be a non-identity point. A note created from a payment address with g_d set to the identity (via collaboration between sender and recipient) could be spent multiple times with different nullifiers (corresponding to different ivks).
  The code outside the circuit correctly enforced the non-identity requirement, but the circuit did not correctly constrain this, and allowed the prover to witness the identity.

• SinsemillaCommit can be modeled as a Pedersen commitment to an output of SinsemillaHash: SinsemillaCommit(r, M) = SinsemillaHashToPoint(M) + [r] R.
  The specification used incomplete addition here, matching its use inside SinsemillaHash. However, unlike in SinsemillaHash, an exceptional case can be produced here when r = 0. The derivations of rivk (for computing ivk) and rcm (for computing the note commitment) normally ensure that r = 0 can only occur with negligible probability, but these derivations are not checked by the circuit for efficiency; thus SinsemillaCommit needs to use complete addition.

These bugs do not affect mainnet, as zcashd v4.5.0 only set the activation height for NU5 on testnet for testing purposes. Nevertheless, in the interest of keeping the testnet environment as close to mainnet as possible, we are fixing these bugs immediately. This means a change to the NU5 consensus rules, and a new testnet activation height for NU5.

To this end, the following changes are made in zcashd v4.5.1:

• The consensus branch ID for NU5 is changed to 0x37519621.
• The protocol version indicating NU5-aware testnet nodes is set to 170015.
• The testnet activation height for NU5 is set to 1,599,200.

Testnet nodes that upgrade to zcashd v4.5.1 prior to block height 1,590,000 will follow the new testnet network upgrade. Testnet nodes that are running zcashd v4.5.0 at that height will need to upgrade to v4.5.1 and then run with -reindex.

As always, it is possible that further backwards incompatible changes might be made to the NU5 consensus rules in this testing phase, prior to setting the mainnet activation height, as we continue to conduct additional internal review. In the event that this happens, testnet will be rolled back in (or prior to) v5.0.0, and a new testnet activation will occur.

Fixed regression in getbalance RPC method

zcashd v4.5.0 removed the account API from the wallet, following its deprecation and removal in upstream Bitcoin Core. As part of the upstream changes, the getbalance RPC method was altered from using two custom balance computation methods, to instead relying on CWallet::GetBalance. This method internally relies on CWalletTx::IsFromMe as part of identifying "trusted" zero-confirmation transactions to include in the balance calculation.

There is an equivalent and closely-named CWallet::IsFromMe method, which is used throughout the wallet, and had been updated before Zcash launched to be aware of spent shielded notes. The change to getbalance exposed a bug: CWalletTx::IsFromMe had not been similarly updated, which caused getbalance to ignore wallet-internal (sent between two addresses in the node's wallet) unshielding transactions with zero confirmations. This release fixes the bug.

v4.5.0

Notable changes

Network Upgrade 5

The code preparations for the Network Upgrade 5 consensus rules are finished and
included in this release. The following ZIPs are being deployed:

• ZIP 216: Require Canonical Jubjub Point Encodings
• ZIP 224: Orchard Shielded Protocol
• ZIP 225: Version 5 Transaction Format
• ZIP 239: Relay of Version 5 Transactions
• ZIP 244: Transaction Identifier Non-Malleability

NU5 will activate on testnet at height 1,590,000, and can also be activated
at a specific height in regtest mode by setting the config option
-nuparams=f919a198:HEIGHT.

The testnet activation of NU5, and zcashd v4.5.0 itself, is aimed at enabling
existing Zcash users to test their software and make the necessary changes to be
compatible with the new consensus rules. In particular:

• Wallets should start adding support for v5 transactions.
• Miners and mining pools should ensure that their software is compatible with
  the semantic change to the block header specified in
  ZIP 244

A subsequent v4.5.1 release in the coming weeks will add support for generating
and using Unified Addresses (ZIP 316), which
will enable zcashd wallets to interact with the Orchard shielded pool.

As with previous network upgrades, it is possible that backwards-incompatible
changes might be made to the consensus rules in this testing phase, prior to
setting the mainnet activation height. In the event that this happens, testnet
will be rolled back in v5.0.0 and a second testnet activation will occur.

See ZIP 252 for additional information about the
deployment process for NU5.

Rejecting unknown CInv message types

Previously, if zcashd received an inv or getdata message containing
unknown CInv message types, it would ignore them and process the remainder of
the message. Starting with v4.5.0, zcashd will instead drop the entire inv
or getdata message and reply with a reject message. This will enable node
operators to discover whether their nodes are sending unexpected CInv types;
in particular, node operators should ensure their software does not produce the
MSG_WTX CInv message type intended for the Bitcoin network, which is
incompatible with the MSG_WTX CInv message type defined in ZIP 239 (which will
be used from NU5 activation for advertising v5 transactions).

Deprecated or removed RPCs

• The 'account' API inherited from Bitcoin Core has been disabled since the
  launch of Zcash. Following its deprecation in Bitcoin Core v0.17 and removal
  in Bitcoin Core v0.18, we have now removed the API from zcashd.

v4.4.1

Notable changes

Fixed chain sync stall bug

The 4.3.0 release included a change to prevent redundant getheaders P2P requests, to reduce node bandwith usage. This behaviour could be disabled by setting the config option -nooptimize-getheaders.

It turns out that these redundant requests were masking an unrelated bug in the chain-rewinding logic that is used when the node detects a change to the consensus rules (for example, if a user forgets to upgrade their zcashd node before a network upgrade activates, and temporarily follows an un-upgraded chain before restarting with the latest version).

In certain uncommon scenarios, a node could end up in a situation where it would believe that the best header it knew about was more than 160 blocks behind its actual best-known block. The redundant getheaders requests meant that this did not cause an issue, because the node would continue requesting headers until it found new blocks. After the getheaders optimizations, if a peer returned a headers message that was entirely known to the node, it would stop requesting more headers from that peer; this eventually caused node synchronization to stall. Restarting with the -nooptimize-getheaders config option would enable the node to continue syncing.

This release fixes the bug at its source, but the -nooptimize-getheaders config option remains available if necessary.

Build system changes

• Cross-compilation support for Windows XP, Windows Vista, and 32-bit Windows binaries, has been removed. Cross-compiled Windows binaries are now 64-bit only, and target a minimum of Windows 7.

4.4.0

Notable changes

Prometheus metrics

zcashd can now be configured to optionally expose an HTTP server that acts as a Prometheus scrape endpoint. The server will respond to GET requests on any request path.

To enable the endpoint, add -prometheusport=<port> to your zcashd configuration (either in zcash.conf or on the command line). After restarting zcashd you can then test the endpoint by querying it with e.g. curl http://127.0.0.1:<port>.

The feature includes IP-level access control rules, the default being to allow connections only from localhost. Users of this feature should be aware of the threat from DNS rebinding attacks and not rely on these access control rules for security. The allowed IPs can be expanded with -metricsallowip=<ip>, which can specify IPs or subnets.

Note that HTTPS is not supported, and therefore connections to the endpoint are not encrypted or authenticated. Access to the endpoint, including through DNS rebinding attacks, should be assumed to compromise the privacy of node operations, by the provided metrics and/or by timing side channels and so for now: You should NOT use this feature while private keys are loaded in zcashd.

The specific metrics names may change in subsequent releases, in particular to improve interoperability with zebrad.

4.3.0

Notable changes

Reduce download traffic

We have made several changes to reduce the amount of data downloaded by zcashd during initial block download (IBD):

• Significant time and bandwidth is spent in issuing getheaders P2P requests. This results in noticeable bandwidth usage due to the large size of Zcash block headers.

  We now eliminate redundant requests in cases where we already know the last header in the message. This optimization is enabled by default, but can be disabled by setting the config option -nooptimize-getheaders.

• Transactions in the mempool are no longer downloaded during IBD (zcashd will only request block data).

Reduce upload traffic

A major part of the outbound traffic is caused by serving historic blocks to other nodes in initial block download state.

It is now possible to reduce the total upload traffic via the -maxuploadtarget parameter. This is not a hard limit but a threshold to minimize the outbound traffic. When the limit is about to be reached, the uploaded data is cut by not serving historic blocks (blocks older than one week). Moreover, any SPV peer is disconnected when they request a filtered block.

This option can be specified in MiB per day and is turned off by default (-maxuploadtarget=0). The recommended minimum is 1152 * MAX_BLOCK_SIZE (currently 2304MB) per day.

Whitelisted peers will never be disconnected, although their traffic counts for calculating the target.

A more detailed documentation about keeping traffic low can be found in /doc/reduce-traffic.md.

libzcashconsensus replaced by libzcash_script

The libzcashconsensus library inherited from upstream has been unusable since the Overwinter network upgrade in 2018. We made changes to signature digests similar to those made in Bitcoin's SegWit, which required additional per-input data that could not be added to the existing APIs without breaking backwards
compatibility.

Additionally, it has become increasingly inaccurately named; it only covers (Zcash's subset of) the Bitcoin scripting system, and not the myriad of other consensus changes: in particular, Zcash's shielded pools.

We have now renamed the library to libzcash_script, and reworked it to instead focus on transparent script verification:

• The script verification APIs are altered to take consensusBranchId and amount fields.
• New precomputing APIs have been added that enable multiple transparent inputs on a single transaction to be verified more efficiently.
• Equihash has been removed from the compiled library. The canonical Equihash validator is the equihash Rust crate since v3.1.0.

The C++ library can be built by compiling zcashd with the environment variable CONFIGURE_FLAGS=--with-libs. It is also wrapped as the zcash_script Rust crate (maintained by the Zcash Foundation for use in zebrad).

Other P2P Changes

The list of banned peers is now stored on disk rather than in memory. Restarting zcashd will no longer clear out the list of banned peers; instead the clearbanned RPC method can be used to manually clear the list. The setban RPC method can also be used to manually ban or unban a peer.

Build system updates

• We now build with Clang 11 and Rust 1.49.
• We have downgraded Boost to 1.74 to mitigate statx-related breakage in some container environments.

4.2.0

Notable changes

Switch to ed25519-zebra for consensus signature checks

This removes the zcashd dependency upon libsodium for ed25519 signature checks and instead uses the Rust implementation in ed25519-zebra, which has been active for signature verification since the Canopy upgrade. For more information on the conditions that led to this change see https://hdevalence.ca/blog/2020-10-04-its-25519am.

Update default fees according to ZIP-313

Reduce default fees to 0.00001 ZEC as specified in ZIP-313 and ensure that transactions paying at least the new minimum fee meet the transaction relay threshold irrespective of transaction size.

Improve getblocktemplate rpc performance when using shielded coinbase

This change precomputes future block templates to permit miners to begin working atop newly arrived blocks as quickly as possible, rather than waiting for a new template to be generated after a block has arrived. It also reduces the initial wait time for incorporating new mempool transactions into a block from 1 minute to 10 seconds; the previous value was inherited from the upstream bitcoin codebase but is inappropriate for our block timing.

Migrate from rpc-tests.sh to rpc-tests.py

This unifies and simplifies the RPC testing framework, as has been done in the upstream Bitcoin codebase.

v4.1.1

Notable changes

This release is a hotfix release that addresses a performance regression in v4.1.0. It is recommended that either v4.0.0 or this release, v4.1.1 be used for Canopy activation.

Optimize release build

The release build now sets CFLAGS/CXXFLAGS to use the -O3 optimization option, which turns on more optimization flags than the previously used -O1. This produces a faster build, addressing a performance regression in v4.1.0.

Correctly report Founders' Reward amount in getblocktemplate

This release correctly returns the foundersreward field from getblocktemplate output pre-Canopy and removes the field post-Canopy. (The Founders' Reward will expire exactly as Canopy activates, as specified in ZIP 207.) To obtain information about funding stream amounts, use getblocksubsidy HEIGHT, passing in the height returned by the getblocktemplate API.