Latest release

Zcash 1.1.2

@bitcartel bitcartel released this Jul 2, 2018 · 53 commits to master since this release

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

@bitcartel bitcartel released this May 29, 2018 · 124 commits to master since this release

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

@str4d str4d released this Apr 14, 2018 · 370 commits to master since this release

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

@str4d str4d released this Mar 28, 2018 · 518 commits to master since this release

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

@str4d str4d released this Jan 8, 2018 · 649 commits to master since this release

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.