Add Full FlexPool Integration

[jeremyhammon]

Files are already created, i just dont have access to add it to your base or create a development fork.

find them here:

Balance: https://github.com/jeremyhammon/RainbowMiner/blob/master/Balances/FlexPool.ps1
Pool: https://github.com/jeremyhammon/RainbowMiner/blob/master/Pools/FlexPool.ps1

Probably not the same exact design you use because i was trying to figure out your pool integration, but it all seems to work. One issue i need to look at regarding amount paid.

[jeremyhammon]

looking at the "Earned" value, my math looks correct. (Total Paid + Balance) / Divisor. The only thing i can figure is that you are actually calculating that somewhere else and i don't need to provide that value directly.

[RainbowMiner]

Thank you! I have been able to used large parts of your source code.

Sidenote: if pools use super large integer numbers (like this pools does, because it uses "wei" as base unit for ETH, means all needs to be divided by 1e18), we run into big trouble with Powershell. A super large integer is a number, that has more than 18 digits.
When doing ConvertTo-Json / ConvertFrom-Json Powershell Core just completely messes up the conversion of those bigints. It's a bug in the Powershell Core code. To be able to handle this bug, our asynchronous web request commandlets Invoke-RestMethodAsync and Invoke-WebRequestAsync have the switch -fixbigint.
We need to set that switch manually for calls, that make use of such superlarge integers.

[jeremyhammon]

Yes, I reported that bigint issue to you a few days ago. Glad you were able to find a good workaround. In this case, it didn't seem to cause an issue since it was doing the read direct and not using the async loader. Since it was direct, it avoided the conversion back and forth and didn't cause an issue.

I have been running the source I created for the last day or so with no issues aside from the total earned calculations.

[jeremyhammon]

I looked over your code and I have a slight concern over the way you are handling the api requests that end in page=0. Unless you have code other places to handle this situation, you could miss payments or block information as it is only 10 per page. If you look back at my code I am grabbing the total number of pages and looping through all of them to make sure I get all of the content

[RainbowMiner]

I have noticed that, but decided to reduce the calls. It would have been more than 50 API calls for the blocks. The averaging and upcalc for the blocks per day turns out to be quiet accurate, with 10 blocks (1 page), only. Regarding the payments, I could implement the looping. My test case has been one of FlexPool's power miners. He had 8 pages to download for the payments.

[jeremyhammon]

The payments I could see keeping the loop, or I think there may be another one that may return the last 30 payments.

I did consider changing the block loop to check the dates and/or go ahead and process them, that way you could stop after you got back 24 hours since it seemed that was what most of the calculations were based on.

[RainbowMiner]

Yes, that could do the job. I'll re-insert the loops. Timecheck is a good idea, thank you!

[RainbowMiner]

Cool. Done. It's down to three API calls for the blocks, now. Regarding the balance, all payout pages will now be loaded. The Flexpool API seems fast enough to handle the calls.