After you picked your setup in plan your deployment, the next step is configuring your Hub. This is typically quite simple as the default settings will be good enough for most.
Even so, the full details of the configuration of the Hub are shown on this page. Please also notice the configuration of the logging subsystem which is separate.
All config options on this page are for the Hub, they can be passed on the command line or in the systemd service file. In that case you should precede them with a dash. Like so:
Also shown in this example is that arguments to the options are separated by an equals sign. No spaces are allowed to separate the option and the arguments. Use quotes if needed.
Options can also be stored in the config file, which makes them look like this:
Notice that the leading dash is removed here. Arguments are passed similarly. One option per line.
- Print version and exit
Configuration location options:
- Specify configuration file (default: flowee.conf). Note about dirs.
- Specify data directory
- How many blocks to check at startup (default: 5, 0 = all).
This feature is only really relevant to check the database consistency. Make sure we didn’t have any disk-corruption.
- How thorough the block verification of -checkblocks is (0-4, default: 3).
Level 3 and 4 also check the UTXO.
- Run in the background as a daemon (returning to the commandline immediately) and accept commands from hub-cli
- Set databases cache size in megabytes (4 to 16384, default: 300)
- Keep at most <n> unconnectable transactions in memory (default: 5000). An unconnectable transaction is one that we don’t know if it is spending any actual money and as such we don’t know if they are valid. We might get a transaction later that connects an orphaned transaction to an actual chain of transactions.
- Keep the transaction memory pool below <n> megabytes (default: 300)
- Do not keep transactions in the mempool longer than <n> hours (default: 72)
- Specify pid file (default: floweethehub.pid)
- Rebuild block chain index from current blk000??.dat files on startup.
- List a fallback directory to find blocks/blk* files.
Block files (blk00000.dat etc) are written in the datadir and when the Hub wants to read the block again it tries first in the datadir again. Using this option you can pass in a series of fallback locations to look for blocks. You can use this option multiple times, the first one found is the first fallback, in sequence.
Api server options:
The API server is the main protocol that different Flowee components use to connect to each other.
- Location of the apiserver auth cookie (default: ‘api-cookie’). Note about dirs.
The cookie is auto-generated should the file not exist yet. It is simply read all consecutive times.
- Bind to given address to listen for api server connections. Use
[host]:port notation for IPv6. This option can be specified multiple times
(default 127.0.0.1:1235 and [::1]:1235).
The default only listens on loopback. Which means it is not visible from any other machine. You can bind to multiple addresses, if your machine has more than one network interface.
These options are solely for connecting to the Bitcoin network. Which is typically about the public internet. Although these options may allow you to chain your nodes on a private network.
- Add a bitcoin-node to connect to and attempt to keep the connection open
- Threshold for disconnecting misbehaving peers (default: 100).
A remote node that doesn’t speak the Bitcoin protocol correctly is given a punishment score for each infraction. Should the punishments add up to the banscore, the node is disconnected and banned from connected again for some time.
- Number of seconds to keep misbehaving peers from reconnecting (default: 86400 = 24 hours)
- Bind to given address and always listen on it. Use [host]:port notation
Being bound to a certain interface on the host machine allows other nodes to connect to you. Do this, and maybe port-forward your node to the external internet if you want SPV wallets and other users to be able to use your node for general, anonymous, requests.
- Connect only to the specified bitcoin-node(s). Notice that you can use connect multiple times, to connect to multiple nodes. It is important to realize that if you use connect the node will not try to actively find other connections. Use ‘addnode’ if you don’t want to disable that.
- Discover own IP addresses (default: true when listening and no -externalip or -proxy)
- Allow DNS lookups for -addnode, -seednode and -connect (default: 1)
- Query for peer addresses via DNS lookup, if low on addresses (default: true unless -connect)
- Specify your own public address, useful if you don’t have a upnp enabled router.
- Always query for peer addresses via DNS lookup (default: 0). If we have enough remote nodes in our peer database, there is no need for DNS lookup.
- Accept connections from outside (default: true if no -proxy or -connect). Other than actually listening you need to make your node visible. If you want to allow others to connect to your node from the public internet, you likely need to enable port-forwarding (ask your sys-admin how).
- Automatically create Tor hidden service (default: 0)
- Maintain at most <n> connections to peers (default: 125)
- Maintain at minimum <n> connections to thin-capable peers (default: 2). The ‘xthin-blocks’ protocol standard allows much smaller blocks to be sent between peers.
- Maximum per-connection receive buffer, <n>*1000 bytes (default: 5000)
- Maximum per-connection send buffer, <n>*1000 bytes (default: 1000)
- Use separate SOCKS5 proxy to reach peers via Tor hidden services (default: -proxy)
- Only connect to nodes in network <net> (ipv4, ipv6 or onion). This is useful to limit if your node is on a network unable to reach the internet on ipv6, for instance. If properly set, the hub will find new hosts faster.
- Listen for connections on <port> (default: 8333 or testnet: 18333).
- Connect through SOCKS5 proxy
- Randomize credentials for every proxy connection. This enables Tor stream isolation (default: 1)
- Connect to a node to retrieve peer addresses, and disconnect
- Specify connection timeout in milliseconds (minimum: 1, default: 5000)
- Tor control port to use if onion listening enabled (default: 127.0.0.1:9051)
- Tor control port password (default: empty)
- Tries to keep outbound traffic under the given target (in MiB per 24h), 0 = no limit (default: 0). This is great if the hub is reachable from the internet and you are on a metered connection. Otherwise you can just leave it turned off.
- Append comment to the user agent string
- Generate coins (default: 0). Please note that ‘generate’ or ‘mining’ on a CPU is not going to work, you need specialized hardware for this. There is a reason this option is in the debug section.
- Set the number of threads for coin generation if enabled (-1 = all cores, default: 1)
- When generating coins a coinbase has to be provided in the form of a public key
- Include IP addresses in debug output (default: 0)
- Send trace/debug info to console instead of debug.log file
- Shrink debug.log file on client startup (default: true when no -debug)
Chain selection options:
- Use the test chain
Node relay options:
- This node will not accept blocks larger than this limit. Unit is in MB (default: 32.0)
- Minimum bytes per sigop in transactions we relay and mine (default: 20)
- Relay and mine data carrier transactions (default: 1)
- Maximum size of data in data carrier transactions we relay and mine (default: 83)
- Request expedited blocks from this host whenever we are connected to it
- The maximum number of nodes this node will forward expedited blocks to
- The maximum number of nodes this node will forward expedited transactions to
- Fees (in BCH/kB) smaller than this are considered zero fee for relaying, mining and transaction creation (default: 0.00001)
- Enable thin blocks to speed up the relay of blocks (default: true)
Block creation options:
- Set minimum block size in bytes (default: 0)
- Set maximum block size in bytes (default: 8000000)
- Set maximum size of high-priority/low-fee transactions in bytes (default: 100000)
RPC server options:
- Accept command line and JSON-RPC commands
- Accept public REST requests (default: 0)
- Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)
- Location of the auth cookie (default: .cookie). Note about dirs.
- Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332)
- Allow JSON-RPC connections from specified source. Valid for <ip> are a single IP (e.g. 22.214.171.124), a network/netmask (e.g. 126.96.36.199⁄255.255.255.0) or a network/CIDR (e.g. 188.8.131.52⁄24). This option can be specified multiple times
- Set the number of threads to service RPC calls (default: 4)
Note that files without full paths are searched for in the following order;
- Inside the data directory.
- In the XDG data dir ($HOME/.local/share/flowee/)
- In the XDG config dir ($HOME/.config/flowee/)
- In the users homedir ($HOME/)