monero-project/monero-docs
monero-project/monero-docs
2
1
Fork 0
mirror of https://github.com/monero-project/monero-docs.git synced 2024-12-22 19:49:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

monerod: update tor setup

Browse source 
- remove outdated tor seed info
- update tx-proxy definition
- update tor setup
This commit is contained in:
nahuhh 2024-09-13 21:52:49 +00:00
parent ac3bb0670f
commit e57537efcf
4 changed files with 223 additions and 255 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

78
docs/en/infrastructure/tor-onion-p2p-seed-nodes.md
View file

@ -1,78 +0,0 @@
---
title: Tor Onion Seed Nodes for Monero P2P Network
---
# Tor onion seed nodes for Monero network
## When this is necessary?
This is only necessary if you run a full node and you want to propagate locally-originating transactions over Tor (using `tx-proxy` option, see [monerod reference](/interacting/monerod-reference/#tori2p)). This allows you to mask your IP (as transaction originator) against P2P network surveillence, on top of Monero's built-in Dandelion++.
## What are P2P seed nodes?
Your monero daemon will discover other P2P nodes but it needs to start somewhere. These starting nodes are known as "seed nodes". For clearnet the seed nodes are hardcoded in the software so no configuration is needed.
For the Tor network there are no hardcoded seed nodes. You must specify them manually by using the `add-peer` option in `monero.conf`.
## Config snippet
These were tested working as of 2020-01-11. They are ran by volunteers and are **not guaranteed** to work or be maintained. See below how you can quickly test them.
```
# monero.conf snippet
# ...
add-peer=moneroxmrxw44lku6qniyarpwgznpcwml4drq7vb24ppatlcg4kmxpqd.onion:18080
add-peer=monerozf6koypqrt.onion:18080
add-peer=zbjkbsxc5munw3qusl7j2hpcmikhqocdf4pqhnhtpzw5nt5jrmofptid.onion:18083 # https://github.com/monero-project/monero/blob/master/src/p2p/net_node.inl
add-peer=rno75kjcw3ein6i446sqby2xkyqjarb75oq36ah6c2mribyklzhurpyd.onion:28083 # it is mainnet despite the weird port
add-peer=sqzrokz36lgkng2i2nlzgzns2ugcxqosflygsxbkybb4xn6gq3ouugqd.onion:18083 # very flaky, works 1 in 3 times
add-peer=blzchctiibfjfvtukctsydhquucz2oajnxnfc5hh4ix35gyqjhdnaqqd.onion:18083 # full node by author of monerodocs.org
# ...
```
## How to test onion seed nodes?
You need Tor daemon installed and running on your laptop. You will also need `torsocks` command line tool that either comes with Tor or needs to be installed separately.
### Test using torsocks and telnet
You need tor, torsocks and telnet installed.
To test speficic onion:
torsocks telnet moneroxmrxw44lku6qniyarpwgznpcwml4drq7vb24ppatlcg4kmxpqd.onion 18080
The expected output (domain resolution errors are fine):
```
1610372702 ERROR torsocks[11332]: Unable to resolve. Status reply: 4 (in socks5_recv_resolve_reply() at socks5.c:677)
Trying 127.42.42.0...
Connected to moneroxmrxw44lku6qniyarpwgznpcwml4drq7vb24ppatlcg4kmxpqd.onion.
Escape character is '^]'.
```
### Test using torsocks and proxychains
You need tor, torsocks and proxychains installed.
To test specific onion:
proxychains nmap -Pn -p 18080 moneroxmrxw44lku6qniyarpwgznpcwml4drq7vb24ppatlcg4kmxpqd.onion
The expected output (example):
````
[proxychains] Strict chain ... 127.0.0.1:9050 ... moneroxmrxw44lku6qniyarpwgznpcwml4drq7vb24ppatlcg4kmxpqd.onion:18080 ... OK
Nmap scan report for moneroxmrxw44lku6qniyarpwgznpcwml4drq7vb24ppatlcg4kmxpqd.onion (224.0.0.1)
Host is up (0.74s latency).
rDNS record for 224.0.0.1: all-systems.mcast.net
PORT STATE SERVICE
18080/tcp open unknown
````
## Not enough onion seed nodes
The onion seed nodes are a scarce resource. Most nodes are only maintained temporarily by their authors.
You can greatly contribute to Monero P2P network performance and resillience by running onion-enabled monero full node.

50
docs/en/interacting/monerod-reference.md
View file

@ -63,8 +63,8 @@ The following groups are only to make reference easier to follow. The daemon its
| Option | Description
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------
| `--help` | Enlist available options.
| `--version` | Show `monerod` version to stdout. Example output: <br />`Monero 'Oxygen Orion' (v0.17.1.8-release)`
| `--os-version` | Show build timestamp and target operating system. Example output:<br />`OS: Linux #65-Ubuntu SMP Thu Dec 10 12:01:51 UTC 2020 5.4.0-59-generic`.
| `--version` | Show `monerod` version to stdout. Example output: <br>`Monero 'Oxygen Orion' (v0.17.1.8-release)`
| `--os-version` | Show build timestamp and target operating system. Example output:<br>`OS: Linux #65-Ubuntu SMP Thu Dec 10 12:01:51 UTC 2020 5.4.0-59-generic`.
| `--check-updates` | One 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)
@ -80,8 +80,8 @@ The following groups are only to make reference easier to follow. The daemon its
| Option | Description
|-----------------------|----------------------------------------------------------------------------------------------------------------------------------------
| `--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 the next log file with a UTC timestamp postfix `-YYYY-MM-DD-HH-MM-SS`.<br /><br />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.
| `--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 the next log file with a UTC timestamp postfix `-YYYY-MM-DD-HH-MM-SS`.<br><br>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-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
@ -94,13 +94,13 @@ The following options will be helpful if you intend to have an always running no
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------
| `--config-file` | Full path to the [configuration file](/interacting/monero-config-file). By default `monerod` looks for `bitmonero.conf` in Monero [data directory](/interacting/overview/#data-directory).
| `--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/overview/#data-directory).
| `--pidfile` | Full path to the PID file. Works only with `--detach`. Example: <br />`./monerod --detach --pidfile=/run/monero/monerod.pid`
| `--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 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-zmq` | Disable 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-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-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) 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).
| `--enforce-dns-checkpointing` | The emergency checkpoints set by [MoneroPulse](/infrastructure/monero-pulse) 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) checkpoints set by core developers will be discarded. The checkpoints are apparently still fetched though.
#### P2P network
@ -112,7 +112,7 @@ The node and peer words are used interchangeably.
| Option | Description
|------------------------|--------------------------------------------------------------------------------------------------------------------------------------
| `--p2p-bind-ip` | IPv4 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. <br /><br />You must change this if you want to constrain binding, for example to force working through Tor via torsocks: <br />`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-ip` | IPv4 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. <br><br>You must change this if you want to constrain binding, for example to force working through Tor via torsocks: <br>`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-port` | TCP 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: <br/>`./monerod --p2p-bind-port=48080`
| `--p2p-external-port` | TCP 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-ipv6` | Enable IPv6 for p2p (disabled by default).
@ -123,8 +123,8 @@ The node and peer words are used interchangeably.
| `--hide-my-port` | `monerod` 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` | Connect 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-peer` | Manually add node to local peer list, `host:port`. Syntax supports IP addresses, domain names, onion and i2p hosts.
| `--add-priority-node` | Specify list of nodes to connect to and then attempt to keep the connection open. <br /><br />To add multiple nodes use the option several times. Example: <br />`./monerod --add-priority-node=178.128.192.138:18081 --add-priority-node=144.76.202.167:18081`
| `--add-exclusive-node` | Specify list of nodes to connect to only. If this option is given the options `--add-priority-node` and `--seed-node` are ignored. <br /><br />To add multiple nodes use the option several times. Example: <br />`./monerod --add-exclusive-node=178.128.192.138:18081 --add-exclusive-node=144.76.202.167:18081`
| `--add-priority-node` | Specify list of nodes to connect to and then attempt to keep the connection open. <br><br>To add multiple nodes use the option several times. Example: <br>`./monerod --add-priority-node=178.128.192.138:18081 --add-priority-node=144.76.202.167:18081`
| `--add-exclusive-node` | Specify list of nodes to connect to only. If this option is given the options `--add-priority-node` and `--seed-node` are ignored. <br><br>To add multiple nodes use the option several times. Example: <br>`./monerod --add-exclusive-node=178.128.192.138:18081 --add-exclusive-node=144.76.202.167:18081`
| `--out-peers` | Set max number of outgoing connections to other nodes. By default 12. Value `-1` represents the code default.
| `--in-peers` | Set max number of incoming connections (nodes actively connecting to you). By default unlimited. Value `-1` represents the code default.
| `--limit-rate-up` | Set outgoing data transfer limit [kB/s]. By default 2048 kB/s. Value `-1` represents the code default.
@ -140,10 +140,10 @@ This is experimental. It may be best to start with this [guide](https://github.c
| Option | Description
|------------------------|--------------------------------------------------------------------------------------------------------------------------------------
| `--tx-proxy` | Send out your local transactions through SOCKS5 proxy (Tor or I2P). Format:<br />`<network-type>,<socks-ip:port>[,max_connections][,disable_noise]` <br /><br />Example:<br />`./monerod --tx-proxy "tx-proxy=tor,127.0.0.1:9050,16"`<br /><br />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).<br /><br />Adding `,disable_noise` disables white noise and Dandelion++ (will speed up tx broadcast but is otherwise not recommended). <br /><br />Note that forwarded transactions (those not originating from the connected wallet(s)) will still be relayed over clearnet.<br /><br />**Requires multiple `--add-peer`** to manually add onion-enabled p2p seed nodes - see [Tor onion seed nodes for Monero P2P network](/infrastructure/tor-onion-p2p-seed-nodes). See this [guide](https://github.com/monero-project/monero/blob/master/docs/ANONYMITY_NETWORKS.md#p2p-commands) and [commit](https://github.com/monero-project/monero/pull/6021).
| `--anonymous-inbound` | Allow anonymous incoming connections to your onionized P2P interface. Format: <br />`<hidden-service-address>,<[bind-ip:]port>[,max_connections]`<br /><br />Example:<br />`./monerod --anonymous-inbound "rveahdfho7wo4b2m.onion:18083,127.0.0.1:18083,100"`.<br /><br />Obviously, you first need to setup the hidden service in your Tor config. See the [guide](https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md#p2p-commands).
| `--tx-proxy` | Send out your local transactions through SOCKS5 proxy (Tor or I2P). Format:<br>`<network-type>,<socks-ip:port>[,max_connections][,disable_noise]` <br><br>Example:<br>`./monerod --tx-proxy "tx-proxy=tor,127.0.0.1:9050,16"`<br><br>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).<br><br>Adding `,disable_noise`: If the user disables "noise" (i.e. `--tx-proxy=tor,127.0.0.1:9050,disable_noise`), then the tx is "fluffed" to outbound Onion and I2P peers, and the receiving hidden service will immediately fluff the transaction to ipv4/6 peers. This will speed up tx broadcast. [more info](https://github.com/monero-project/monero/pull/6354#pullrequestreview-399554356)<br><br>Note that forwarded transactions (those not originating from the connected wallet(s)) will still be relayed over clearnet.<br>See this [guide](https://github.com/monero-project/monero/blob/master/docs/ANONYMITY_NETWORKS.md#p2p-commands) and [commit](https://github.com/monero-project/monero/pull/6021).
| `--anonymous-inbound` | Allow anonymous incoming connections to your onionized P2P interface. Format: <br>`<hidden-service-address>,<[bind-ip:]port>[,max_connections]`<br><br>Example:<br>`./monerod --anonymous-inbound "rveahdfho7wo4b2m.onion:18083,127.0.0.1:18083,100"`.<br><br>Obviously, You first need to setup the hidden service in your Tor config. See the [guide](https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md#p2p-commands).
| `--pad-transactions` | Pad 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](https://github.com/monero-project/monero/pull/4787).
| `--proxy` | Network 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:<br />`<socks-ip:port>`
| `--proxy` | Network 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:<br>`<socks-ip:port>`
#### Node RPC API
@ -193,9 +193,9 @@ These are network notifications offered by `monerod`. There are also wallet noti
| Option | Description
|------------------------------|------------------------------------------------------------------------------------------------
| `--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: <br />`./monerod --block-notify="/usr/bin/echo %s"`<br /><br />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. <br /><br />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: <br /><br >`%t`: the number of minutes in the observation window<br /><br >`%b`: the number of blocks observed in that window<br /><br >`%e`: the ideal number of blocks expected in that window<br /><br > 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.<br /><br />**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: <br /><br >`%s`: the height at which the split occurs <br /><br />`%h`: the height of the new blockchain<br /><br />`%d`: the number of blocks discarded from the old chain <br /><br />`%n`: the number of blocks being added <br /><br /> 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). <br /><br />**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.
| `--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: <br>`./monerod --block-notify="/usr/bin/echo %s"`<br><br>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. <br><br>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: <br><br>`%t`: the number of minutes in the observation window<br><br>`%b`: the number of blocks observed in that window<br><br>`%e`: the ideal number of blocks expected in that window<br><br> 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.<br><br>**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: <br><br>`%s`: the height at which the split occurs <br><br>`%h`: the height of the new blockchain<br><br>`%d`: the number of blocks discarded from the old chain <br><br>`%n`: the number of blocks being added <br><br> 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). <br><br>**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
@ -203,13 +203,13 @@ These are advanced options that allow you to optimize performance of your `moner
| Option | Description
|---------------------------------|--------------------------------------------------------------------------------------------------------------------------------------
| `--prune-blockchain` | Pruning 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. <br /><br />If you already have unpruned blockchain, see the `monero-blockchain-prune` tool. <br /><br />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.
| `--prune-blockchain` | Pruning 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. <br><br>If you already have unpruned blockchain, see the `monero-blockchain-prune` tool. <br><br>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-blocks` | Accept pruned blocks instead of pruning yourself. It should save network transfer when used with `--prune-blockchain`. See the [commit](https://github.com/monero-project/monero/commit/8330e772f1ed680a54833d25c4d17d09a99ab8d6) and [comments](https://web.getmonero.org/2019/09/08/logs-for-the-dev-meeting-held-on-2019-09-08.html).
| `--db-sync-mode` | Specify sync option, using format:<br />`[safe|fast|fastest]:[sync|async]:[<nblocks_per_sync>[blocks]|<nbytes_per_sync>[bytes]]`<br /><br />The default is `fast:async:250000000bytes`.<br /><br />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`.
| `--db-sync-mode` | Specify sync option, using format:<br>`[safe|fast|fastest]:[sync|async]:[<nblocks_per_sync>[blocks]|<nbytes_per_sync>[bytes]]`<br><br>The default is `fast:async:250000000bytes`.<br><br>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-concurrency` | Max number of threads to use for parallel jobs. The default value `0` uses the number of CPU threads.
| `--prep-blocks-threads` | Max 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-sync` | Sync 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-size` | How 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:<br />`./monerod --block-sync-size=500`
| `--block-sync-size` | How 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:<br>`./monerod --block-sync-size=500`
| `--bootstrap-daemon-address` | The host:port of a "bootstrap" remote open node that the connected wallets can use while this node is still not fully synced. Example:<br/>`./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-login` | Specify 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-sync` | Do not sync up. Continue using bootstrap daemon instead (if set). See [commit](https://github.com/monero-project/monero/pull/5195).
@ -256,7 +256,7 @@ These options should no longer be necessary. They are still present in `monerod`
| Option | Description
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------
| `--ban-list` | Specify 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: <br />`./monerod --ban-list=block.txt`. Here is the popular [block.txt](https://gui.xmr.pm/files/block.txt) file.<br /><br />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.
| `--ban-list` | Specify 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: <br>`./monerod --ban-list=block.txt`. Here is the popular [block.txt](https://gui.xmr.pm/files/block.txt) file.<br><br>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-blocklist` | Similar 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-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.
@ -283,8 +283,8 @@ You can also type commands directly in the console of the running `monerod` (if
| Option | Description
|------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------
| `help [<command>]` | Show help for `<command>`.
| `version` | Show version information. Example output:<br />`Monero 'Boron Butterfly' (v0.14.0.0-release)`
| `status` | Show status. Example output:<br />`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`
| `version` | Show version information. Example output:<br>`Monero 'Boron Butterfly' (v0.14.0.0-release)`
| `status` | Show status. Example output:<br>`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
@ -293,9 +293,9 @@ You can also type commands directly in the console of the running `monerod` (if
| `print_pl` | Show the full peer list.
| `print_pl_stats` | Show the full peer list statistics (white vs gray peers). White peers are online and reachable. Grey peers are offline but your `monerod` remembers them from past sessions.
| `print_cn` | Show 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:<br />`./monerod ban 187.63.135.161`.
| `ban <IP> [<seconds>]` | Ban a given `<IP>` for a given amount of `<seconds>`. By default the ban is for 24h. Example:<br>`./monerod ban 187.63.135.161`.
| `unban <IP>` | Unban a given `<IP>`.
| `bans` | Show the currently banned IPs. Example output:<br />`187.63.135.161 banned for 86397 seconds`.
| `bans` | Show the currently banned IPs. Example output:<br>`187.63.135.161 banned for 86397 seconds`.
| `in_peers <max_number>` | Set the <max_number> of incoming connections from other peers.
| `out_peers <max_number>` | Set the <max_number> of outgoing connections to other peers.
| `limit [<kB/s>]` | Get or set the download and upload limit.
@ -315,7 +315,7 @@ You can also type commands directly in the console of the running `monerod` (if
| Option | Description
|------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------
| `print_coinbase_tx_sum <start_height> [<block_count>]` | Show a sum of all emitted coins and paid fees within specified range. Example:<br />`./monerod print_coinbase_tx_sum 0 1000000000000`
| `print_coinbase_tx_sum <start_height> [<block_count>]` | Show a sum of all emitted coins and paid fees within specified range. Example:<br>`./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.
@ -337,7 +337,7 @@ You can also type commands directly in the console of the running `monerod` (if
| `exit`, `stop_daemon` | Ask 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_status` | Show 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:<br />`Update available: v0.13.0.4: https://downloads.getmonero.org/cli/monero-linux-x64-v0.13.0.4.tar.bz2, hash 693e1a0210201f65138ace679d1ab1928aca06bb6e679c20d8b4d2d8717e50d6`<br/>`Update downloaded to: /opt/monero-v0.13.0.2/monero-linux-x64-v0.13.0.4.tar.bz2`
| `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:<br>`Update available: v0.13.0.4: https://downloads.getmonero.org/cli/monero-linux-x64-v0.13.0.4.tar.bz2, hash 693e1a0210201f65138ace679d1ab1928aca06bb6e679c20d8b4d2d8717e50d6`<br/>`Update downloaded to: /opt/monero-v0.13.0.2/monero-linux-x64-v0.13.0.4.tar.bz2`
#### Mining

349
docs/en/running-node/open-node-tor-onion.md
View file

@ -3,228 +3,281 @@ title: Running Monero Open Node with Tor Onion Support
---
# Running Monero Open Node + Tor Onion
!!! success "Powerful setup"
This is great contribution to Monero network and also a pretty sophisticated personal setup. If you are a beginner, you don't need this.
!!! info "The end goal"
!!! success "The end goal"
You will publicly offer the following services, where xxx.yyy.zzz.vvv is your server IP address.
* xxx.yyy.zzz.vvv:18080 - clearnet P2P service (for other nodes)
* xxx.yyy.zzz.vvv:18081 - clearnet RPC service (for wallets)
* yourlongv3onionaddress.onion:18083 - onion P2P service (for other onion nodes)
* yourlongv3onionaddress.onion:18081 - onion RPC service (for wallets connecting over Tor)
* xxx.yyy.zzz.vvv:18089 - clearnet RPC service (for wallets)
* yourlongv3onionaddress.onion:18084 - onion P2P service (for other onion nodes)
* yourlongv3onionaddress.onion:18089 - onion RPC service (for wallets connecting over Tor)
Why different P2P ports for clearnet and onion? This is a `monerod` requirement.
??? info "P2P ports"
Q: Why different P2P ports for clearnet and onion?
A: The data served by the Onion differs from clearnet P2P. A different port is required
!!! warning "Broadcasting bad transactions from your IP"
As with any public data broadcast or relay service, "bad traffic" or in this case "bad transactions" may appear to originate from your server IP address from an outside observer perspective - even though they really originate from a remote wallet user. This is a potential risk you need to keep in mind.
??? warning "May be resource intensive"
Providing a Public RPC may use a sizeable amount of resources on your PC.
If you have concerns about data/bandwidth, CPU or RAM usage, you may disable the `public-node` setting by commenting [#] or deleting the line from the [config](#config)
## Why run this specific setup?
You will be able to connect your desktop and mobile Monero wallets to your own trusted Monero node,
in a secure and private way over Tor. Your node will be always ready w/o delays (always synced up, contrary to intermittently running node on a laptop).
in a secure and private way over Tor.
**Running as a systemd service** will allow your node to always remain synced, as opposed to intermittently running node.
**Serving blocks and transactions** in Monero P2P network helps new users to bootstrap and sync up their nodes.
It also strenghtens Monero P2P network against DDoS attacks and network partitioning.
**Open wallet inteface** (the "RPC") allows anyone to connect their wallets to Monero network through your node.
This is useful for beginner users who don't run their own nodes yet.
**Open wallet inteface** - The `public-node` config option allows anyone to connect their wallets to Monero network through your node.
This is useful to users who don't run their own nodes.
**Tor onion for wallet interface** is useful for wallet users connecting over Tor because it mitigates Tor exit nodes MiTM risks (which are very real). By connecting wallet to an onion service, no MiTM attack is realistic because within the Tor network connections are end-to-end TLS-ed.
**Tor onion for wallet interface** is useful for wallet users connecting over Tor because it mitigates Clearnet and Tor exit node MiTM risks (which are very real). By connecting wallet to an onion service, no MiTM attack is realistic because onion connections are end-to-end encrypted.
**Tor onion for P2P network** is useful for other full node users as it allows them to broadcast transactions over Tor (using `--tx-proxy` option).
## Assumptions
You understand basic Linux administration. You seek Monero specific guidance.
You possess:
You have root access to a Linux server with 2GB+ RAM and 120GB+ SSD (or 50GB+ for the pruned node version). This is current for Jan 2021.
- Basic understanding of Linux administration
- Root access to a Linux server
- _Recommended_ 4 GB+ RAM
- _Recommended_ available SSD storage of
- **{{ multiply(lmdb_size_full, 2.5) }} GB+** for the full node
- **{{ multiply(lmdb_size_pruned, 2.5) }} GB+** for the pruned.
!!! note "Current blockchain size as of {{ lmdb_size_updated }}"
The current blockchain sizes are approximately:
Full node: **{{ lmdb_size_full }} GB**
Pruned node: **{{ lmdb_size_pruned }} GB**
Some commands assume Ubuntu but you will easily translate them to your distribution.
## Install Tor
[Install Tor](https://2019.www.torproject.org/docs/debian.html.en#ubuntu).
1. [Install Tor](https://support.torproject.org/apt)
Modify `/etc/tor/torrc` as shown below.
2. Elevate to root:
Enable tor service with `systemctl enable tor` and restart it via `systemctl restart tor`
``` Bash
sudo su -
```
Verify the Tor is up `systemctl status tor@default`
3. Add the following lines to `/etc/tor/torrc`:
A fresh onion address and corresponding key pair got created for you by the `tor` daemon in `/var/lib/tor/monero/`. You may want to backup these to secure control over your onion address. This happens on restart whenever you add new `HiddenServiceDir` to `torrc` config.
``` ApacheConf
HiddenServiceDir /var/lib/tor/monerod
HiddenServicePort 18089 127.0.0.1:18089 # interface for wallet ("RPC")
HiddenServicePort 18084 127.0.0.1:18084 # interface for P2P network
```
Monero daemon itself is not necessary at this point. The onion services (AKA hidden services) will just wait until localhost `monerod` shows up at specified ports 18081 and 18083.
4. Enable tor service:
### /etc/tor/torrc
``` Bash
systemctl enable tor
systemctl restart tor
```
``` ApacheConf
HiddenServiceDir /var/lib/tor/monero
HiddenServicePort 18081 127.0.0.1:18081 # interface for wallet ("RPC")
HiddenServicePort 18083 127.0.0.1:18083 # interface for P2P network
```
5. Verify the Tor is running:
``` Bash
systemctl status tor@default
```
6. View/Copy your new Onion Address:
``` Bash
cat /var/lib/tor/monerod/hostname
```
??? info "Backup Onion keys"
You may want to backup your keys folder (`/var/lib/tor/monerod`) to secure control over your onion address.
??? info "How Tor onion services work?"
The `tor` daemon will simply pass over the traffic from virtual onion port to actual localhost port, where some service is listening (in our case, this will be `monerod`). A single onion address can offer multiple services at various virtual ports. We will use this to expose both P2P and RPC `monerod` services on a single onion. You could host any number of onion addresses at single server or IP address but we won't need that here.
A fresh onion address and corresponding key pair were created for you in /var/lib/tor/monero/.
This happens on restart whenever you add a new `HiddenServiceDir` to the `/etc/tor/torrc` config file.
The tor daemon will forward traffic from a virtual onion port to an actual localhost port, where some service is listening (in our case, this will be `monerod`).
A single onion address can offer multiple services at various virtual ports.
## Install Monero
Create `monero` user and group `useradd --system monero`
1. Create `monero` user and group:
Create monero **binaries** directory (empty for now) `mkdir -p /opt/monero` and `chown -R monero:monero /opt/monero`
``` Bash
useradd --system monero
```
Create monero **data** directory `mkdir -p /srv/monero` and `chown -R monero:monero /srv/monero`
2. Create monero **config**, **data** and **log** directories:
Create monero **log** directory `mkdir -p /var/log/monero` and `chown -R monero:monero /var/log/monero`
``` Bash
mkdir -p /etc/monero # config
mkdir -p /var/lib/monero # blockchain
mkdir -p /var/log/monero # logs
chown monero:monero /etc/monero
chown monero:monero /var/lib/monero
chown monero:monero /var/log/monero
```
Feel free to adjust above to your preferred conventions, just remember to adjust the paths accordingly.
Feel free to adjust above to your preferred conventions, just remember to adjust the paths in the `systemd` and `monerod` config files accordingly.
[Download](/interacting/download-monero-binaries/) and [verify](/interacting/verify-monero-binaries/) the file.
3. [Download](../interacting/download-monero-binaries.md) and [verify](../interacting/verify-monero-binaries.md) the archive.
Extract `tar -xf monero-linux-x64-v0.17.1.9.tar.bz2` (adjust filename).
4. Extract the binaries (adjust filename if necessary):
Move binaries to `/opt/monero/` with `mv monero-x86_64-linux-gnu-v0.17.1.9/* /opt/monero/` then `chown -R monero:monero /opt/monero`
``` Bash
tar -xvf monero-linux-x64-{{ cli_vers }}.tar.bz2
rm monero-linux-x64-{{ cli_vers }}.tar.bz2
```
Create `/etc/monero.conf` as shown below and **paste your values in placeholders**.
5. Move binaries to /usr/local/bin/:
Create `/etc/systemd/system/monero.service` as shown below.
``` Bash
mv monero-x86_64-linux-gnu-{{ cli_vers }}/* /usr/local/bin/.
chown monero:monero /usr/local/bin/monero*
```
Enable monero service with `systemctl enable monero` and restart it with `systemctl restart monero`
### **Monerod Config**
Verify it is up `systemctl status monero`
6. Create `/etc/monero/monerod.conf` as shown below and **replace `PASTE_YOUR_ONION_HOSTNAME` with your Onion address**.
Verify it is working as intended `tail -n100 /var/log/monero/monero.log`
``` YAML
# /etc/monero/monerod.conf
#
# Configuration file for monerod. For all available options see the MoneroDocs:
# https://docs.getmonero.org/interacting/monerod-reference/
### /etc/monero.conf
# Data directory (blockchain db and indices)
data-dir=/var/lib/monero/bitmonero
This is just an example configuration and it is by no means authoritative. Feel free to modify, see [monerod reference](/interacting/monerod-reference).
# Optional pruning
#prune-blockchain=1 # Pruning saves 2/3 of disk space w/o degrading functionality but contributes less to the network
#sync-pruned-blocks=1 # Allow downloading pruned blocks instead of prunning them yourself
Modify paths if you changed them.
# Centralized services
check-updates=disabled # Do not check DNS TXT records for a new version
enable-dns-blocklist # Block known malicious nodes
Print your onion address with `cat /var/lib/tor/monero/hostname` and paste it to `anonymous-inbound` option.
# Log file
log-file=/var/log/monero/monero.log
log-level=0 # Minimal logs, WILL NOT log peers or wallets connecting
max-log-file-size=2147483648 # Set to 2GB to mitigate log trimming by monerod; configure logrotate instead
``` YAML
# /etc/monero.conf
#
# Configuration file for monerod. For all available options see the MoneroDocs:
# https://monerodocs.org/interacting/monerod-reference/
# P2P full node
#p2p-bind-ip=0.0.0.0 # Bind to all interfaces (the default)
#p2p-bind-port=18080 # Bind to default port
#no-igd=1 # Disable UPnP port mapping
# Data directory (blockchain db and indices)
data-dir=/srv/monero
# RPC open node
public-node=1 # Advertise to other users they can use this node for connecting their wallets
rpc-restricted-bind-ip=0.0.0.0 # Bind to all interfaces (the Open Node)
rpc-restricted-bind-port=18089 # Bind to a new RESTICTED port (the Open Node)
# Optional prunning
# prune-blockchain=1 # Pruning saves 2/3 of disk space w/o degrading functionality but contributes less to the network
# sync-pruned-blocks=1 # Allow downloading pruned blocks instead of prunning them yourself
# RPC TLS
rpc-ssl=autodetect # Use TLS if client wallet supports it (Default); A new certificate will be regenerated every restart
check-updates=disabled # Do not check DNS TXT records for a new version
# ZMQ
#zmq-rpc-bind-ip=127.0.0.1 # Default 127.0.0.1
#zmq-rpc-bind-port=18082 # Default 18082
zmq-pub=tcp://127.0.0.1:18083 # ZMQ pub
#no-zmq=1 # Disable ZMQ RPC server
# Log file
log-file=/var/log/monero/monero.log
log-level=0 # Minimal logs, WILL NOT log peers or wallets connecting
max-log-file-size=2147483648 # Set to 2GB to mitigate log trimming by monerod; configure logrotate instead
# Mempool size
max-txpool-weight=2684354560 # Maximum unconfirmed transactions pool size in bytes (here ~2.5GB, default ~618MB)
# P2P full node
p2p-bind-ip=0.0.0.0 # Bind to all interfaces (the default)
p2p-bind-port=18080 # Bind to default port
# Database sync mode
#db-sync-mode=safe:sync # Slow but reliable db writes
# RPC open node
public-node=1 # Advertise to other users they can use this node as a remote one for connecting their wallets
confirm-external-bind=1 # Open Node (confirm)
rpc-bind-ip=0.0.0.0 # Bind to all interfaces (the Open Node)
rpc-bind-port=18081 # Bind to default port (the Open Node)
restricted-rpc=1 # Obligatory for Open Node interface
no-igd=1 # Disable UPnP port mapping
no-zmq=1 # Disable ZMQ RPC server to decrease attack surface (it's not used)
# Network limits
out-peers=24 # This will enable much faster sync and tx awareness; the default 8 is suboptimal nowadays
in-peers=48 # The default is unlimited; we prefer to put a cap on this
# RPC TLS
rpc-ssl=autodetect # Use TLS if client wallet supports it (the default behavior); the certificate will be generated on the fly on every restart
limit-rate-up=1048576 # 1048576 kB/s == 1GB/s; a raise from default 2048 kB/s; contribute more to p2p network
limit-rate-down=1048576 # 1048576 kB/s == 1GB/s; a raise from default 8192 kB/s; allow for faster initial sync
# Mempool size
max-txpool-weight=268435456 # Maximum unconfirmed transactions pool size in bytes (here 256MB, default ~618MB)
# Tor/I2P: broadcast transactions originating from connected wallets over Tor/I2P (does not concern relayed transactions)
tx-proxy=tor,127.0.0.1:9050,16,disable_noise # Tor
#tx-proxy=i2p,127.0.0.1:4447,16.disable_noise # I2P
# Slow but reliable db writes
db-sync-mode=safe
# Tor/I2P: tell monerod your onion address so it can be advertised on P2P network
anonymous-inbound=PASTE_YOUR_ONION_HOSTNAME:18084,127.0.0.1:18084,64
#anonymous-inbound=PASTE_YOUR_I2P_HOSTNAME,127.0.0.1:18085,64
out-peers=64 # This will enable much faster sync and tx awareness; the default 8 is suboptimal nowadays
in-peers=64 # The default is unlimited; we prefer to put a cap on this
# Tor: be forgiving to connecting wallets; suggested by http://xmrguide42y34onq.onion/remote_nodes
disable-rpc-ban=1
```
limit-rate-up=1048576 # 1048576 kB/s == 1GB/s; a raise from default 2048 kB/s; contribute more to p2p network
limit-rate-down=1048576 # 1048576 kB/s == 1GB/s; a raise from default 8192 kB/s; allow for faster initial sync
# Tor: broadcast transactions originating from connected wallets over Tor (does not concern relayed transactions)
tx-proxy=tor,127.0.0.1:9050,16
### Systemd
# Tor: add P2P seed nodes for the Tor network
# For an up-to-date list of working nodes see https://www.ditatompel.com/monero/node-peers
add-peer=4egylyolrzsk6rskorqvocipdo4tqqoyzxnplbjorns7issmgpoxvtyd.onion:18083
add-peer=fagmobguo6u4z4b2ghyg3jegcdpmd4qj4wxkhemph5d5q6dltllveqyd.onion:18083
add-peer=monerokdwzyuml7vfp73fjx5277lzesbrq4nvbl3r3t5ctgodsx34vid.onion:18089
add-peer=b75obarnhi42p7js7wgzo7v3wtiwcgf4bknrwv6ihatop77jivrtwpid.onion:15892
add-peer=5nvd6jbefgto3u74nzzdkcsbqgxyzrkk7bz5qupsdqg4gbuj5valiaqd.onion:18083
add-peer=ozeavjybjbxbvmfcpxzjcn4zklbgohjwwndzenjt44pypvx6jisy74id.onion:18083
add-peer=xcccrsxi2zknef6zl3sviasqg4xnlkh5k3xqu7ytwkpfli3huyfvsjid.onion:18083
7. Create `/etc/systemd/system/monerod.service` as shown below.
# Make the seed nodes permanent to fix monerod issue of not maintaining enough connections,
# based on this reddit comment:
# https://www.reddit.com/r/monerosupport/comments/k3m3x2/comment/ge5ehcy/?utm_source=share&utm_medium=web2x&context=3
add-priority-node=4egylyolrzsk6rskorqvocipdo4tqqoyzxnplbjorns7issmgpoxvtyd.onion:18083
add-priority-node=fagmobguo6u4z4b2ghyg3jegcdpmd4qj4wxkhemph5d5q6dltllveqyd.onion:18083
add-priority-node=monerokdwzyuml7vfp73fjx5277lzesbrq4nvbl3r3t5ctgodsx34vid.onion:18089
add-priority-node=b75obarnhi42p7js7wgzo7v3wtiwcgf4bknrwv6ihatop77jivrtwpid.onion:15892
add-priority-node=5nvd6jbefgto3u74nzzdkcsbqgxyzrkk7bz5qupsdqg4gbuj5valiaqd.onion:18083
add-priority-node=ozeavjybjbxbvmfcpxzjcn4zklbgohjwwndzenjt44pypvx6jisy74id.onion:18083
add-priority-node=xcccrsxi2zknef6zl3sviasqg4xnlkh5k3xqu7ytwkpfli3huyfvsjid.onion:18083
``` INI
# /etc/systemd/system/monerod.service
# Tor: tell monerod your onion address so it can be advertised on P2P network
anonymous-inbound=PASTE_YOUR_ONION_HOSTNAME:18083,127.0.0.1:18083,64
[Unit]
Description=Monero Daemon
After=network-online.target
# Tor: be forgiving to connecting wallets; suggested by http://xmrguide42y34onq.onion/remote_nodes
disable-rpc-ban=1
```
[Service]
ExecStart=/usr/local/bin/monerod --detach --config-file /etc/monero/monerod.conf --pidfile /run/monero/monerod.pid
ExecStartPost=/bin/sleep 0.1
PIDFile=/run/monero/monerod.pid
Type=forking
### /etc/.../monero.service
Restart=on-failure
RestartSec=30
``` INI
# /etc/systemd/system/monero.service
User=monero
Group=monero
RuntimeDirectory=monero
[Unit]
Description=Monero Daemon
After=network.target
Wants=network.target
StandardOutput=journal
StandardError=journal
[Service]
ExecStart=/opt/monero/monerod --detach --config-file /etc/monero.conf --pidfile /run/monero/monerod.pid
ExecStartPost=/bin/sleep 0.1
Type=forking
PIDFile=/run/monero/monerod.pid
[Install]
WantedBy=multi-user.target
```
Restart=always
RestartSec=16
8. Enable the monerod service:
User=monero
Group=monero
RuntimeDirectory=monero
``` Bash
systemctl daemon-reload
systemctl enable monerod
systemctl restart monerod
```
9. Verify it is up:
``` Bash
systemctl status monerod
```
9. Verify it is working as intended:
``` Bash
tail -n100 /var/log/monero/monero.log
```
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
```
## Open firewall ports
If you use a firewall (and you should), open `18080` and `18081` ports for incoming TCP connections. These are for the incoming **clearnet** connections, P2P and RPC respectively.
If you use a firewall (and you should), open `18080` and `18089` ports for incoming TCP connections.
These are for the incoming **clearnet** connections, P2P and RPC respectively.
You **do not** need to open any ports for Tor. The onion services work with virtual ports. The `tor` daemon does not directly accept incoming connections and so it needs no open ports.
You **do not** need to open any ports for Tor.
For example, for popular ufw firewall, that would be:
``` Bash
ufw allow 18080/tcp
ufw allow 18081/tcp
ufw allow 18089/tcp
```
To verify, use `ufw status`. The output should be similar to the following (the `22` being default SSH port, unrelated to Monero):
@ -234,10 +287,10 @@ To Action From
-- ------ ----
22/tcp LIMIT Anywhere
18080/tcp ALLOW Anywhere
18081/tcp ALLOW Anywhere
18089/tcp ALLOW Anywhere
22/tcp (v6) LIMIT Anywhere (v6)
18080/tcp (v6) ALLOW Anywhere (v6)
18081/tcp (v6) ALLOW Anywhere (v6)
18089/tcp (v6) ALLOW Anywhere (v6)
```
@ -247,7 +300,9 @@ To Action From
List all services listening on ports and make sure it is what you expect:
`sudo netstat -lntpu`
``` Bash
sudo netstat -lntpu
```
The output should include these (in any order); obviously the PID values will differ.
@ -255,8 +310,8 @@ The output should include these (in any order); obviously the PID values will di
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
...
tcp 0 0 0.0.0.0:18080 0.0.0.0:* LISTEN 259255/monerod
tcp 0 0 0.0.0.0:18081 0.0.0.0:* LISTEN 259255/monerod
tcp 0 0 127.0.0.1:18083 0.0.0.0:* LISTEN 259255/monerod
tcp 0 0 0.0.0.0:18089 0.0.0.0:* LISTEN 259255/monerod
tcp 0 0 127.0.0.1:18084 0.0.0.0:* LISTEN 259255/monerod
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN 258786/tor
```
@ -274,15 +329,15 @@ Test **clearnet P2P** connection:
Test **clearnet RPC** connection:
`curl --digest -X POST http://YOUR_IP_ADDRESS_HERE:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' -H 'Content-Type: application/json'`
`curl --digest -X POST http://YOUR_IP_ADDRESS_HERE:18089/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' -H 'Content-Type: application/json'`
Test **onion P2P** connection (skip if you don't have proxychains):
`proxychains nmap -Pn -p 18083 YOUR_ONION_ADDRESS_HERE.onion`
`proxychains nmap -Pn -p 18084 YOUR_ONION_ADDRESS_HERE.onion`
Test **onion RPC** connection:
`torsocks curl --digest -X POST http://YOUR_ONION_ADDRESS_HERE.onion:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' -H 'Content-Type: application/json'`
`curl -x socks5h://127.0.0.1:9050 --digest -X POST http://YOUR_ONION_ADDRESS_HERE.onion:18089/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' -H 'Content-Type: application/json'`
## Debugging
@ -292,16 +347,8 @@ Tor:
* Status: `systemctl status tor@default`
* Logs: `journalctl -xe --unit tor@default`
Monero:
Monerod:
* Status: `systemctl status monero`
* Logs: `tail -n100 /var/log/monero/monero.log`
* Logs more info: change `log-level=0` to `log-level=1` in `monero.conf` (remember to revert once solved)
## Further improvements
### Periodic restarts
It's likely worthwhile to add peridic auto-restarting to both `tor` and `monerod` every couple hours. Neither daemon is perfect; they can get stuck or leak memory in edge case situations,
like the recent attacks on Tor v3 or DDoS attacks on the Monero network. One possible way would be to use systemd timers.

1
mkdocs.yml
View file

@ -22,7 +22,6 @@ nav:
- Setup Guide:
# - I2P: 'running-node/open-node-tor-onion.md' TODO
- Tor: 'running-node/open-node-tor-onion.md'
# - Tor onion seed nodes: 'infrastructure/tor-onion-p2p-seed-nodes.md'
- Sample Configs:
- VPS: 'interacting/monero-config-file.md'
# - Home: 'interacting/moneord-tori2p.md' # TODO