Bug Type: Fairness

Bug Description: So decided to look at the provably fair of your mines game. It's not very explanatory maybe you guys don't see it bothering over. But see you guys using a similar system as Stake minus the Fisher-Yates algorithm Stake uses to make sure there are no duplicate mines.
But if you take a look at how these games verified I noticed the mines position didn't match up with the numbers.
Example here: https://fjminesdemo.steadylogic.com/verify?serverSeed=4220a54a315143ee8d5d77cd3b9b2275e0448ac1c0f042ec92ec8d96779a4d44&clientSeed=a&nonce=0&numberOfPins=3

Pic: https://i.imgur.com/R48ntLo.png
You notice how instead of position 19 it went position 20 instead and instead of 18 it went 19 and 13 to 14. Now that's a change that could mean the different between someones win/lose.
But there's sometimes not only a 1 position difference.

Example here: https://fjminesdemo.steadylogic.com/verify?serverSeed=034e7d1a562348b3b78b6b4019197079f1ede09307394aada99ee256f3503d7a&clientSeed=a&nonce=0&numberOfPins=5

Pic: https://i.imgur.com/MmD6bRf.png

In this one not only is position 2 shifted to 3, but position 13 was moved to 15, 10 to position 12 and 4 to position 6.

Now I have looked at 2 other provably fair mines games(Crypto.games and Stake) none of them ever change the float number except in a case of a duplicate mine, which none of the above have. It doesn't help that theres no documentation/explanation on why the number changed.

Not saying you guys are cheating just saying that there is some kind of issue that alters the proper result of the game. Seems like your guys were going for some kind of Fisher Yates shuffle but didn't fully implement it.

If you guys wanted to properly implement the shuffle when you get the float number. You had to multiply by the number of options remaining eg. for the 1st mine it will be (*25) the 2nd will be (*24) 3rd (*23) etc. going down the amount of mines. Instead you guys have it static at 25.

Username: lolgato