BIPs that are implemented by Zcash (up-to-date up to **v1.1.0**):
BIPs that are implemented by Hush (up-to-date up to **v1.1.0**):
* Numerous historic BIPs were present in **v1.0.0** at launch; see [the protocol spec](https://github.com/zcash/zips/blob/master/protocol/protocol.pdf) for details.
* [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, but only enforced for peer versions `>=170004` as of **v1.1.0** ([PR #2814](https://github.com/zcash/zcash/pull/2814)).
Zcash extends the Bitcoin Core API with new RPC calls to support private Zcash payments.
Hush extends the Bitcoin Core API with new RPC calls to support private Hush payments.
Zcash payments make use of two address formats:
Hush payments make use of two address formats:
* taddr - an address for transparent funds (just like a Bitcoin address, value stored in UTXOs)
* zaddr - an address for private funds (value stored in objects called notes)
When transferring funds from one taddr to another taddr, you can use either the existing Bitcoin RPC calls or the new Zcash RPC calls.
When transferring funds from one taddr to another taddr, you can use either the existing Bitcoin RPC calls or the new Hush RPC calls.
When a transfer involves zaddrs, you must use the new Zcash RPC calls.
When a transfer involves zaddrs, you must use the new Hush RPC calls.
## Compatibility with Bitcoin Core
Zcash supports all commands in the Bitcoin Core API (as of version 0.11.2). Where applicable, Zcash will extend commands in a backwards-compatible way to enable additional functionality.
Hush supports all commands in the Bitcoin Core API (as of version 0.11.2). Where applicable, Hush will extend commands in a backwards-compatible way to enable additional functionality.
We do not recommend use of accounts which are now deprecated in Bitcoin Core. Where the account parameter exists in the API, please use “” as its value, otherwise an error will be returned.
To support multiple users in a single node’s wallet, consider using getnewaddress or z_getnewaddress to obtain a new address for each user. Also consider mapping multiple addresses to each user.
## List of Zcash API commands
## List of Hush API commands
Optional parameters are denoted in [square brackets].
@ -61,8 +61,8 @@ z_validateaddress | zaddr | Return information about a given zaddr.<br><br>Outpu
Command | Parameters | Description
--- | --- | ---
z_exportkey | zaddr | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Return a zkey for a given zaddr belonging to the node’s wallet.<br><br>The key will be returned as a string formatted using Base58Check as described in the Zcash protocol spec.<br><br>Output:AKWUAkypwQjhZ6LLNaMuuuLcmZ6gt5UFyo8m3jGutvALmwZKLdR5
z_importkey | zkey [rescan=true] | _Wallet must be unlocked._<br><br>Add a zkey as returned by z_exportkey to a node's wallet.<br><br>The key should be formatted using Base58Check as described in the Zcash protocol spec.<br><br>Set rescan to true (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transactions affecting the newly-added address for this spending key).
z_exportkey | zaddr | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Return a zkey for a given zaddr belonging to the node’s wallet.<br><br>The key will be returned as a string formatted using Base58Check as described in the Hush protocol spec.<br><br>Output:AKWUAkypwQjhZ6LLNaMuuuLcmZ6gt5UFyo8m3jGutvALmwZKLdR5
z_importkey | zkey [rescan=true] | _Wallet must be unlocked._<br><br>Add a zkey as returned by z_exportkey to a node's wallet.<br><br>The key should be formatted using Base58Check as described in the Hush protocol spec.<br><br>Set rescan to true (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transactions affecting the newly-added address for this spending key).
z_exportwallet | filename | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Creates or overwrites a file with taddr private keys and zaddr private keys in a human-readable format.<br><br>Filename is the file in which the wallet dump will be placed. May be prefaced by an absolute file path. An existing file with that name will be overwritten.<br><br>No value is returned but a JSON-RPC error will be reported if a failure occurred.
z_importwallet | filename | _Requires an unlocked wallet or an unencrypted wallet._<br><br>Imports private keys from a file in wallet export file format (see z_exportwallet). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.<br><br>Filename is the file to import. The path is relative to hushd’s working directory.<br><br>No value is returned but a JSON-RPC error will be reported if a failure occurred.
z_exportviewingkey | zaddr | Reveals the viewing key corresponding to 'zaddr'. Then the z_importviewingkey can be used with this output.
@ -111,7 +111,7 @@ z_listoperationids <br>| [state] | Return a list of operationids for all operati
## Asynchronous RPC call Error Codes
Zcash error codes are defined in https://github.com/zcash/zcash/blob/master/src/rpcprotocol.h
Hush error codes are defined in https://github.com/zcash/zcash/blob/master/src/rpcprotocol.h
Zcash has been subjected to a formal third-party security review. For security
Hush has been subjected to a formal third-party security review. For security
announcements, audit results and other general security information, see
https://z.cash/support/security.html
@ -47,7 +47,7 @@ running on your OS can read your wallet.dat file.
Side-Channel Attacks
--------------------
This implementation of Zcash is not resistant to side-channel attacks. You
This implementation of Hush is not resistant to side-channel attacks. You
should assume (even unprivileged) users who are running on the hardware, or who
are physically near the hardware, that your `zcashd` process is running on will
be able to:
@ -84,7 +84,7 @@ Users should also refrain from changing the default setting that only allows RPC
Block Chain Reorganization: Major Differences
-------------------------------------------------
Users should be aware of new behavior in Zcash that differs significantly from Bitcoin: in the case of a block chain reorganization, Bitcoin's coinbase maturity rule helps to ensure that any reorganization shorter than the maturity interval will not invalidate any of the rolled-back transactions. Zcash keeps Bitcoin's 100-block maturity interval for generation transactions, but because JoinSplits must be anchored within a block, this provides more limited protection against transactions becoming invalidated. In the case of a block chain reorganization for Zcash, all JoinSplits which were anchored within the reorganization interval and any transactions that depend on them will become invalid, rolling back transactions and reverting funds to the original owner. The transaction rebroadcast mechanism inherited from Bitcoin will not successfully rebroadcast transactions depending on invalidated JoinSplits if the anchor needs to change. The creator of an invalidated JoinSplit, as well as the creators of all transactions dependent on it, must rebroadcast the transactions themselves.
Users should be aware of new behavior in Hush that differs significantly from Bitcoin: in the case of a block chain reorganization, Bitcoin's coinbase maturity rule helps to ensure that any reorganization shorter than the maturity interval will not invalidate any of the rolled-back transactions. Hush keeps Bitcoin's 100-block maturity interval for generation transactions, but because JoinSplits must be anchored within a block, this provides more limited protection against transactions becoming invalidated. In the case of a block chain reorganization for Hush, all JoinSplits which were anchored within the reorganization interval and any transactions that depend on them will become invalid, rolling back transactions and reverting funds to the original owner. The transaction rebroadcast mechanism inherited from Bitcoin will not successfully rebroadcast transactions depending on invalidated JoinSplits if the anchor needs to change. The creator of an invalidated JoinSplit, as well as the creators of all transactions dependent on it, must rebroadcast the transactions themselves.
Receivers of funds from a JoinSplit can mitigate the risk of relying on funds received from transactions that may be rolled back by using a higher minconf (minimum number of confirmations).
Backing up your Zcash private keys is the best way to be proactive about preventing loss of access to your ZEC.
Backing up your Hush private keys is the best way to be proactive about preventing loss of access to your ZEC.
Problems resulting from bugs in the code, user error, device failure, etc. may lead to losing access to your wallet (and as a result, the private keys of addresses which are required to spend from them).
@ -12,7 +12,7 @@ Note that a backup is a duplicate of data needed to spend ZEC so where you keep
## Instructions for backing up your wallet and/or private keys
These instructions are specific for the officially supported Zcash Linux client. For backing up with third-party wallets, please consult with user guides or support channels provided for those services.
These instructions are specific for the officially supported Hush Linux client. For backing up with third-party wallets, please consult with user guides or support channels provided for those services.
There are multiple ways to make sure you have at least one other copy of the private keys needed to spend your ZEC and view your shielded ZEC.
@ -32,7 +32,7 @@ To create a backup of your wallet, use:
The backup will be an exact copy of the current state of your wallet.dat file stored in the export directory you specified in the config file. The file path will also be returned.
If you generate a new Zcash address, it will not be reflected in the backup file.
If you generate a new Hush address, it will not be reflected in the backup file.
If your original `wallet.dat` file becomes inaccessible for whatever reason, you can use your backup by copying it into your data directory and renaming the copy to `wallet.dat`.
