You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

99 lines
5.4 KiB

4 years ago
# Hush Full Node Integration Docs
This document will help you install and maintain a Hush Full Node. It is mainly geared towards exchanges and mining pools, but
will be useful to any service provider adding Hush, such as a tipbot or exchange or mining pool.
4 years ago
# Installing Hush from source
On Ubuntu/Linux systems, you can install Hush from [source](https://git.hush.is/hush/hush3) with these commands:
4 years ago
```
# install build depedencies
sudo apt-get install build-essential pkg-config libc6-dev m4 g++-multilib \
autoconf libtool ncurses-dev unzip git python zlib1g-dev wget \
bsdmainutils automake curl unzip nano libsodium-dev
git clone https://git.hush.is/hush/hush3.git
4 years ago
cd hush3
./build.sh -j4 #4 for use 4 cores
4 years ago
```
More details can be found [here](https://git.hush.is/hush/hush3/src/branch/master/INSTALL.md)
4 years ago
4 years ago
# Installing Hush from a binary
You can also install a binary from an [official release](https://git.hush.is/hush/hush3/releases)
4 years ago
4 years ago
# Terminology
We have a document that explains a lot of terminology [here](https://git.hush.is/hush/terminology)
4 years ago
# 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
4 years ago
# Config changes for exchanges and pools
4 years ago
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
access, so don't show the contents to untrusted people. The legacy location used to be `~/.komodo/HUSH3/HUSH3.conf` . You can move the old legacy directory to the new location and it will be found and used.
4 years ago
An advanced feature exchanges & pools can use is called `consolidation=1` which keeps wallets small and hence fast.
4 years ago
This feature will always make small transactions in the background, "consolidating" funds into very efficient amounts. This
makes future transactions fast by spending small amounts of time consolidating funds in the background. We note that turning on consolidation for an already very large wallet will have performance issues.
4 years ago
Here is an example config file for HUSH which is recommended for exchanges and mining pools:
```
rpcuser=someuser
rpcpassword=agoodpassword
rpcport=18031
server=1
txindex=1
rpcworkqueue=256
rpcallowip=127.0.0.1
rpcbind=127.0.0.1
# if you have servers with slow CPUs or very large existing wallets, comment out the next line
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
4 years ago
# How Shielded Addresses (zaddrs) Are Different
4 years ago
* Change from a zaddr goes back to itself! Not a different address, like in transparent addresses (taddrs).
* 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
4 years ago
* 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
4 years ago
* 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`
4 years ago
4 years ago
# GUI wallets
4 years ago
Hush full node GUI wallet: [SilentDragon](https://git.hush.is/hush/SilentDragon/releases)
4 years ago
Hush lite wallet: [SilentDragonLite](https://git.hush.is/hush/SilentDragonLite/releases)
4 years ago
Android wallet (pairs with SilentDragon or SilentDragonLite): [SilentDragonAndroid](https://git.hush.is/hush/SilentDragonAndroid/releases)
4 years ago