xcashd
keeps your computer synced up with the X-Cash network.xcashd
is entirely decoupled from your wallet.xcashd
does not access your private keys and therefore doesn't know your transactions and balance.xcashd
on a separate computer or in the cloud and access it remotely to retrieve/provide the data needed for wallet operations.xcashd
instance provided by a semi-trusted 3rd party. Such 3rd party will not be able to steal your funds as all transactions are signed locally../xcashd [options] [command]
--option-name
convention.command_name
convention.--option-name
convention.--help
--version
xcashd
version to stdout. Example: X-CASH '' (v1.5.0-unknown)
--os-version
OS: Microsoft (build 17763), 64-bit
--stagenet
--stagenet
as well.--testnet
--testnet
as well.--log-file
./xcashd --log-file=/var/log/xcash/mainnet/xcash.log
--log-level
0-4
with 0
being minimal logging and 4
being full tracing. Defaults to 0
. These are general presets and do not directly map to severity levels. For example, even with minimal 0
, you may see some most important INFO
entries. Temporarily changing to 1
allows for much better understanding of how the full node operates. Example: ./xcashd --log-level=1
--max-log-file-size
xcashd
creates the next log file with a UTC timestamp postfix -YYYY-MM-DD-HH-MM-SS
. In production deployments, you would probably prefer to use established solutions like logrotate instead. In that case, set --max-log-file-size=0
to prevent xcashd from managing the log files.--max-log-files
xcashd
defaults are adjusted for running it occasionally on the same computer as your X-Cash wallet.--config-file
--data-dir
--pidfile
--detach
../xcashd --detach --pidfile=/run/xcash/xcashd.pid
--detach
xcashd
daemon with systemd or similar. By default xcashd
runs in a foreground.--non-interactive
xcashd
runs in a foreground and opens stdin for reading. This breaks containerization because no tty gets assigned and xcashd
process crashes. You can make it run in a background with --detach
but this is inconvenient in a containerized environment because the canonical usage is that the container waits on the main process to exist (forking makes things more complicated).--no-igd
--max-txpool-weight
--enforce-dns-checkpointing
ERROR Local blockchain failed to pass a checkpoint, rolling back!
Eventually, the alternative ("fixed") fork will get heavier and the node will follow it, leaving the "invalid" fork behind.ERRORWARNING: local blockchain failed to pass a xcashPulse checkpoint, and you could be on a fork. You should either sync up from scratch, OR download a fresh blockchain bootstrap, OR enable checkpoint enforcing with the --enforce-dns-checkpointing command-line option
As of 04/09/2019, X-Cash has not implemented X-CashPulse operators.--disable-dns-checkpoints
--p2p-bind-ip
0.0.0.0
binds to all network interfaces and should be used in general working conditions. You must change this if you want to constrain binding, for example to configure connection through Tor via torsocks: DNS_PUBLIC=tcp://1.1.1.1 TORSOCKS_ALLOW_INBOUND=1 torsocks ./xcashd --p2p-bind-ip 127.0.0.1 --no-igd --hide-my-port
--p2p-bind-port
18281
for mainnet, 28281
for testnet, and 38281
for stagenet. You normally wouldn't change that. This is helpful to run several nodes on your machine to simulate private a X-Cash p2p network (likely using private testnet). Example: ./xcashd --p2p-bind-port=48080
--p2p-external-port
xcashd
know what to advertise on the network. By default this value is 0
.--hide-my-port
xcashd
will still open and listen on the p2p port. However, it will not announce itself as a peer list candidate. Technically, it will return port 0
in a response to p2p handshake (node_data.my_port = 0
in get_local_node_data
function). In effect nodes you connect to won't spread your IP to other nodes. To sum up, it is not really hiding, it is more like "do not advertise".--seed-node
xcashd
will use hardcoded seed nodes on the first run, and peers cached on disk on subsequent runs.--add-peer
--add-priority-node
./xcashd --add-priority-node=178.128.192.138:18081 --add-priority-node=144.76.202.167:18081
--add-exclusive-node
--add-priority-node
and --seed-node
are ignored. To add multiple nodes use the option several times. Example: ./xcashd --add-exclusive-node=178.128.192.138:18081 --add-exclusive-node=144.76.202.167:18081
--out-peers
-1
represents the code default.--in-peers
-1
represents the code default.--limit-rate-up
-1
represents the code default.--limit-rate-down
-1
represents the code default.--limit-rate
-1
) the individual up/down default limits will be used. It is better to use --limit-rate-up
and --limit-rate-down
instead to avoid confusion.--offline
--allow-local-ip
xcashd
node offers a powerful API. It serves 3 purposes:--rpc-bind-ip
127.0.0.1
because API gives full administrative capabilities over the node. Set it to 0.0.0.0
to listen on all interfaces - but only in connection with one of *-restricted-*
options and --confirm-external-bind
.--rpc-bind-port
18281
(mainnet), 28281
(testnet), 38281
(stagenet).--rpc-restricted-bind-port
--confirm-external-bind
--rpc-bind-ip
to non-localhost IP and you understand the consequences.--restricted-rpc
--rpc-restricted-bind-port
because you would end up with two restricted APIs.--rpc-login
username[:password]
required to connect to API. Practical usage is limited because API communication is in plain text over HTTP.--rpc-access-control-origins
xcashd
API directly from a web browser via JavaScript (say in a pure-fronted web appp scenario). With this option xcashd
will put proper HTTP CORS headers to its responses. You will also need to set --rpc-login
if you use this option. Normally though, the API is used by backend app and this option isn't necessary.xcashd
. There are also wallet notifications like --tx-notify
offered by xcashd-wallet-rpc
here.--block-notify
<arg>
must be a full path. If the <arg>
contains %s
it will be replaced by the block hash. Example: ./xcashd --block-notify="/usr/bin/echo %s"
Block notifications are good for immediate reaction. However, you should always assume you will miss some block notifications and you should independently poll the API to cover this up. Mind blockchain reorganizations. Block notifications can revert to same and past heights. Small reorganizations are natural and happen every day.--block-rate-notify
<arg>
must be a full path. The <arg
> can contain any of %t
, %b
, %e
symbols to interpolate: %t
: the number of minutes in the observation window %b
: the number of blocks observed in that window %e
: the ideal number of blocks expected in that window The option will let you know if the network hash rate drops by a lot. This may be indicative of a large section of the network miners moving off to mine a private chain, to be later released to the network. Note that if this event triggers, it is not incontrovertible proof that this is happening. It might just be chance. The longer the window (the %t parameter), and the larger the distance between actual and expected number of blocks, the more indicative it is of a possible chain reorg double-spend attack being prepared. Recommendation: unless you run economically significant X-Cash exchange or operation, do not act on this data. It is hard to calibrate and easy to misinterpret. If this is a real attack, it will target high-liquidity entities and not small merchants.--reorg-notify
<arg>
must be a full path. The <arg
> can contain any of %s
, %h
, %n
symbols to interpolate: %s
: the height at which the split occurs %h
: the height of the new blockchain %d
: the number of blocks discarded from the old chain %n
: the number of blocks being added The option will let you know when a block is removed from the chain to be replaced by other blocks. This happens when a 51% attack occurs, but small reorgs also happen in the normal course of things. The %d
parameter will be set to the number of blocks discarded from the old chain (so if this is higher than the number of confirmations you wait to act upon an incoming payment, that payment might have been cancelled). The %n
parameter wil be set to the number of blocks in the new chain (so if this is higher than the number of confirmations you wait to act upon an incoming payment, any incoming payment in the first block will be automatically acted upon by your platform). Recommendation: unless you run economically significant X-Cash exchange or operation, you do not need to bother with this option. Simply account for reorganizations by requiring at least 10 confirmations to consider payments no reversible.xcashd
node, sometimes at the expense of reliability.--db-sync-mode
The default is
fast:async:250000000bytes. The
fast:async:*can corrupt blockchain database in case of a system crash. It should not corrupt if just
xcashdcrashes. If you are concerned with system crashes use
safe:sync`.--max-concurrency
0
uses the number of CPU threads.--prep-blocks-threads
1
to turn on and 0
to turn off. This is on (1
) by default. Normally, for every block the full node must calculate the block hash to verify miner's proof of work. Because the CryptoNight PoW used in X-Cash is very expensive (even for verification), xcashd
offers skipping these calculations for old blocks. In other words, it's a mechanism to trust xcashd
binary regarding old blocks' PoW validity, to sync up faster.--block-sync-size
0
. Intuitively, the more resources you have, the bigger batch size you may want to try out. Example: ./xcashd --block-sync-size=500
--bootstrap-daemon-address
./xcashd --bootstrap-daemon-address=opennode.xmr-tw.org:18089
. The node will forward selected RPC calls to the bootstrap node. The wallet will handle this automatically and transparently. Obviously, such bootstraping phase has privacy implications similar to directly using a remote node.--bootstrap-daemon-login
xcashd
. This is mostly useful for:281000
, X-Cash switched to Cryptonight HeavyX algorithm which is ASIC and NiceHash resistant.--start-mining
--mining-threads
--extra-messages-file
--bg-mining-enable
--bg-*
options below.--bg-mining-ignore-battery
--bg-mining-min-idle-interval
--bg-mining-idle-threshold
--bg-mining-miner-target
--test-drop-download
--test-drop-download-height
0
.--regtest
--fixed-difficulty
0
.--test-dbg-lock-sleep
--save-graph
xcashd
for backwards compatibility.--fluffy-blocks
--no-fluffy-blocks
--show-time-stats
--zmq-rpc-bind-ip
127.0.0.1
. This is not yet widely used as ZMQ interface currently does not provide meaningful advantage over classic JSON-RPC interface. Unfortunately, currently there is no way to disable the ZMQ server.--zmq-rpc-bind-port
18082
for mainnet, 38082
for stagenet, and 28082
for testnet.--db-type
lmdb
.command_name
convention.xcashd
(if not detached).help [<command>]
<command>
.version
X-CASH '' (v1.5.0-unknown)
status
Height: 424951/424951 (100.0%) on mainnet, not mining, net hash 2.38 MH/s, v12, update needed, 8(out)+0(in) connections, uptime 0d 1h 18m 25s
print_pl
print_pl_stats
xcashd
remembers them from past sessions.print_cn
ban <IP> [<seconds>]
<IP>
for a given amount of <seconds>
. By default the ban is for 24h. Example: ./xcashd ban 187.63.135.161
unban <IP>
<IP>
.bans
187.63.135.161 banned for 86397 seconds
.in_peers <max_number>
out_peers <max_uber>
limit [<kB/s>]
limit_down [<kB/s>]
limit_up [<kB/s>]
flush_txpool [<txid>]
print_pool
print_pool_sh
print_pool_stats
print_coinbase_tx_sum <start_height> [<block_count>]
./xcashd print_coinbase_tx_sum 0 1000000000000
print_tx <transaction_hash> [+hex] [+json]
relay_tx <txid>
print_height
sync_info
print_bc <begin_height> [<end_height>]
hard_fork_info
is_key_image_spent <key_image>
exit
, stop_daemon
exit
and stop_daemon
are identical (one is alias of the other).set log <{+,-,}categories>
<level>
is a number 0-4print_status
update (check download)
sha256sum
to verify. Example output: Update available: v0.13.0.4: https://downloads.getxcash.org/cli/xcash-linux-x64-v0.13.0.4.tar.bz2, hash 693e1a0210201f65138ace679d1ab1928aca06bb6e679c20d8b4d2d8717e50d6
Update downloaded to: /opt/xcash-v0.13.0.2/xcash-linux-x64-v0.13.0.4.tar.bz2
show_hr
xcashd
daemon to stop printing current hash rate. Relevant only if xcashd
is mining.hide_hr
xcashd
daemon to print current hash rate. Relevant only if xcashd
is mining.start_mining <adr> [<threads>] [do_background_mining] [ignore_battery]
xcashd
daemon to start mining. Block reward will go to <addr>
.stop_mining
xcashd
daemon to stop mining.start_save_graph
stop_save_graph
save
xcashd
saves the blockchain automatically on exit.output_histogram [@<amount>] <min_count> [<max_count>]