Repository navigation
Pool mapper drops every XMRig pool key it does not know: rig-id, nicehash, algo/coin, sni #527
Description
What's the problem
Line references are to develop @ 91ca45b. Part of the XMRig-surface sweep.
What's missing
The pool mapper is a whitelist: known_pool="url user pass keepalive tls enabled tls-fingerprint socks5" (rigforge.sh:760). Any other per-pool key XMRig accepts warns as an unknown field and is dropped (rigforge.sh:793). #115 added tls-fingerprint and #400 added socks5, one issue and one mapper change each. The rest of XMRig's per-pool schema is still missing:
| Key | Default | What it is for |
|---|---|---|
rig-id |
null | the pool-side rig identifier. RigForge overloads user with the hostname instead (rigforge.sh:1134); on a pool that keys stats on rig-id, every RigForge worker is anonymous |
nicehash |
false | NiceHash-protocol pools (nonce is pool-assigned). Without it, every share is rejected |
algo / coin |
null | pin the algorithm or let XMRig pick by block version. RigForge assumes rx/0; a RandomX variant (rx/wow, rx/arq, rx/graft) has a different scratchpad and thread profile |
sni |
false | send SNI on a TLS pool. Needed behind any name-based TLS front; pairs with tls and tls-fingerprint, which RigForge already supports |
The change
The whitelist becomes XMRig's full per-pool schema, minus the daemon/solo keys (their own issue). Each key gets the same treatment socks5 got in #400: re-attached from the raw config only when set, validated, and passed through verbatim.
rig-id: same charset rule asuser/pass(rigforge.sh:484). Docs say when to use it instead ofuser.nicehash,sni: strict booleans, likekeepalive/tls/enabled(rigforge.sh:553).algo: accept therx/*family only, error on anything else naming the reason (the HugePages reservation andtune's bench assume a RandomX scratchpad).coin: XMRig's list.statusanddoctorshow the algorithm when it is notrx/0.- The control path's
/applypool schema accepts the same set (util/control-server.py), so a Pithead-driven pool change cannot strip a key the operator set locally. config.reference.jsonanddocs/configuration.mdlist every pool key with its XMRig meaning.
Testing
Unit tier, tests/run.sh, next to the existing #400 cases (tests/run.sh:359-450): each key round-trips into the generated config; an invalid value is rejected with its message; a config without any of them is byte-identical to today; the control-server drift test still passes.
what it impacts
Scope, what stays out
daemon, daemon-poll-interval, daemon-job-timeout, daemon-zmq-port, self-select, submit-to-origin, spend-secret-key are solo-mining mode, which changes what doctor and the feed mean by "pool". Separate issue. No non-RandomX algorithms.
How I found it
Discovery details are not separately established in the existing report; preserve and verify the evidence already recorded.
how important is it
Importance has not been assessed explicitly; triage must state the priority and its reason.
acceptance criteria
Acceptance is not isolated in the existing report; the agent must identify a testable outcome before implementation.
possible solutions
No distinct solution options are recorded; investigate the existing report before choosing an approach.
Activity
pithead-developer commentedon Sep 24, 2026
Investigation brief (operator pre-read, 2026-09-23)
still_valid: yes, on develop @ dcdbc7e (current head). The pool mapper still builds
POOLS_JSONfrom a fixed object literal —url/user/pass/keepalive/tls/enabledonly (rigforge.sh:449-457) — and onlytls-fingerprint(#115) andsocks5(#400) got a follow-up "re-attach from raw config if set" jq pass (rigforge.sh:461-472). No PR since the issue's baseline (91ca45b) touches rig-id/nicehash/algo/coin/sni;gh pr listsearch turns up nothing on those keys. CHANGELOG's [Unreleased]/1.17.3 entries don't mention this either.root_cause: the whitelist-then-patch pattern. Unknown pool fields are dropped after only a lint warning (
known_pool, rigforge.sh:761, checked at 785-798);rig-id/nicehash/algo/coin/sniwere never given the same re-attach treatment socks5 got. Separately,userunconditionally defaults to the rig name (rigforge.sh:1183) — there's norig-idpath at all.fix_shape: mechanical repeat of the #400 pattern, not a new mechanism — one single-line jq re-attach pass per key (rigforge.sh ~472), extend the validation loop (rigforge.sh:509-556) with rig-id's charset rule and strict booleans for nicehash/sni, add an
algoallowlist (rx/0|rx/wow|rx/arq|rx/graft) sincetune --bench/HugePages assume rx/0 (rigforge.sh:3278, 6190).util/control-server.py:21stagespoolsopaquely (WRITABLE) and rigforge.sh re-validates on apply, so no separate control-server schema is needed — one fix covers both paths. Tests slot in next to tests/run.sh:359-366 as the issue proposes.evidence_tier: read (file:line, current head).
rulings_needed:
duplicates_or_blockers: none found.
Triage recommendation: MOVE-2.0.x — config completeness for XMRig pool keys, unrelated to the fork/appliance/dashboard cut; no security or data-loss exposure to justify blocking GA.
Verify against the code before relying on this; it was written by an investigator, not the implementer.
pithead-developer commentedon Nov 1, 2026
Operator: claimed for an operator-run implementation session (owner request, 2026-11-01).
operator-actionkeeps the automated runner off it until the session's draft PR is reviewed.pithead-developer commentedon Nov 2, 2026
Operator: draft PR #607 from the implementation session, held with
operator-actionfor operator review.pithead-developer commentedon Nov 6, 2026
Operator: released to the runner (owner 2026-11-06). New work goes to the local Flash-Next model first; Claude only after three local rounds or for sensitive work.
Preserve optional XMRig pool fields (#607)
pithead-developer commentedon Nov 9, 2026
Merged in #607.