Tuesday, April 26, 2022

Feedback on running a Public Monero Node

I run a public monero node using dAppnode. For anyone with an extra PC lying around which you are OK with dedicating to node running, I highly recommend it. I personally use it to run nodes for Monero, Bitcoin and Ethererum (Geth and Prysm). I personally use an NUC10i3 with 16 GB RAM and a 2TB WD-Red SSD NVMe and it runs great as a headless unit with each node in its own docker container with an nice GUI interface. It is a modified version of Debian Linux. If interested, can download it here: https://docs.dappnode.io/get-started/installation/custom-hardware/installation/iso/

Anyway, I am using the following arguments to run my unattended Monero public node and would just like feedback if can recommend any changes. I have a fast 1 GB connection without any data caps.

Options: --restricted-rpc --enable-dns-blocklist --enforce-dns-checkpointing --public-node --out-peers=50 --in-peers=50 --limit-rate-up=1048576 --limit-rate-down=1048576 --log-level=0

  1. Restricted RPC: recommended for any public node since limits the scope of commands users can give to it
  2. enable-dns-blocklist: Is this still recommended? It blocks a bunch of known malicous nodes from a centrally maintained list. I am not crazy about the centralization aspect of it, but since this is an unattended node and it maintained by a trusted community member (sethforprivacy?), I figure I'll run it if it is helpful for stability
  3. enforce-dns-checkpointing: I read that this is recommended for unattended nodes. It uses something called Monero Pulse to identify the valid chain in the event of a fork event I believe. Once again, seems like a possible centralization vector, but since it run by the core team and the node unattended, I figure it a worthwhile compromise for node stability
  4. public node: accounces to the P2P network the node available for public use
  5. out-peers=50: I believe the default unlimited. This let's my node connect to others to seed them. I felt lke unlimited is too high.
  6. in-peers=50: Default is only 8. This let's my node allow others to connect and speeds synchronication and tx awareness. Figured 50 makes more sense
  7. limit-rate-up=1048576: default only 2048 kB/s, by increasing can contribute more to p2p network
  8. limit-rate-down=1048576: default only 8192 kB/s, setting higher allows for faster initial sync. After that, does not have much effect
  9. log-level=0: This is the same as the default log level which is quite minimal in output. I just keep it there so can quickly change it for troubleshooting, in case I want to increase it to 1-4 for more verbose outputs.

Any thoughts if these are optimal settings for my use case or if can recommend any others?


No comments:

Post a Comment