diff --git a/doc/amqp.md b/doc/amqp.md index f733fa514..431fa55b1 100644 --- a/doc/amqp.md +++ b/doc/amqp.md @@ -6,8 +6,8 @@ transactions between applications. AMQP supports both broker and brokerless messaging. AMQP 1.0 is an open standard and has been ratified as ISO/IEC 19464. -The Zcash daemon can be configured to act as a trusted "border -router", implementing the Zcash P2P protocol and relay, making +The Hush daemon can be configured to act as a trusted "border +router", implementing the Hush P2P protocol and relay, making consensus decisions, maintaining the local blockchain database, broadcasting locally generated transactions into the network, and providing a queryable RPC interface to interact on a polled basis for @@ -31,7 +31,7 @@ buffering or reassembly. ## Prerequisites -The AMQP feature in Zcash requires [Qpid Proton](https://qpid.apache.org/proton/) +The AMQP feature in Hush requires [Qpid Proton](https://qpid.apache.org/proton/) version 0.17 or newer, which you will need to install if you are not using the depends system. Typically, it is packaged by distributions as something like *libqpid-proton*. The C++ wrapper for AMQP *is* required. @@ -105,7 +105,7 @@ No authentication or authorization is done on peers that zcashd connects to; it is assumed that the AMQP link is exposed only to trusted entities, using other means such as firewalling. -TLS support may be added once OpenSSL has been removed from the Zcash +TLS support may be added once OpenSSL has been removed from the Hush project and alternative TLS implementations have been evaluated. SASL support may be added in a future update for secure communication. diff --git a/doc/bips.md b/doc/bips.md index 14c7e372f..35ef70c65 100644 --- a/doc/bips.md +++ b/doc/bips.md @@ -1,4 +1,4 @@ -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)). diff --git a/doc/developer-notes.md b/doc/developer-notes.md index 2fe0ec73f..c22ae3fe8 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -116,7 +116,7 @@ that run in -regtest mode. **DEBUG_LOCKORDER** -Zcash is a multithreaded application, and deadlocks or other multithreading bugs +Hush is a multithreaded application, and deadlocks or other multithreading bugs can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of which locks are held, and adds warnings to the debug.log file if inconsistencies are detected. @@ -165,7 +165,7 @@ Threads - ThreadRPCServer : Remote procedure call handler, listens on port 8232 for connections and services them. -- ZcashMiner : Generates zcash (if wallet is enabled). +- HushMiner : Generates zcash (if wallet is enabled). - Shutdown : Does an orderly shutdown of everything. diff --git a/doc/dnsseed-policy.md b/doc/dnsseed-policy.md index a85d047b5..4d08ec024 100644 --- a/doc/dnsseed-policy.md +++ b/doc/dnsseed-policy.md @@ -1,12 +1,12 @@ Expectations for DNS Seed operators ==================================== -Zcash attempts to minimize the level of trust in DNS seeds, +Hush attempts to minimize the level of trust in DNS seeds, but DNS seeds still pose a small amount of risk for the network. As such, DNS seeds must be run by entities which have some minimum -level of trust within the Zcash community. +level of trust within the Hush community. -Other implementations of Zcash software may also use the same +Other implementations of Hush software may also use the same seeds and may be more exposed. In light of this exposure, this document establishes some basic expectations for operating DNS seeds. @@ -16,7 +16,7 @@ and not sell or transfer control of the DNS seed. Any hosting services contracted by the operator are equally expected to uphold these expectations. 1. The DNS seed results must consist exclusively of fairly selected and -functioning Zcash nodes from the public network to the best of the +functioning Hush nodes from the public network to the best of the operator's understanding and capability. 2. For the avoidance of doubt, the results may be randomized but must not @@ -26,7 +26,7 @@ urgent technical necessity and disclosed. 3. The results may not be served with a DNS TTL of less than one minute. 4. Any logging of DNS queries should be only that which is necessary -for the operation of the service or urgent health of the Zcash +for the operation of the service or urgent health of the Hush network and must not be retained longer than necessary nor disclosed to any third party. diff --git a/doc/payment-api.md b/doc/payment-api.md index b5a04276b..b7b054a46 100644 --- a/doc/payment-api.md +++ b/doc/payment-api.md @@ -1,28 +1,28 @@ -# Zcash Payment API +# Hush Payment API ## Overview -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.

Outpu Command | Parameters | Description --- | --- | --- -z_exportkey | zaddr | _Requires an unlocked wallet or an unencrypted wallet._

Return a zkey for a given zaddr belonging to the node’s wallet.

The key will be returned as a string formatted using Base58Check as described in the Zcash protocol spec.

Output:AKWUAkypwQjhZ6LLNaMuuuLcmZ6gt5UFyo8m3jGutvALmwZKLdR5 -z_importkey | zkey [rescan=true] | _Wallet must be unlocked._

Add a zkey as returned by z_exportkey to a node's wallet.

The key should be formatted using Base58Check as described in the Zcash protocol spec.

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

Return a zkey for a given zaddr belonging to the node’s wallet.

The key will be returned as a string formatted using Base58Check as described in the Hush protocol spec.

Output:AKWUAkypwQjhZ6LLNaMuuuLcmZ6gt5UFyo8m3jGutvALmwZKLdR5 +z_importkey | zkey [rescan=true] | _Wallet must be unlocked._

Add a zkey as returned by z_exportkey to a node's wallet.

The key should be formatted using Base58Check as described in the Hush protocol spec.

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

Creates or overwrites a file with taddr private keys and zaddr private keys in a human-readable format.

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.

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

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.

Filename is the file to import. The path is relative to hushd’s working directory.

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
| [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 ### z_sendmany error codes diff --git a/doc/security-warnings.md b/doc/security-warnings.md index 556a55c4a..eba7141fc 100644 --- a/doc/security-warnings.md +++ b/doc/security-warnings.md @@ -4,7 +4,7 @@ Security Warnings Security Audit -------------- -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). diff --git a/doc/shield-coinbase.md b/doc/shield-coinbase.md index f9a9c1970..c48e32635 100644 --- a/doc/shield-coinbase.md +++ b/doc/shield-coinbase.md @@ -10,7 +10,7 @@ Miners, Mining pools, Online wallets ## Background -The current Zcash protocol includes a consensus rule that coinbase rewards must be sent to a shielded address. +The current Hush protocol includes a consensus rule that coinbase rewards must be sent to a shielded address. ## User Experience Challenges diff --git a/doc/translation_strings_policy.md b/doc/translation_strings_policy.md index c370dba24..abcf1c2e5 100644 --- a/doc/translation_strings_policy.md +++ b/doc/translation_strings_policy.md @@ -1,4 +1,4 @@ -*** Warning: This document has not been updated for Zcash and may be inaccurate. *** +*** Warning: This document has not been updated for Hush and may be inaccurate. *** Translation Strings Policy =========================== diff --git a/doc/unit-tests.md b/doc/unit-tests.md index 9410b4407..6025a78bc 100644 --- a/doc/unit-tests.md +++ b/doc/unit-tests.md @@ -12,6 +12,6 @@ There are two scripts for running tests: The main test suite uses two different testing frameworks. Tests using the Boost framework are under ``src/test/``; tests using the Google Test/Google Mock framework are under ``src/gtest/`` and ``src/wallet/gtest/``. The latter framework -is preferred for new Zcash unit tests. +is preferred for new Hush unit tests. RPC tests are implemented in Python under the ``qa/rpc-tests/`` directory. diff --git a/doc/wallet-backup.md b/doc/wallet-backup.md index ef48cea15..968d6c903 100644 --- a/doc/wallet-backup.md +++ b/doc/wallet-backup.md @@ -2,7 +2,7 @@ ## Overview -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`. diff --git a/doc/zmq.md b/doc/zmq.md index c13a31d2c..a473d2ca4 100644 --- a/doc/zmq.md +++ b/doc/zmq.md @@ -5,8 +5,8 @@ connections, inter-process communication, and shared-memory, providing various message-oriented semantics such as publish/subscribe, request/reply, and push/pull. -The Zcash daemon can be configured to act as a trusted "border -router", implementing the Zcash wire protocol and relay, making +The Hush daemon can be configured to act as a trusted "border +router", implementing the Hush wire protocol and relay, making consensus decisions, maintaining the local blockchain database, broadcasting locally generated transactions into the network, and providing a queryable RPC interface to interact on a polled basis for @@ -33,7 +33,7 @@ buffering or reassembly. ## Prerequisites -The ZeroMQ feature in Zcash requires ZeroMQ API version 4.x or +The ZeroMQ feature in Hush requires ZeroMQ API version 4.x or newer, which you will need to install if you are not using the depends system. Typically, it is packaged by distributions as something like *libzmq5-dev*. The C++ wrapper for ZeroMQ is *not* needed. @@ -103,5 +103,5 @@ retrieve the chain from the last known block to the new tip. There are several possibilities that ZMQ notification can get lost during transmission depending on the communication type you are -using. Zcashd appends an up-counting sequence number to each +using. Hushd appends an up-counting sequence number to each notification which allows listeners to detect lost notifications.