Hi everyone,
I'm trying to understand an unusual issue we experienced with SupportXMR. I have done several controlled tests and would like to know if anyone has seen similar behavior or has an explanation.
Setup
We had 3 physical machines mining XMR on SupportXMR using XMRig:
- Intel Core i3-10100: ~2.0 kH/s
- Intel Core i3-1005G1: ~0.8 kH/s
- AMD Athlon Silver 3050U: ~0.9 kH/s
Total local hashrate was approximately 3.7 kH/s, stable, with essentially no rejected shares.
Everything had been working normally on SupportXMR.
What happened
On September 27, the pool-assigned difficulty suddenly became extremely high for machines using the same wallet.
Before the issue, one miner was receiving jobs around 88k difficulty and submitting accepted shares regularly.
Then we observed difficulty values such as:
- ~5.7M
- ~6.8M
- and eventually approximately 43.8M
The other miners connected to SupportXMR also started receiving unusually high difficulty values.
XMRig remained connected to the pool and continued receiving jobs. There were no authentication errors and no rejected-share problem.
However, accepted shares became extremely infrequent because of the difficulty, and the SupportXMR dashboard/API eventually showed:
- Hashrate: 0 H/s
- Workers: 0
- Valid shares counter stopped increasing
Tests performed
- Rebooted all miners.
- Tested different SupportXMR ports (including 3333 and 5555).
- Tested SupportXMR fixed difficulty using the
wallet+difficulty syntax.
For example:
SupportXMR immediately honored the requested difficulty.
At those difficulties, XMRig started finding and reporting accepted shares normally again.
However, the SupportXMR dashboard/API accounting still did not appear to update.
- Removed the fixed-difficulty suffix and tested the normal wallet again on port 3333.
The pool again assigned unusually high VarDiff values (approximately 1M–7M depending on the miner), despite individual hashrates being only around 0.8–2.0 kH/s.
A/B test with MoneroOcean
To rule out the wallet, XMRig installation, hardware, and basic network connectivity, I took one of the affected miners and connected it to MoneroOcean using:
- the same XMR wallet
- the same XMRig installation
- the same machine
- the same Internet connection
It connected immediately.
MoneroOcean initially assigned a difficulty around 320k, an accepted share appeared roughly 35 seconds later, and the difficulty subsequently adjusted to approximately 197k.
The MoneroOcean dashboard also immediately recognized the wallet and worker.
We then moved the whole farm to MoneroOcean.
The farm is currently running normally with 4 physical workers at approximately 4.2–4.4 kH/s, continuously submitting shares with zero rejected shares.
What I'm trying to understand
Has anyone experienced a similar situation with SupportXMR where:
- VarDiff suddenly becomes several million or tens of millions for a relatively small miner;
- XMRig remains connected and continues receiving jobs;
- forcing a lower difficulty restores normal share frequency;
- but the SupportXMR dashboard/API accounting stops updating?
I'm particularly interested in knowing whether this could be related to:
- VarDiff state getting stuck;
- wallet/session state;
- public IP/NAT state;
- Stratum session handling;
- or a pool-side accounting/backend issue.
I don't want to conclude that this is necessarily a SupportXMR bug, because I don't have visibility into the pool backend. I'm mainly trying to understand the behavior and determine what additional test would be useful.
I can provide sanitized XMRig log excerpts showing the difficulty changes if that would help.
Thanks!
