Benchmark Tor vs clearnet while mining (p2pool / monerod / Tari) — does steady-state mining lose yield over Tor?

[VijitSingh97]

Motivation

The privacy epic #160 locks in a v1.1 plan to flip the yield-trade-off paths to Tor by default — p2pool outbound sidechain P2P (#165) and XvB donation mining (#166) — but explicitly conditions it on:

v1.1 — Tor-by-default for the yield-trade-off paths (benchmark first; opt-out documented)

This issue is that benchmark. We need quantitative data on whether routing the mining-path networking over Tor (vs clearnet) measurably hurts yield or reliability while actively mining (steady state — not initial sync, which #183/#234 already established is impractically slow over Tor). The result feeds the default decisions in #165/#166 and gives us an honest trade-off section for docs/privacy.md.

Question

While the stack is mining at steady state, does routing p2pool sidechain P2P, monerod P2P, and Tari P2P over Tor instead of clearnet cost us anything that matters — share latency, orphan/uncle rate, block propagation lag, effective on-pool hashrate, or crediting at XvB?

Metrics to compare (Tor vs clearnet, same hashrate input)

p2pool (most latency-sensitive → directly revenue-affecting)

• Share submission latency / round-trip to sidechain peers
• Uncle / orphan share rate (the headline number — latency → stale shares → lost revenue)
• Time-to-first-share after start; sidechain peer count & churn
• Effective/accepted hashrate as seen on the pool

monerod

• Tip lag / block propagation delay (how stale is our chain tip vs network)
• Peer count, connection stability, reorg exposure

Tari (merge-mining)

• Block-template freshness, block propagation, peer connectivity

XvB donation path (#166)

• Whether clearnet vs Tor affects accepted-share crediting at na.xmrvsbeast.com

Overhead

• Tor daemon CPU / memory cost under sustained mining traffic

Method

• Two otherwise-identical stacks (or an A/B of the same host over matched windows): one all-Tor, one clearnet, with the same hashrate pointed at each.
• Run over a fixed, long-enough window to get statistically meaningful orphan/uncle counts (shares are sparse — likely several days per arm).
• Capture the metrics above; produce a results table + a recommendation.
• This needs a live mining environment, not unit tests — consider piggybacking on the e2e test-server matrix (Comprehensive end-to-end infrastructure test matrix on a real Ubuntu server (full Monero + Tari node) #54 / e2e: optional tier-4 live validation for already-unit-tested security features #206) rather than standing up bespoke infra.

Output / deliverable

• A results table comparing Tor vs clearnet across the metrics above.
• A clear recommendation feeding p2pool: route outbound sidechain P2P through Tor by default (--socks5), documented clearnet opt-out #165 (p2pool default) and XvB donation: route mining upstream through Tor by default + pin --donate-level 0 (xvb.tor opt-out) #166 (XvB default): is the privacy default acceptable as-is, does it need a documented opt-out, or does the trade-off warrant a different default?
• Trade-off content for docs/privacy.md so operators can make an informed choice.

Related

• [Epic] Privacy: no clearnet egress outside Tor — close leaks + privacy-first defaults #160 — Privacy egress epic — this issue is the "benchmark first" prerequisite it names.
• p2pool: route outbound sidechain P2P through Tor by default (--socks5), documented clearnet opt-out #165 — p2pool outbound P2P over Tor by default (decision depends on this).
• XvB donation: route mining upstream through Tor by default + pin --donate-level 0 (xvb.tor opt-out) #166 — XvB donation over Tor by default (decision depends on this).
• Feature: optional clearnet initial sync (Monero + Tari) then switch to Tor — default off, privacy-first #183 / Auto-transition clearnet initial sync back to Tor once synced (follow-up to #183) #234 — Optional clearnet initial sync then back to Tor (establishes Tor IBD is slow; this issue is about steady-state mining, the open question).
• Dashboard: Component Health panel with per-component + outbound-connection security status (Tor vs clearnet) #170 — Dashboard Component Health panel (Tor vs clearnet egress status) — natural place to surface the live picture.