I believe some miners might have been hit with a weird bug, that went completely unnoticed on servers with just GTM & GIN pools. Sometimes the connections ended up on the wrong pool. This was noticed on a server with RVN & GIN, because it caused rejected shares that were easy to spot. But on GTM/GIN servers both the algorithm & the addresses are compatible! Some people complained about missing hashrate and I had a hard time understanding that. But I finally realized some shares had ended up on the GIN pool, and even got paid as GIN! The situation can't happen now with each coin having its own port. GTM is on port 3, I encourage everyone to switch who still uses port 1.
You could actually reclaim those shares as GIN, just by copying your GTM wallet.dat as your GIN wallet. I haven't tried that myself, and the amounts didn't seem to be even 1 GIN for anyone I checked, but surely it should work when the addresses are compatible?
I'm sorry for this mistake, I'll see how high the rate could go as some sort of compensation
If anyone cares about the techical details, here goes: the pools had their own public IP addresses, both pools on port 1 of their address, on the same server. For some reason that I still don't fully understand, the pool on the primary IP (the 1st one, which is also used for outgoing connections by default) sometimes 'took over' connections of the other IP addresses. My theory is that the server might have sent TCP connection resets from the primary IP address, even for connections of the other addresses, and with the correct source/destination port numbers, some operating systems interpreted that as a change of IP address of the endpoint, while most just reset the connection without allowing the IP to change. Does anyone have a better idea? Most users never noticed anything, which led me to believe it only happens with certain operating systems, and they can differ in their routing & TCP implementations quite a bit.
