Problem with submitted shares not matching what i paid for.
I verified the orders i submitted yesterday and today for the amount of shares actually submitted to the pool and they are at least 20% off. Which means i am paying 20% more for the hashrate i hired.
Has anyone else had similar problems?
Here follows my calculations:
| Order | Price BTC/TH/Day | Total BTC | Unspent BTC | Limited TH/s | Expected Shares | Actual Shares (on pool) |
| Nicehash |
| #252158 | 0.0103 | 0.205702 | 0 | 100 | 401749338.9 |
| #250693 | 0.0104 | 0.156702 | 0 | 250 | 303106382.5 |
| Total nicehash | | | | | 704855721.4 | 560946737 |
| WestHash |
| #250694 | 0.0104 | 0.303702 | 0 | 250 | 587446328.5 |
| #252159 | 0.0103 | 0.156702 | 0.05561814 | 100 | 197423330.5 |
| Total Westhash | | | | | 784869659 | 668995673 |
Has anyone any idea what happened? Can i get my missing shares refunded?
Thanks,
girino.
i would suggest to use only one fixed diff on the pool
( can be really high, statisticially this does not matter )
i also had problems with vardiff .. this is why:
nicehash sometimes sends "old" shares ( from slow miners ) when diff changed, but block did not change. this leads to two problems:
a) when diff is doubling:
50% chance to be below new diff = get rejected
50% chance to be above new diff = get a share with 200% diff
so this case should be no problem on average
b) when diff is halving from 2048 to 1024:
100% to be above new diff = gets always accepted
but: nicehash thinks the share is worth 2048 , whereas the pool thinks it's worth 1024
so you will pay more than you get.
so i expect a often changing diff to cause problems!
i set diff to like 65536 ..only few shares are submitted, but each has a high value..
so i reduce network load, reduce pool load and avoid those problems!
