Good write-up, and the two-way links are a nice touch. Two small additions for the clearnet page:

• Add <meta http-equiv="onion-location" content="http://your-onion-address.onion/"> to its head. Tor Browser then shows a “.onion available” button to visitors who arrive on the clearnet page, and since it’s a meta tag it works on a static host where you can’t set headers.
• Publish a short PGP-signed text that names both the onion and the clearnet URL, and serve the same file on both. Matching links can be copied by a phishing clone; a valid signature from your key can’t.

For the frozen wallet, a cheap watchdog is a cron job or systemd timer that calls get_height on each monero-wallet-rpc with a short timeout and restarts that unit if it fails twice in a row. Running each wallet RPC as its own systemd service with Restart=on-failure also covers the case where it crashes outright.

Thanks for coming back with numbers, that’s a clean result. Going from 0.41/h to 0.12/h on failed checks is a big drop.

Since one of the three nodes simply died, it might be worth automating the swap next time: a small script that calls get_info on each wallet’s node every few minutes, checks that height is within a block or two of the others, and moves the wallet to the next node on a short list if it falls behind or stops answering. monero.fail’s list works as a source for that fallback list, as long as you only keep onion nodes with a long uptime.

Good luck with the shop.

Worth knowing for anyone who owns one: since 2024 Colorado and California both treat neural data as sensitive personal information under their privacy laws. In Colorado that means it needs opt-in consent; in California you can tell the company to limit its use to what’s needed for the service. If you’re in either state, a deletion or limit-use request that names the neural data specifically is the practical step, and “de-identified” brainwave data is a weak promise when the recordings are long and unique to each person.

Nice design choice with SIGSTOP/SIGCONT instead of changing thread counts, since every thread change makes RandomX rebuild its dataset.

One question: which P2Pool sidechain does it use by default? At laptop-level hashrate the main chain can go days between shares, so P2Pool mini or nano usually suits casual miners better: smaller but regular payouts. Auto-picking the sidechain from the measured hashrate could be a nice touch.

And on @ArseneSpeculoos’s question: P2Pool needs a monerod with ZMQ enabled (--zmq-pub), so pointing it at your own node works fine as long as ZMQ is on. Most public remote nodes don’t expose ZMQ, which might be worth a line in the README.

Glad it helped. Of the two, IsolateSOCKSAuth is the least invasive: you keep one Tor process and just give each wallet a different SOCKS username, so the setup script only changes the proxy line per wallet. Good luck with the launch.

Nice write-up, and the 2-of-3 view-only setup is clever. On the missed polls: I had the same pattern with several wallets over one Tor client. Giving each wallet its own circuit (a separate SocksPort, or a different SOCKS username with IsolateSOCKSAuth) and raising the RPC timeout to 60–90 s made most of the “bad node” misses disappear. Tor sometimes just has a slow minute for everything at once.

Also, once you’re happy with it, add the shop to a few Monero directories (XMRList and others list onion-only shops). That’s mostly how people looking to spend XMR find new places.