monerod - Reference

Overview

Connects you to Monero network

The Monero daemon monerod keeps your computer synced up with the Monero network.

It downloads and validates the blockchain from the p2p network.

Not aware of your private keys

monerod is entirely decoupled from your wallet.

monerod does not access your private keys - it is not aware of your transactions and balance.

This allows you to run monerod on a separate computer or in the cloud.

In fact, you can connect to a remote monerod instance provided by a semi-trusted 3rd party. Such 3rd party will not be able to steal your funds. This is very handy for learning and experimentation.

However, there are privacy and reliability implications to using a remote, untrusted node. For any real business you should be running your own full node.

Syntax

./monerod [options] [command]

Options define how the daemon should be working. Their names follow the --option-name pattern.

Commands give access to specific services provided by the daemon. Commands are executed against the running daemon. Their names follow the command_name pattern.

Running

Go to directory where you unpacked Monero.

The stagenet is what you should be using for learning and experimentation.

./monerod --stagenet --detach                # run as a daemon in background
tail -f ~/.bitmonero/stagenet/bitmonero.log  # watch the logs
./monerod --stagenet exit                    # ask daemon to exit gracefully

The mainnet is when you want to deal with the real XMR.

./monerod --detach                           # run as a daemon in background
tail -f ~/.bitmonero/bitmonero.log           # watch the logs
./monerod exit                               # ask daemon to exit gracefully

Options

Options define how the daemon should be working. Their names follow the --option-name pattern.

The following groups are only to make reference easier to follow. The daemon itself does not group options in any way.

Help and version

OptionDescription
--helpEnlist available options.
--versionShow monerod version to stdout. Example output:
Monero 'Oxygen Orion' (v0.17.1.8-release)
--os-versionShow build timestamp and target operating system. Example output:
OS: Linux #65-Ubuntu SMP Thu Dec 10 12:01:51 UTC 2020 5.4.0-59-generic.
--check-updatesOne of: disabled | notify | download (=notify by default). Check for new versions of Monero and optionally download it. You should probably prefer your OS package manager to do the update, if possible. There is also unimplemented update option shown by the help system.

Pick Monero network (blockchain)

OptionDescription
(missing)By default monerod assumes mainnet.
--stagenetRun on stagenet. Remember to run your wallet with --stagenet as well.
--testnetRun on testnet. Remember to run your wallet with --testnet as well.

Logging

OptionDescription
--log-fileFull path to the log file. Example (mind file permissions):
./monerod --log-file=/var/log/monero/mainnet/monerod.log
--log-level0-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:
./monerod --log-level=1
--max-log-file-sizeSoft limit in bytes for the log file (=104850000 by default, which is just under 100MB). Once log file grows past that limit, monerod 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 monerod from managing the log files.
--max-log-filesLimit on the number of log files (=50 by default). The oldest log files are removed. In production deployments, you would probably prefer to use established solutions like logrotate instead.

Server

monerod defaults are adjusted for running it occasionally on the same computer as your Monero wallet.

The following options will be helpful if you intend to have an always running node — most likely on a remote server or your own separate PC.

OptionDescription
--config-fileFull path to the configuration file. By default monerod looks for bitmonero.conf in Monero data directory.
--data-dirFull path to data directory. This is where the blockchain, log files, and p2p network memory are stored. For defaults and details see data directory.
--pidfileFull path to the PID file. Works only with --detach. Example:
./monerod --detach --pidfile=/run/monero/monerod.pid
--detachGo to background (decouple from the terminal). This is useful for long-running / server scenarios. Typically, you will also want to manage monerod daemon with systemd or similar. By default monerod runs in a foreground.
--non-interactiveDo not require tty in a foreground mode. Helpful when running in a container. By default monerod runs in a foreground and opens stdin for reading. This breaks containerization because no tty gets assigned and monerod 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-zmqDisable ZMQ RPC server. You should use this option to limit attack surface and number of unnecessarily open ports (the ZMQ server is unfinished thing and you are unlikely to ever use it).
--no-igdDisable UPnP port mapping on the router (“Internet Gateway Device”). Add this option to improve security if you are not behind a NAT (you can bind directly to public IP or you run through Tor).
--max-txpool-weightSet maximum transactions pool size in bytes. By default 648000000 (~618MB). These are transactions pending for confirmations (not included in any block).
--enforce-dns-checkpointingThe emergency checkpoints set by MoneroPulse operators will be enforced. It is probably a good idea to set enforcing for unattended nodes.

If encountered block hash does not match corresponding checkpoint, the local blockchain will be rolled back a few blocks, effectively blocking following what MoneroPulse operators consider invalid fork. The log entry will be produced: 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.

By default checkpointing only notifies about discrepancy by producing the following log entry: ERROR WARNING: local blockchain failed to pass a MoneroPulse 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.

Reference: source code.
--disable-dns-checkpointsThe MoneroPulse checkpoints set by core developers will be discarded. The checkpoints are apparently still fetched though.

P2P network

The following options define how your node participates in Monero peer-to-peer network. This is for node-to-node communication. The following options do not affect wallet-to-node interface.

The node and peer words are used interchangeably.

OptionDescription
--p2p-bind-ipIPv4 network interface to bind to for p2p network protocol. Default value 0.0.0.0 binds to all network interfaces. This is typically what you want.

You must change this if you want to constrain binding, for example to force working through Tor via torsocks:
DNS_PUBLIC=tcp://1.1.1.1 TORSOCKS_ALLOW_INBOUND=1 torsocks ./monerod --p2p-bind-ip 127.0.0.1  --no-igd  --hide-my-port
--p2p-bind-portTCP port to listen for p2p network connections. Defaults to 18080 for mainnet, 28080 for testnet, and 38080 for stagenet. You normally wouldn’t change that. This is helpful to run several nodes on your machine to simulate private Monero p2p network (likely using private Testnet). Example:
./monerod --p2p-bind-port=48080
--p2p-external-portTCP port to listen for p2p network connections on your router. Relevant if you are behind a NAT and still want to accept incoming connections. You must then set this to relevant port on your router. This is to let monerod know what to advertise on the network. Default is 0.
--p2p-use-ipv6Enable IPv6 for p2p (disabled by default).
--p2p-bind-ipv6-addressIPv6 network interface to bind to for p2p network protocol. Default value :: binds to all network interfaces.
--p2p-bind-port-ipv6TCP port to listen for p2p network connections. By default same as IPv4 port for given nettype.
--p2p-ignore-ipv4Ignore unsuccessful IPv4 bind for p2p. Useful if you only want to use IPv6.
--igdSet UPnP port mapping on the router (“Internet Gateway Device”). One of: disabled | enabled | delayed (=delayed by default). Relevant if you are behind NAT and want to accept incoming P2P network connections. The delayed value means it will wait for incoming connections in hope UPnP may not be necessary. After a while w/o incoming connections found it will attempt to map ports with UPnP. If you know you need UPnP change it to enabled to fast track the process.
--hide-my-portmonerod 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-nodeConnect to a node to retrieve other nodes’ addresses, and disconnect. If not specified, monerod will use hardcoded seed nodes on the first run, and peers cached on disk on subsequent runs.
--add-peerManually add node to local peer list, host:port. Syntax supports IP addresses, domain names, onion and i2p hosts.
--add-priority-nodeSpecify list of nodes to connect to and then attempt to keep the connection open.

To add multiple nodes use the option several times. Example:
./monerod --add-priority-node=178.128.192.138:18081 --add-priority-node=144.76.202.167:18081
--add-exclusive-nodeSpecify list of nodes to connect to only. If this option is given the options --add-priority-node and --seed-node are ignored.

To add multiple nodes use the option several times. Example:
./monerod --add-exclusive-node=178.128.192.138:18081 --add-exclusive-node=144.76.202.167:18081
--out-peersSet max number of outgoing connections to other nodes. By default 12. Value -1 represents the code default.
--in-peersSet max number of incoming connections (nodes actively connecting to you). By default unlimited. Value -1 represents the code default.
--limit-rate-upSet outgoing data transfer limit [kB/s]. By default 2048 kB/s. Value -1 represents the code default.
--limit-rate-downSet incoming data transfer limit [kB/s]. By default 8192 kB/s. Value -1 represents the code default.
--limit-rateSet the same limit value for incoming and outgoing data transfer. By default (-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.
--offlineDo not listen for peers, nor connect to any. Useful for working with a local, archival blockchain.
--allow-local-ipAllow adding local IP to peer list. Useful mostly for debug purposes when you may want to have multiple nodes on a single machine.
--max-connections-per-ipMaximum number of connections allowed from the same IP address.

Tor/I2P and proxies

This is experimental. It may be best to start with this guide.

OptionDescription
--tx-proxySend out your local transactions through SOCKS5 proxy (Tor or I2P). Format:
<network-type>,<socks-ip:port>[,max_connections][,disable_noise]

Example:
./monerod --tx-proxy "tx-proxy=tor,127.0.0.1:9050,16"

This was introduced to make publishing transactions over Tor easier (no need for torsocks) while allowing clearnet for blocks at the same time (while torsocks affected everything).

Adding ,disable_noise disables white noise and Dandelion++ (will speed up tx broadcast but is otherwise not recommended).

Note that forwarded transactions (those not originating from the connected wallet(s)) will still be relayed over clearnet.

Requires multiple --add-peer to manually add onion-enabled p2p seed nodes - see Tor onion seed nodes for Monero P2P network. See this guide and commit.
--anonymous-inboundAllow anonymous incoming connections to your onionized P2P interface. Format:
<hidden-service-address>,<[bind-ip:]port>[,max_connections]

Example:
./monerod --anonymous-inbound "rveahdfho7wo4b2m.onion:18083,127.0.0.1:18083,100".

Obviously, you first need to setup the hidden service in your Tor config. See the guide.
--pad-transactionsPad relayed transactions to next 1024 bytes to help defend against traffic volume analysis. This only makes sense if you are behind Tor or I2P. See commit.
--proxyNetwork communication through proxy. Works with any service that supports SOCKS4, including Tor, i2p, and commercial VPN/proxy services. SOCKS5 support is anticipated in the future. Enabling this setting sends all traffic through this proxy. Can be used in conjunction with --tx-proxy, in which case transaction broadcasts originating from the connected wallet(s) will be sent through Tor or i2p as specified in --tx-proxy, and all other traffic will be sent through the SOCKS proxy. Format:
<socks-ip:port>

Node RPC API

monerod node offers powerful API. It serves 3 purposes:

  • provides network data (stats, blocks, transactions, …)
  • provides local node information (peer list, hash rate if mining, …)
  • provides interface for wallets (send transactions, …)

This API is typically referred to as “RPC” because it is mostly based on JSON/RPC standard.

The following options define how the API behaves.

OptionDescription
--public-nodeAdvertise to other users they can use this node as a remote one for connecting their wallets. Requires --restricted-rpc, --rpc-bind-ip and --confirm-external-bind. Without --public-node the node can still be public (assuming other relevant options are set) but won’t be advertised as such on the P2P network. This option will allow wallets to auto-discover public nodes (instead of requiring user to manually find one).
--rpc-bind-ipIP to listen on. By default 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-portTCP port to listen on. By default 18081 (mainnet), 28081 (testnet), 38081 (stagenet).
--rpc-bind-ipv6-addressIPv6 to listen on. By default ::1 (localhost). All remarks for --rpc-bind-ip are applicable here as well.
--rpc-use-ipv6Enable IPv6 for RPC server (disabled by default).
--rpc-ignore-ipv4Ignore unsuccessful IPv4 bind for RPC. Useful if you only want to use IPv6.
--rpc-restricted-bind-ipIP to listen on with the limited version of API. The limited API can be made public to create an Open Node. By default 127.0.0.1, set it to 0.0.0.0 to listen on all interfaces.
--rpc-restricted-bind-ipv6-addressIPv6 to listen on with the limited version of API. The limited API can be made public to create an Open Node. By default ::1 (localhost). Set it to :: to listen on all interfaces.
--rpc-restricted-bind-portTCP port to listen on with the limited version of API. To be used in combination with --rpc-restricted-bind-ip.
--confirm-external-bindConfirm you consciously set --rpc-bind-ip to non-localhost IP and you understand the consequences.
--restricted-rpcRestrict API to view only commands and do not return privacy sensitive data. Note this does not make sense with --rpc-restricted-bind-port because you would end up with two restricted APIs.
--rpc-sslEnable TLS on RPC connections. One of: enabled | disabled | autodetect (=autodetect by default). You should enable this if you connect a remote wallet.
--rpc-ssl-private-keyPath to server’s private key in PEM format. Generate it with monero-gen-ssl-cert tool. This is to facilitate server authentication to client.
--rpc-ssl-certificatePath to server’s certificate in PEM format. Generate it with monero-gen-ssl-cert tool. This is to facilitate server authentication to client.
--rpc-ssl-allowed-fingerprintsList of certificate fingerprints to accept. This is a way to authenticate clients.
--rpc-ssl-allow-any-certAllow any certificate of connecting client.
--rpc-ssl-ca-certificatesPath to file containing concatenated PEM format certificate(s) to replace system CA(s).
--rpc-ssl-allow-chainedAllow user chained certificates. This is only applicable if user has a “real” CA issued certificate.
--rpc-loginSpecify username[:password] required to connect to API.
--rpc-access-control-originsSpecify a comma separated list of origins to allow cross origin resource sharing. This is useful if you want to use monerod API directly from a web browser via JavaScript (say in a pure-fronted web appp scenario). With this option monerod 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.
--disable-rpc-banDo not ban hosts on RPC errors. May help to prevent monerod from banning traffic originating from the Tor daemon.
rpc-payment-addressRestrict RPC to clients sending micropayment to this address.
rpc-payment-difficultyRestrict RPC to clients sending micropayment at this difficulty in thousands.
rpc-payment-creditsRestrict RPC to clients sending micropayment, yields that many credits per payment in hundreds.
rpc-payment-allow-free-loopbackAllow free access from the loopback address (ie, the local host).

Accepting Monero

These are network notifications offered by monerod. There are also wallet notifications like --tx-notify offered by monero-wallet-rpc here.

OptionDescription
--block-notify <arg>Run a program for each new block. The <arg> must be a full path. If the <arg> contains %s it will be replaced by the block hash. Example:
./monerod --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>Run a program when the number of blocks received in the recent past deviates significantly from the expectation. The <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 Monero 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>Run a program when reorganization happens (ie, at least one block is removed from the top of the blockchain). The <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 Monero exchange or operation, you do not need to bother with this option. Simply account for reorganizations by requiring at least 10 confirmations before shipping valuable goods.

Performance

These are advanced options that allow you to optimize performance of your monerod node, sometimes at the expense of reliability.

OptionDescription
--prune-blockchainPruning saves 2/3 of disk space w/o degrading functionality. For maximum effect this should be used already on the first sync. If you add this option later the past data will only be pruned logically w/o shrinking the file size and the gain will be delayed.

If you already have unpruned blockchain, see the monero-blockchain-prune tool.

The drawback is that you will contribute less to Monero P2P network in terms of helping new nodes to sync up (up to 1/8 of normal contribution). You will still be useful regarding relaying new transactions and blocks though.
--sync-pruned-blocksAccept pruned blocks instead of pruning yourself. It should save network transfer when used with --prune-blockchain. See the commit and comments.
--db-sync-modeSpecify sync option, using format:
[safe|fast|fastest]:[sync|async]:[<nblocks_per_sync>[blocks]|<nbytes_per_sync>[bytes]]

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 monerod crashes. If you are concerned with system crashes use safe:sync.
--max-concurrencyMax number of threads to use for parallel jobs. The default value 0 uses the number of CPU threads.
--prep-blocks-threadsMax number of threads to use when computing block hashes (PoW) in groups. Defaults to 4. Decrease this if you don’t want monerod hog your computer when syncing.
--fast-block-syncSync up most of the way by using embedded, “known” block hashes. Pass 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 RandomX PoW used in Monero is very expensive (even for verification), monerod offers skipping these calculations for old blocks. In other words, it’s a mechanism to trust monerod binary regarding old blocks’ PoW validity, to sync up faster.
--block-sync-sizeHow many blocks are processed in a single batch during chain synchronization. By default this is 20 blocks for newer history and 100 blocks for older history (“pre v4”). Default behavior is represented by value 0. Intuitively, the more resources you have, the bigger batch size you may want to try out. Example:
./monerod --block-sync-size=500
--bootstrap-daemon-addressThe host:port of a “bootstrap” remote open node that the connected wallets can use while this node is still not fully synced. Example:
./monerod --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-loginSpecify username:password for the bootstrap daemon login (if required). This considers the RPC interface used by the wallet. Normally, open nodes do not require any credentials.
--no-syncDo not sync up. Continue using bootstrap daemon instead (if set). See commit.

Mining

The following options configure solo mining using CPU with the standard software stack monerod. This is mostly useful for:

  • generating your stagenet or testnet coins
  • experimentation and learning
  • if you have access to vast CPU resources

Be advised though that real mining happens in pools like p2pool, and with dedicated miner software like xmrig.

OptionDescription
--start-miningSpecify wallet address to mining for. This must be a standard address! It can be neither a subaddres nor integrated address.
--mining-threadsSpecify mining threads count. By default ony one thread will be used. For best results, set it to number of your physical cores.
--extra-messages-fileSpecify file for extra messages to include into coinbase transactions.
--bg-mining-enableEnable unobtrusive mining. In this mode mining will use a small percentage of your system resources to never noticeably slow down your computer. This is intended to encourage people to mine to improve decentralization. That being said chances of finding a block are diminishingly small with solo CPU mining, and even lesser with its unobtrusive version. You can tweak the unobtrusivness / power trade-offs with the further --bg-* options below.
--bg-mining-ignore-batteryIf true, assumes plugged in when unable to query system power status.
--bg-mining-min-idle-intervalSpecify min lookback interval in seconds for determining idle state.
--bg-mining-idle-thresholdSpecify minimum avg idle percentage over lookback interval.
--bg-mining-miner-targetSpecify maximum percentage cpu use by miner(s).

Testing Monero itself

These options are useful for Monero project developers and testers. Normal users shouldn’t be concerned with these.

OptionDescription
--keep-alt-blocksKeep alternative blocks on restart. May help with researching reorgs etc. Commit. Research project by noncesense research lab.
--test-drop-downloadFor net tests: in download, discard ALL blocks instead checking/saving them (very fast).
--test-drop-download-heightLike test-drop-download but discards only after around certain height. By default 0.
--regtestRun in a regression testing mode.
--keep-fakechainDon’t delete any existing database when in fakechain mode.
--fixed-difficultyFixed difficulty used for testing. By default 0.
--test-dbg-lock-sleepSleep time in ms, defaults to 0 (off), used to debug before/after locking mutex. Values 100 to 1000 are good for tests.

Legacy

These options should no longer be necessary. They are still present in monerod for backwards compatibility.

OptionDescription
--ban-listSpecify ban list file, one IP address per line. This was introduced as an emergency measure to deal with large DDoS attacks on Monero p2p network in Dec 2020 / Jan 2021. Example:
./monerod --ban-list=block.txt. Here is the popular block.txt file.

It is not recommended to statically ban any IP addresses unless you absolutely need to. Banning IPs often excludes the most vulnerable users who are forced to operate entirely behind Tor or other anonymity networks.
--enable-dns-blocklistSimilar to --ban-list but instead of a static file uses dynamic IP blocklist available as DNS TXT entries. The DNS blocklist is centrally managed by Monero contributors. It is not recommended unless in emergency situations.
--fluffy-blocksRelay compact blocks. Default. Compact block is just a header and a list of transaction IDs.
--no-fluffy-blocksRelay classic full blocks. Classic block contains all transactions.
--show-time-statsOfficial docs say “Show time-stats when processing blocks/txs and disk synchronization” but it does not seem to produce any output during usual blockchain synchronization.
--zmq-rpc-bind-ipIP for ZMQ RPC server to listen on. By default 127.0.0.1. This is not yet widely used as ZMQ interface currently does not provide meaningful advantage over classic JSON-RPC interface.
--zmq-rpc-bind-portPort for ZMQ RPC server to listen on. By default 18082 for mainnet, 38082 for stagenet, and 28082 for testnet.
--zmq-pubAddress for ZMQ pub - tcp://ip:port or ipc://path
--db-typeSpecify database type. The default and only available: lmdb.

Commands

Commands give access to specific services provided by the daemon. Commands are executed against the running daemon. Their names follow the command_name pattern.

The following groups are only to make reference easier to follow. The daemon itself does not group commands in any way.

See running for example usage. You can also type commands directly in the console of the running monerod (if not detached).

Help, version, status

OptionDescription
help [<command>]Show help for <command>.
versionShow version information. Example output:
Monero 'Boron Butterfly' (v0.14.0.0-release)
statusShow status. Example output:
Height: 186754/186754 (100.0%) on stagenet, not mining, net hash 317 H/s, v9, up to date, 8(out)+0(in) connections, uptime 0d 3h 48m 47s

P2P network

OptionDescription
print_plShow the full peer list.
print_pl_statsShow the full peer list statistics (white vs gray peers). White peers are any peers your node has completed a handshake with. Grey nodes are nodes that your node hasn’t tried to connect to yet.
print_cnShow connected peers with connection initiative (incoming/outgoing) and other stats.
ban <IP> [<seconds>]Ban a given <IP> for a given amount of <seconds>. By default the ban is for 24h. Example:
./monerod ban 187.63.135.161.
unban <IP>Unban a given <IP>.
bansShow the currently banned IPs. Example output:
187.63.135.161 banned for 86397 seconds.
in_peers <max_number>Set the of incoming connections from other peers.
out_peers <max_number>Set the of outgoing connections to other peers.
limit [<kB/s>]Get or set the download and upload limit.
limit_down [<kB/s>]Get or set the download limit.
limit_up [<kB/s>]Get or set the upload limit.

Transaction pool

OptionDescription
flush_txpool [<txid>]Flush specified transaction from transactions pool, or flush the whole transactions pool if was not provided.
print_poolPrint the transaction pool using a verbose format.
print_pool_shPrint the transaction pool using a short format.
print_pool_statsPrint the transaction pool’s statistics (number of transactions, memory size, fees, double spend attempts etc).

Transactions

OptionDescription
print_coinbase_tx_sum <start_height> [<block_count>]Show a sum of all emitted coins and paid fees within specified range. Example:
./monerod print_coinbase_tx_sum 0 1000000000000
print_tx <transaction_hash> [+hex] [+json]Show specified transaction as JSON and/or HEX.
relay_tx <txid>Force relaying the transaction. Useful if you want to rebroadcast the transaction for any reason or if transaction was previously created with “do_not_relay”:true.

Blockchain

OptionDescription
print_heightShow local blockchain height.
sync_infoShow blockchain sync progress and connected peers along with download / upload stats.
print_bc <begin_height> [<end_height>]Show blocks in range <begin_height>..<end_height>. The information will include block id, height, timestamp, version, size, weight, number of non-coinbase transactions, difficulty, nonce, and reward.
print_block <block_hash> | <block_height>Show detailed data of specified block.
hard_fork_infoShow current consensus version and future hard fork block height, if any.
is_key_image_spent <key_image>Check if specified key image is spent. Key image is a hash.

Manage daemon

OptionDescription
exit, stop_daemonAsk daemon to exit gracefully. The exit and stop_daemon are identical (one is alias of the other).
set_log <level>|<{+,-,}categories>Set the current log level/categories where <level> is a number 0-4.
print_statusShow if daemon is running.
update (check|download)Check if update is available and optionally download it. The hash is SHA-256. On linux use sha256sum to verify. Example output:
Update available: v0.13.0.4: https://downloads.getmonero.org/cli/monero-linux-x64-v0.13.0.4.tar.bz2, hash 693e1a0210201f65138ace679d1ab1928aca06bb6e679c20d8b4d2d8717e50d6
Update downloaded to: /opt/monero-v0.13.0.2/monero-linux-x64-v0.13.0.4.tar.bz2

Mining

OptionDescription
show_hrAsk monerod daemon to print current hash rate. Relevant only if monerod is mining.
hide_hrAsk monerod daemon to stop printing current hash rate. Relevant only if monerod is mining.
start_mining <addr> [<threads>] [do_background_mining] [ignore_battery]Ask moneroddaemon to start mining. Block reward will go to <addr>.
stop_miningAsk monerod daemon to stop mining.

Testing Monero itself

OptionDescription
start_save_graphStart saving data for dr Monero.
stop_save_graphStop saving data for dr Monero.

Legacy

OptionDescription
saveFlush blockchain data to disk. This is normally no longer necessary as monerod saves the blockchain automatically on exit.
output_histogram [@<amount>] <min_count> [<max_count>]Show number of outputs for each amount denomination. This was only relevant in the pre-RingCT era. The old wallet used this to determine which outputs can be used for the requested mixin. With RingCT denominations are irrelevant as amounts are hidden. More info in these SA answers.