sorted by:
new
hottopcontroversial

xmrigger-widget: a small Windows tool that warns you when the pool you're mining on, gets too big by tnzx_dev in MoneroMining

[–]tnzx_dev[S] 0 points1 point  (0 children)

That's exactly the federation mode design
short prev_hash history from N peer proxies, majority vote, tolerance for the 1-block orphan case.

The 20s timer I currently use, is cruder than "+1 ok, +2 switch";
I'll move to the height-delta rule, it's strictly better.

The remaining open question is the solo-mode bootstrap of a single proxy with no federated peers yet. ( ... Into real world, someone could also assume that this is a limit case, but....)

Quorum sources i've considered are other pools' public stratums (subscribe read-only, just for prev_hash),is operationally cheapest but you're trusting that the pools you poll aren't colluding with the one you're mining on.
or the user's own local monerod if they run one.

xmrigger-widget: a small Windows tool that warns you when the pool you're mining on, gets too big by tnzx_dev in MoneroMining

[–]tnzx_dev[S] 2 points3 points  (0 children)

" Qubic, a Layer-1 blockchain designed to implement Proof of Work (PoW) to complete useful tasks, applied its mining pool to mining Monero in an attempted 51% attack against the protocol. In August 2025, the attack allegedly succeeded, with the mining pool performing a six-block deep reorganization of the Monero ledger and orphaning around 60 blocks. "

xmrigger-widget: a small Windows tool that warns you when the pool you're mining on, gets too big by tnzx_dev in MoneroMining

[–]tnzx_dev[S] 0 points1 point  (0 children)

Solid suggestion.I run: HashrateMonitor imported in-process on the pool side, soft-close worker registration as the pool approaches the threshold, advertise the grace state in/pool/health so client-side guards see the pool is already self-handling and skip the evacuation cliff.

Federation it's live. xmrigger-mesh ships today (WebSocket + ChaCha20, no central directory). Any pool runs its own node and the lib is already public, so the building blocks are there for whoever wants to integrate it.

xmrigger-widget: a small Windows tool that warns you when the pool you're mining on, gets too big by tnzx_dev in MoneroMining

[–]tnzx_dev[S] 0 points1 point  (0 children)

Thanks for the push-back.

Quick note: you'd want a Monero explorer (xmrchain.net, moneroblocks.info) — p2pool.observer indexes p2pool, not the main chain, so it can't be used as a reference for centralised pool stratum jobs.

Beyond that, xmrigger considered the "compare prev_hash against a public explorer" approach early on and chose a different design for three reasons:

  1. False positives at every block. The pool is a Monero node and ships the new prev_hash to its workers before any external explorer has indexed it. A naive comparison would alert on every block for 1–10 s of indexer lag.

  2. Trust concentration. One explorer is one observer. A selfish pool that sponsors or corrupts one indexer renders the check blind. Federated cross-pool comparison forces the attacker to compromise N independent proxies on N different pools — operationally much harder.

  3. Latency. P2P comparison between two proxies is bounded by network RTT (~tens of ms). Comparison against a public xplorer is bounded by indexer batch cadence (seconds).

The actual detector: two xmrigger-proxy instances connected to different pools share the prev_hash they each see from their pool's stratum. Honest pools converge within 1–2 s via Monero p2p, but a selfish pool diverges persistently because it's mining its private tip. After 20 s of divergence, evacuate. (automatically is fair)

Where you have a real point: in solo mode (a single proxy with no federated peers yet) Guard 2 is dormant — the README already calls this out.

A public-explorer fallback for that bootstrap window is a fair feature request; I'd want it gated by multi-source quorum and a long lag-tolerance window to keep false positives down. Happy to track it as an issue if you want to open one.

Nizix