mirror of
https://github.com/monero-project/monero-docs.git
synced 2024-10-30 02:47:35 +00:00
Add monerod options reference reegarding RPC API
This commit is contained in:
parent
6716502415
commit
0f59b2f50a
2 changed files with 27 additions and 7 deletions
|
@ -32,6 +32,7 @@ Following option groups are only to make this reference easier to follow. The da
|
|||
| `--log-file` | Full path to the log file. Example (mind file permissions): <br/>`./monerod --log-file=/var/log/monero/mainnet/monerod.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: <br />`./monerod --log-level=1`
|
||||
| `--max-log-file-size` | Soft limit in bytes for the log file (=104850000 by default, which is just under 100MB). Once log file grows past that limit, `monerod` creates next log file with a `-YYYY-MM-DD-HH-MM-SS` UTC timestamp postfix. In production deployments, you would probably prefer to use established solutions like logrotate instead.
|
||||
| `--max-log-files` | Limit 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
|
||||
|
||||
|
@ -45,16 +46,16 @@ The following options will be helpful if you intend to have an always running no
|
|||
| `--data-dir` | Full path to data directory. This is where the blockchain, log files, and p2p network memory are stored. For defaults and details see [data directory](/interacting/monerod/overview/#data-directory).
|
||||
| `--pidfile` | Full path to the PID file. Works only with `--detach`. Example: <br />`./monerod --detach --pidfile=/run/monero/monerod.pid`
|
||||
| `--detach` | Go 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-interactive` | Do 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 getss 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).
|
||||
| `--non-interactive` | Do 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-igd` | Disable 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-size arg` | Set maximum transactions pool size in bytes. By default 648000000 (~618MB). These are transactions pending for confirmations (not included in any block).
|
||||
| `--max-txpool-weight` | Set maximum transactions pool size in bytes. By default 648000000 (~618MB). These are transactions pending for confirmations (not included in any block).
|
||||
| `--enforce-dns-checkpointing` | The emergency checkpoints set by [MoneroPulse](/infrastructure/monero-pulse.md) operators will be enforced. It is probably a good idea to set enforcing for unattended nodes. <br /><br />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.<br /><br />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`.<br /><br />Reference: [source code](https://github.com/monero-project/monero/blob/22a6591a70151840381e327f1b41dc27cbdb2ee6/src/cryptonote_core/blockchain.cpp#L3614).
|
||||
| `--disable-dns-checkpoints` | The [MoneroPulse](/infrastructure/monero-pulse.md) 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.
|
||||
This is for node-to-node communication. The following options do **not** affect [wallet-to-node](#node-rpc-api) interface.
|
||||
|
||||
The node and peer words are used interchangeably.
|
||||
|
||||
|
@ -76,6 +77,28 @@ The node and peer words are used interchangeably.
|
|||
| `--offline` | Do not listen for peers, nor connect to any. Useful for working with a local, archival blockchain.
|
||||
| `--allow-local-ip` | Allow adding local IP to peer list. Useful mostly for debug purposes when you may want to have multiple nodes on a single machine.
|
||||
|
||||
#### 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.
|
||||
|
||||
| Option | Description
|
||||
|---------------------------------|--------------------------------------------------------------------------------------------------------------------------------------
|
||||
| `--rpc-bind-ip` | IP 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-port` | TCP port to listen on. By default `18081` (mainnet), `28081` (testnet), `38081` (stagenet).
|
||||
| `--rpc-restricted-bind-port` | TCP port to listen on with the limited version of API. The limited API can be made public to create an Open Node. At the same time, you may firewall the full API port to still enjoy local querying and administration.
|
||||
| `--confirm-external-bind` | Confirm you consciously set `--rpc-bind-ip` to non-localhost IP and you understand the consequences.
|
||||
| `--restricted-rpc` | Restrict 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-login` | Specify `username[:password]` required to connect to API. Practical usage seems limited because API communication is in plain text over HTTP.
|
||||
| `--rpc-access-control-origins` | Specify a comma separated list of origins to allow cross origin resource sharing.
|
||||
|
||||
#### Speed nad Reliability
|
||||
|
||||
| Option | Description
|
||||
|
@ -116,7 +139,7 @@ These options should no longer be necessary. They are still present in `monerod`
|
|||
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------
|
||||
| `--fluffy-blocks` | Relay compact blocks. Default. Compact block is just a header and a list of transaction IDs.
|
||||
| `--no-fluffy-blocks` | Relay classic full blocks. Classic block contains all transactions.
|
||||
| `--show-time-stats` | Official 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.
|
||||
| `--show-time-stats` | Official 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-ip` | IP 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. Unfortunately, currently there is no way to disable the ZMQ server.
|
||||
| `--zmq-rpc-bind-port` | Port for ZMQ RPC server to listen on. By default `18082` for mainnet, `38082` for stagenet, and `28082` for testnet.
|
||||
| `--db-type` | Specify database type. The default and only available: `lmdb`.
|
||||
|
@ -129,7 +152,6 @@ These options should no longer be necessary. They are still present in `monerod`
|
|||
| `--version` | Shows `monerod` version to stdout. Example: <br />`Monero 'Lithium Luna' (v0.12.3.0-release)`
|
||||
| `--os-version` | Shows build timestamp and target operating system. Example output:<br />`OS: Linux #1 SMP PREEMPT Fri Aug 24 12:48:58 UTC 2018 4.18.5-arch1-1-ARCH`.
|
||||
|
||||
--zmq-rpc-bind-ip
|
||||
## Reference
|
||||
|
||||
* [Reddit answer](https://www.reddit.com/r/Monero/comments/3jhyqc/0mq_help_share_this_exciting_news/)
|
||||
|
|
|
@ -47,8 +47,6 @@ Every participants sends his second round of init data to all other participants
|
|||
|
||||
Every participant finalizes wallet creation by applying the second round of init data from all other participants. This finally results in a wallet **public address** and **private view key** to be known for all participants.
|
||||
|
||||
|
||||
|
||||
Please note actions are symmetric for all participants. Even though we considered a 2-of-3 scheme, every participant cooperates with everyone else. The secret splitting is performed internally by the wallet.
|
||||
|
||||
Secure sharing of initialization data between participants is manual. The wallet itself does not provide any secure communication channel. This is out of scope.
|
||||
|
|
Loading…
Reference in a new issue