New Release: 2.1.2

Heartwood testnet activation

This release supports the activation of Heartwood on testnet, with an activation height of 903800, slated to occur on May 6, 2020. Please upgrade to this release, or any subsequent release, in order to follow the Heartwood network upgrade on testnet.

This release does not support activation of Heartwood on mainnet. In order to follow the Heartwood upgrade on mainnet you will still need to upgrade to 3.0.0 (or a later version) when it is released in the coming month.

The Heartwood network upgrade deploys ZIP 213, which allows miners to mine directly into shielded addresses. It also deploys ZIP 221, enabling Flyclient support by changing the semantics of existing block header fields. The deployment process for the Heartwood upgrade is described in ZIP 250.

Testnet: Mining to Sapling addresses

After the activation of Heartwood on testnet, miners will be able to immediately shield funds to Sapling addresses in the coinbase transactions which mint new testnet coins (TAZ).

This release provides the ability for miners to specify mineraddress=SAPLING_ADDRESS in their zcash.conf file, where SAPLING_ADDRESS is a Sapling payment address that they can obtain using z_getnewaddress. However, miners should wait until Heartwood has activated on testnet before making this change to their configuration file, or else getblocktemplate will return block templates that cannot be mined.

Sapling viewing key support

This release provides support for Sapling viewing keys (specifically, the extended viewing keys described in ZIP 32) in the wallet. Nodes will track both sent and received transactions for any Sapling addresses associated with the Sapling viewing keys that have been imported into the wallet.

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

View shielded information in wallet transactions

This release introduces the z_viewtransaction RPC command. This command, given a transaction ID, will decrypt the transaction with all Sapling keys in the local wallet and return the shielded information that it can recover, 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)

Other changes

  • The -maxtimeadjustment option has been removed; node operators should ensure their node’s local time is configured properly.
  • Error messages for transactions that are rejected during network upgrades are more clear.
  • We’ve introduced a -txexpirynotify option which, similar to the -blocknotify config option, will perform the configured command whenever a transaction expires in the mempool.
  • 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.

More details about the changes in this release can be found in the release notes.

Recent blog posts: