I can confirm that the Tor over Tor warnings are no longer present in Nyx with my new monerod configuration in Whonix-Workstation.
I still have a question about the ideal SocksPort: Which one should I choose, and why? I have some thoughts on that, but first, let me explain what I did for the monerod configuration.
I checked 65_gateway.conf in sys-whonix to see all the configured socksports (e.g., grep -R socksport /etc/torrc.d/).
Then, I chose one that offered IsolateDestAddr and IsolateDestPort. I selected 9105 because my 65_gateway.conf includes this line: /etc/torrc.d/65_gateway.conf:SocksPort 127.0.0.1:9105 IPv6Traffic IsolateDestAddr IsolateDestPort.
I also used the command ss -ntp | grep 9105 to check if the port is in use. Since it was available (no output), I chose it.
This resulted in the configuration of my monerod file like this:
--proxy=10.152.152.10:9105
--tx-proxy=tor,10.152.152.10:9105,16
In the context of Whonix, how can I determine the best port for monerod? From what I understand, it’s best to assign different ports to different applications to avoid correlation risks, though stream isolation makes this less necessary. The only risk occurs when two applications reach out to the same destination and port, causing stream isolation to fail. This is possible but unlikely. For applications that reach different destinations and ports, it would be fine to always use the same stream-isolated port. This is my current understanding.
Ideally, each application, such as Tor Browser, monerod, and messaging, would have its own dedicated port. However, I am concerned that choosing any free port might lead to its use by Whonix developers in the future. I could not find a clear, declarative table in the documentation showing which ports are in use and for which application. For strong data locality, this information should be documented directly in the 65_gateway configuration file. Perhaps first-class Tor applications, such as monerod, should be given a reserved port (as a recommendation in the configuration file). Please let me know if my concern is valid and if I understand the matter correctly. Also, please let me know what you think about my proposal for improvement.
My tested monerod.service file is:
[Unit]
Description=Monero Full Node (Tor-only, restricted RPC) - Flatpak
After=network.target
[Service]
Type=simple
ExecStartPre=/bin/sh -c 'until nc -z 10.152.152.10 9105; do sleep 2; done'
ExecStart=/usr/bin/flatpak run \
--command=monerod \
--share=network \
--filesystem=%h/.bitmonero:rw \
org.getmonero.Monero \
--data-dir=%h/.bitmonero \
--non-interactive \
--prune-blockchain \
--sync-pruned-blocks \
--proxy=10.152.152.10:9105 \
--tx-proxy=tor,10.152.152.10:9105,16 \
--out-peers=8 \
--in-peers=0 \
--hide-my-port \
--pad-transactions \
--enable-dns-blocklist \
--no-igd \
--rpc-bind-ip=127.0.0.1 \
--rpc-bind-port=18081 \
--restricted-rpc \
--no-zmq \
--check-updates=disabled \
--log-file=%h/.bitmonero/bitmonero.log \
--log-level=0,stacktrace:FATAL \
--max-log-file-size=10485760 \
--max-log-files=3
Restart=on-failure
RestartSec=30
ExecStop=/usr/bin/flatpak kill org.getmonero.Monero
StandardOutput=journal
StandardError=journal
PrivateTmp=true
ProtectSystem=full
[Install]
WantedBy=default.target
The goal of this file is to strike the optimal balance between connectivity and minimizing exposure. Monerod is locked down and all unnecessary features have been removed for the Qubes/Whonix split wallet architecture. No incoming connections are established.
The best feature is that separate circuits are used for monerod p2p connections and transaction broadcasting. This ensures that each connection has a different Monero p2p circuit, as well as additional circuits for Monero transactions, since the nodes used for p2p traffic aren’t used for transactions. This reduces the risk of correlation attacks. Broadcasting to a maximum of 16 nodes in the network leads to fast transaction diffusion, which protects against analysis by having some nodes receive the transaction much earlier than others in the network.
Monerod will primarily use Onion Services, but not exclusively, to reduce eclipse attacks. The pool of Onion Services for p2p Monero nodes is simply more limited than it would be if IP addresses were also used. Additionally, an attacker could create multiple Onion Services addresses for the same node, which could lead to the same node. Therefore, a mix is ideal.
I have always been annoyed by the stack traces in the logs that lead to a GitHub issue stating they are neither critical nor important. Therefore, I disabled logging for all but fatal stack traces. I also reduced the size of the logs because I don’t need 10 logs, each 100 MB. This should be the default behavior.
I consider padding transactions an improvement against traffic analysis.
To make updates easier, I used Flatpak. This allowed me to improve the Whonix documentation without completely breaking it. Since Flatpaks can be updated easily, I disabled the update check to reduce exposure and eliminate one unnecessary connection.
Terminating the Flatpak process isn’t the cleanest method, but I could not find a proper stop command for the monerod process. I tried for hours. The issue is that the graceful shutdown command needs to be passed from systemd through two child processes of Flatpak’s sandbox to reach monerod, but this often fails, leading to orphaned processes that still hold the lock on the LMDB database. This causes the database to break when monerod is restarted because the old service is still running and holding the lock. Therefore, I used the working Flatpak kill command that is also in the Whonix documentation. This shouldn’t be a problem, as LMDB is atomic and should not become corrupted upon abrupt shutdown.
I also added the pruned flag because running a pruned blockchain does not pose a privacy issue. The only real downside is that the node cannot provide others with full blockchain data. However, this limitation is irrelevant since the node only runs outbound connections anyway.
I consider this a significant improvement to the official documentation, and I would like to see it added. However, I don’t know how to edit the documentation or contribute to it.
My approach was to determine all flags of the latest moenrod version (‘Fluorine Fermi’ v0.18.4.6), while matching the QubesOS/Whonix split architecture in the best possible way. I omitted the unnecessary ones and set some redundant options to ensure added safety against future changes.
Please ask if you have any additional questions.
