[draft] benchmark: Tor vs clearnet while mining — methodology (#256)#268
Closed
VijitSingh97 wants to merge 3 commits into
Closed
[draft] benchmark: Tor vs clearnet while mining — methodology (#256)#268VijitSingh97 wants to merge 3 commits into
VijitSingh97 wants to merge 3 commits into
Conversation
…sion rule (#256) Documents WHAT we measure and FROM WHERE before building the harness, so the run is reproducible and the conclusion is honest. Key points, grounded in what p2pool actually exposes on gouda (/stats/* + /api/state + docker stats): - Primary metric is PPLNS reward share (block_reward_share_percent) — the direct revenue number that already captures any orphan/uncle effect, so we do NOT need a raw orphan counter to answer "does Tor cost yield". Yield efficiency (reward-share ÷ hashrate-share) + average_effort back it up. - Raw uncle/orphan count is a secondary cross-check via p2pool console-log parse (not in /api/state) — honestly flagged as noisier, not the decision metric. - Secondary latency/connectivity metrics (peers, share cadence, rejects, Tor overhead) are all available today. - Method: sequential A/B on gouda + miner-0 at fixed hashrate, several days per arm, control variable = the #165 p2pool.clearnet knob (dogfoods the toggle). - Decision rule: clearnet arm sets the noise floor; keep Tor default if the delta is within it, else reconsider per-sidechain / clearnet-default-with-opt-in. Harness + results land in follow-up commits on this branch. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Read-only collector for the Tor-vs-clearnet benchmark: snapshots p2pool's /stats/* (reward_share, effort, hashrate, shares, peers, sidechain diff) plus `docker stats tor` (CPU/mem) into one JSONL line per interval, per arm. No new container — it reads what p2pool already writes via --local-api/--data-api. Validated against the live p2pool on gouda (--once produced a clean snapshot: reward_share, peers_out/list, pool_hr, tor_cpu_pct/mem). shellcheck clean. Doc updated with the run recipe (nohup per arm) + a jq summary one-liner. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…net leak check (#256) Reads /proc/net/tcp from each app container and flags any ESTABLISHED connection to a PUBLIC IP (one that bypasses the Tor SOCKS at <bridge>.25:9050). For the "tor" arm every app container must show 0 public connections; only the tor container should reach the internet. For "clearnet" the mining-path containers should show direct public connections. Immediately caught a real leak on a live deploy: p2pool dialing sidechain peers on :37889 directly + Tari direct P2P — config-level checks had passed, but the connection-level check found the traffic was NOT actually behind Tor. This is the live egress assertion the gouda README flagged as a gap (#160/#2). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jun 17, 2026
Collaborator
Author
|
Superseded by #293 ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Wave 2, PR A — the gate (draft: methodology first; harness + multi-day results to follow on this branch).
docs/benchmarks/tor-vs-clearnet.mddocuments exactly which metrics the benchmark uses and from where, before any data is collected — so the run is reproducible and the conclusion is honest. This is the gate for the Tor-default decision in #165/#166.The headline finding that shaped it
Raw orphan/uncle rate is not captured anywhere today (only
shares_found/ reject counts). But we don't need it: PPLNS reward share (block_reward_share_percent, in/stats/local/stratum) is the direct revenue number and already reflects any orphan/uncle effect — an orphaned share simply fails to earn its weight. So the bottom-line yield is measurable today; the raw uncle count is kept as a secondary log-parse cross-check, not the decision metric.Metrics & sources (all verified against the live p2pool on gouda)
block_reward_share_percent, yield efficiency (reward-share ÷ hashrate-share),average_effort— from/stats/local/stratum+/stats/pool/stats./stats/local/p2p), share cadence,shares_failed, hashrate windows, Tor overhead (docker stats tor).proxy_summary.{accepted,rejected,invalid}during donation windows.Method & decision rule
Sequential A/B on gouda + miner-0 at fixed hashrate, several days per arm, control variable = the #165
p2pool.clearnetknob (the benchmark dogfoods the toggle it validates). The clearnet arm sets the noise floor; keep Tor default if the delta is within it, else reconsider (per-sidechain default / clearnet-default-with-opt-in). Conclusion lands indocs/privacy.mdand sets the #165/#166 defaults before the v1.1 release.Next on this branch
/stats/*+docker stats, tails the p2pool console) — no new container.Related
#256 · gates #165 / #166 · part of the #160 privacy epic.
🤖 Generated with Claude Code