Skip to content

faq.md

Latest commit

 

History

History
145 lines (110 loc) · 8.18 KB

faq.md

File metadata and controls

145 lines (110 loc) · 8.18 KB

FAQ

Common questions about what Pithead is, what it does for you, and how it compares to wiring the pieces together yourself. If you're new here, start with Getting Started; the deeper "why" lives in Architecture.

Why Pithead vs. doing it yourself / vs. Gupax

vs. doing it yourself

You can absolutely run a private Monero + P2Pool + Tari setup by hand — plenty of people do, and the underlying projects (monerod, P2Pool, XMRig) are excellent. Doing it yourself means standing up and maintaining each piece and the wiring between them:

  • A Monero full node with restricted RPC, ZMQ, and Tor transaction broadcasting.
  • P2Pool pointed at that node, with an onion address for inbound peers.
  • Tari (Minotari) merge-mining alongside Monero.
  • Each rig configured for the pool, plus a plan for what happens when the node goes down.
  • Some way to actually see hashrate, sync progress, and your PPLNS window.

Pithead automates that whole stack in one command and adds the parts that are tedious to build yourself:

  • Tor-first networking. A built-in Tor daemon gives Monero, Tari, and P2Pool hidden-service (onion) addresses — no public port forwarding, and Monero/Tari traffic runs over Tor. A couple of outbound yield paths still use clearnet today; see Privacy & network egress for the full map and how to harden them.
  • One endpoint for every rig. All workers point at a single xmrig-proxy endpoint on :3333. There's nothing per-rig to configure — no wallet address, no pool URL juggling. See Connecting Miners.
  • Algorithmic XvB switching. A feedback controller splits your hashrate between P2Pool and XMRvsBeast (XvB) bonus rounds, donating only the minimum needed to hold your target tier and routing the rest to P2Pool. See Architecture › Algorithmic switching.
  • Node-down worker failover. If monerod goes down, the stack stops xmrig-proxy so your miners fail over to their backup pools instead of mining into a void. See Configuration › dashboard.tari_required.
  • A dashboard that tells you things. Live hashrate, sync progress, the PPLNS window, per-worker stats, and your P2Pool/XvB split — served over HTTPS on your LAN. See The Dashboard.
  • Hardened defaults. Least-privilege containers, SHA256-verified and version-pinned binaries, localhost-only RPC, and split read-only / start-stop Docker socket proxies. See Architecture › Security posture.

If you enjoy hand-wiring infrastructure, the manual route is a great learning exercise. If you'd rather get a private, multi-rig, merge-mining stack running before your coffee gets cold, that's what Pithead is for.

vs. Gupax

Gupax is an excellent GUI for running P2Pool + XMRig on a single machine — if you want a friendly, one-box way to solo-mine Monero on P2Pool, it's a great choice and worth a look.

Pithead solves a different problem. It's a full self-hosted stack, not a single-machine GUI: your own Monero full node, Tor for privacy, Tari merge-mining, a single proxy endpoint for many rigs, algorithmic XvB switching, node-down failover, and a LAN dashboard — all orchestrated together. Think of Gupax as the right tool when you're mining on one PC, and Pithead as the right tool when you want to run the whole operation — node, privacy, dashboard, and a fleet of workers — yourself. Different tools for different goals.

FAQ

Is my home IP exposed?

Mostly not — with two clearnet exceptions today, plus a one-time exposure at install. A built-in Tor daemon gives Monero, Tari, and P2Pool hidden-service (onion) addresses, so inbound connections need no port forwarding and don't reveal your IP. Monero and Tari route P2P and transaction traffic over Tor, and their old clearnet DNS lookups are closed.

What still touches clearnet (and so can reveal your IP):

  • P2Pool's outbound sidechain peers — clearnet today; Tor-by-default is planned for v1.1 (#165), and you can route it through Tor now (see the privacy guide).
  • XvB donation mining — only if XvB is enabled; clearnet to xmrvsbeast.com. Disable XvB to stop it, or wait for the v1.1 Tor routing (#166). (The XvB stats fetch is already Tor-routed.)
  • Install / build fetches code and container images from GitHub, getmonero.org, and the image registries once — inherent and integrity-pinned, but it reveals your IP at that moment.

Bottom line: with XvB disabled, on a normal home connection behind NAT the only time your IP leaves the box is that one-time install.

See Privacy & network egress for every connection and how to harden each one.

Do I need to port-forward?

No. Because connectivity runs through Tor hidden services, there's no public IPv4 port forwarding required. (On your LAN, port 3333 does need to be reachable from each rig to the stack host — that's local network traffic, not an internet-facing port. See Connecting Miners › Networking notes.)

Is the XvB donation mandatory? Will it cost me?

It's optional, and the engine is designed to minimize what you give up. XvB switching is on by default but can be turned off (xvb.enabled: false). When it's on, the decision engine donates only enough hashrate to hold your target tier and routes everything else to P2Pool — because the XvB raffle picks winners at random, donating above a tier's threshold earns nothing extra. See Architecture › Algorithmic switching and the xvb.* keys in Configuration.

What is Tari? Do I have to mine it?

Tari (the Minotari node) is a chain that's merge-mined alongside Monero through P2Pool — you earn on both at once for the same RandomX work. You do need a Tari payout address, but you don't have to let Tari problems hold up Monero mining: set dashboard.tari_required: false to keep mining Monero through a Tari outage or resync, with Tari catching up in the background. See Configuration › dashboard.tari_required.

Can I use my existing synced Monero node?

Yes. You can skip most — or all — of the initial blockchain sync two ways: point the bundled node at your existing .bitmonero directory via monero.data_dir, or switch to remote mode and connect to a node you run elsewhere (it must have ZMQ publishing enabled for P2Pool). The same data_dir trick works for reusing a synced Tari node. See Configuration › Reusing an existing node.

What hardware do I need?

Plan for 16 GB+ RAM, a CPU with AVX2 for RandomX, and an SSD (~300 GB pruned / ~500 GB full minimum — Tari's chain alone is ~135 GB, and both chains grow ~100+ GB/year, so a 2–4 TB drive is the set-and-forget choice). Full minimum-vs-recommended sizing for the stack host is in Hardware Requirements. (Miner hardware is sized separately in RigForge.)

How do I connect my miners?

Point any XMRig (or other RandomX miner) at YOUR_STACK_IP:3333 — that single endpoint is the only pool setting your rigs need, and you do not put a wallet address in the miner config. Point all your rigs at the same address; the stack aggregates them. New to mining? RigForge provisions a tuned worker and wires up the 3333 connection in one command. See Connecting Miners.

See also