@ -27,6 +27,13 @@ You can also install a binary from an [official release](https://git.hush.is/hus
We have a document that explains a lot of terminology [here](https://git.hush.is/hush/terminology)
# Hush RPC Docs
Every single Hush RPC is documented on the web at https://faq.hush.is/rpc/
For instance the docs for `z_listunspent` RPC are here: https://faq.hush.is/rpc/z_listunspent.html
# Config changes for exchanges and pools
The default location on Linux for the HUSH config file is `~/.hush/HUSH3/HUSH3.conf` . This file will have a username and password for RPC
@ -51,16 +58,35 @@ rpcbind=127.0.0.1
consolidation=1
```
# Tips for exchanges and mining pools
* It's possible that many users request a withdraw within a few seconds of each other which will spike CPU usage and potentially trigger bugs
* Hush 3.9.1 should be less likely to have these bugs
* It's a good idea to not let too many ztx's be queued at once.
* So it's good to check the output of z_getoperationstatus before queuing a new ztx
* If there are 3 or more existing ztx's in the state of "executing", do not add more
* Wait until there are 2 or less ztx's in the "executing" state to add more to the queue
* To detect users that are mining to your exchange:
* Occasionally process the output of `z_listunspent`, such as once per hour via cron
* If a certain zaddr has more than 30 zutxos (items in the array output of `z_listunspent`) it's likely they are mining to the exchange, or sending many small deposits
* You can then manually inspect these user accounts or send them a message to not mine to the exchange
* The `rescan` RPC in Hush 3.9.1 can be used to rescan from any block height, which minimizes downtime.
* Example usage: `hush-cli rescan 123456`
* It's best to only send payouts a few times per day (such as 2 or 3) instead of when they are above a threshold.
* This will make pool wallets smaller and faster, miner wallets smaller and faster, and exchange wallets smaller and faster (because miners often mine directly to pools)
* For exchanges, you can limit how many withdrawals a user can do per day, such as 3, and show them how many they have left. This will help keep wallets small and fast.
* To see the balances of all zaddrs use `z_getbalances`
* Do not use `z_getbalance` for each zaddr in the wallet, that will be drastically slower
# How Shielded Addresses (zaddrs) Are Different
* Change from a zaddr goes back to itself! Not a different address, like in transparent addresses (taddrs).
* Making zaddr transactions are slower, taking a few seconds instead of a few milliseconds
* Shielded transactions do not show the sender address, receiver address or amounts on the public explorer. You will need to use local RPC methods such as `z_viewtransaction` to see those details
* Making zaddr transactions are slower, taking at least a few seconds and potentially hundreds of seconds for very large transactions, instead of a few milliseconds
* Shielded transactions do not show the sender address, receiver address or amounts on the public explorer. You will need to use local RPC methods such as `z_viewtransaction`or `getrawtransaction txid 1`to see those details
* Shielded transactions are larger than transparent transactions, because more data is stored
* Very roughly, the smallest shielded transactions are about 1KB, some can be very large up to the transaction size limit of 200KB
* RPCs which work with zaddrs usually begin with `z_` such as `z_listunspent`. The very common `sendmany` RPC is called `z_sendmany` for zaddrs
* To generate a new zaddr use `z_getnewaddress`
* To see the balances of all zaddrs use `z_getbalances`
* Do not use `z_getbalance` for each zaddr in the wallet, that will be drastically slower
