So you effectively made ~9% off your miners by going to Goat ?
4% fee + 5% bonus.
Not exactly. The experiment with gigaminer was small (about a million shares), but a complete disaster. We ended up paying our miners for about 200,000 valid shares which have been rejected upstream.
ABC miners are always credited for every valid share they submit as long as it’s not a duplicate. Even if an 'upstream pool' later turns out to reject the share, the original miner is still credited.
That's another way that we create a predictable experience for our miners, which cost us quite a bit in this instance.
Could you please explain this properly.
I don't know for sure that I understand what needs additional explanation, but I'll try!
As far as I see it, it is your choice of where you sent the hashing that caused this problem.
It sure is.
So of course you should pay for the problems you cause - it would make no sense why people who mine at your pool should pay for that.
I completely agree, that's why we set it up that way. We absorb that risk, so our miners know that their shares are always counted. Luckily this problem has only happened once on this scale.
Had you processed the shares yourself, the stales would not have been anything like that
Yes, they would probably be a lot lower.
No pool should be having 20% stales, ever! ... all but foolish members would leave such a pool.
We intend to prevent shares from being routed through the project #2 pool in the future. We've now seen that it does not work when pools forward shares to each other in a circle. Who would have thought?
Yep it was that last bit that needs clarification.
Of course sending shares in a loop wouldn't work ... however, the getwork must come from somewhere ...
There must be some pool that replies to the getwork request and that is the pool that will accept/reject the shares.
So I'd not expect that the circle was the actual direct cause of the problem - that would mean that no getworks would be answered.
Somewhere in the "loop" there must have been getwork replies or no work would have happened on the loop at all.
The problem would be: not sending the share replies to the getwork source.
So I'd again guess that the issue there was (and has now been corrected) no proper correlation of where the getwork came from with where the share reply should go ...