Release issued today

hashingpro wrote:So if we had 100 people on, and the system was reading it as 120 miners due to not disconnecting 20 people and still counting them....

Then wasn't the system taking the profits and dividing it by 120 and giving each miner 1/120 of a profit instead of 1/100 of a share?
So where were the rest of the 20 1/120 shares going if not to the miners that were on the system mining?

Were the expected payouts being figured using this invalid 1/120 number instead of the true 1/100 number it should have been and THATS why all the expected payout projections have been off for so long now?

Hopefully with the disconnected people no longer being counted to skew off the numbers the expected payouts are more in line with what we actually get so the expected payouts can again be more reliably used to judge performance of the pool again.

Hashingpro has raised points that need responding to. Please confirm what happened, if anything, to the profits calculated against an incorrect number of miners.

Steve Sokolowski wrote:Whatever the case, this issue could not have caused miners to be paid less than the reported profitability, because that's just an average of what everyone is earning. I think the end result will be a slight increase in reported profitability compared to that over the past year.

So not the REPORTED profitibilty in the total miner earnings, Im sure that is what you pay out to all the types of miners(scrypt pool, scrypt solo, x11 pool, x11 solo) on the pool presently. My issue has been with the EXPECTED 1MH expected payouts. The automatic vs LTC and the automatic vs DASH.

Just to be clear that chart represents the amount the AUTOPOOL miners made divided by the hashrate the AUTOPOOL miners had on it for each of the X11 and Scrypt types correct? And there is a method in place to subtract out the hashrate of the solominers who aren't in the pool and their profits from the calculations or are they already split into 2 separate numbers to begin with? like x11_soloprofits, x11_solohash, X11_poolprofit, X11_poolhash?

Because if you are taking ALL the money paid out from ALL the miners, and dividing it by the hashpower or miners or workers or accounts on ALL the pools then you aren't really calculating the expected payout on the AUTOMATIC vs LTC chart, you are calculating the POOL SCRYPT vs LTC chart.

I am assuming when the solo mining part was added that they were separated out.
Is there any chance you could add dropdowns to the 1 MH/s expected payouts for SOLO SCRYPT and SOLO X-11 so we can look and compare those numbers also.
Splitting up the Daily miner's payouts by those 4 categories might be nice also, Id be interested in how much comes from solo mining vs the pool and the hashrates being applied by each to the pool's total, even if that is just in a pie chart or by percents of the total for the day's earnings?

tomos81 wrote:

QuoteFirst, I added a check to disconnect users who connect with two miners with the same n= parameter. This is important because n= is used to track miners on the website, and the hashrate of two miners with the same "n=" would constantly swap back and forth on the "earnings" page.

in nicehash - now when we are trying to hire higher hashing power, and nicehash creating more mining groups within the same order ,the 2nd and the next miner groups having the error - Disconnected - Authorization failed..

https://ibb.co/gvqgTk

Don't use the same worker name for every order. Instead, use different "n=" password arguments, or omit n=.

Steve Sokolowski wrote:

tomos81 wrote:

QuoteFirst, I added a check to disconnect users who connect with two miners with the same n= parameter. This is important because n= is used to track miners on the website, and the hashrate of two miners with the same "n=" would constantly swap back and forth on the "earnings" page.

in nicehash - now when we are trying to hire higher hashing power, and nicehash creating more mining groups within the same order ,the 2nd and the next miner groups having the error - Disconnected - Authorization failed..

https://ibb.co/gvqgTk

Don't use the same worker name for every order. Instead, use different "n=" password arguments, or omit n=.

I am using different name for every worker. but nicehash is making more groups with same worker name within single order - pls see my screenshot above.. they are acting like 2..n same workers with same name within 1 order, that i cannot change.

tomos81 wrote:

Steve Sokolowski wrote:

tomos81 wrote:

in nicehash - now when we are trying to hire higher hashing power, and nicehash creating more mining groups within the same order ,the 2nd and the next miner groups having the error - Disconnected - Authorization failed..

https://ibb.co/gvqgTk

Don't use the same worker name for every order. Instead, use different "n=" password arguments, or omit n=.

I am using different name for every worker. but nicehash is making more groups with same worker name within single order - pls see my screenshot above.. they are acting like 2..n same workers with same name within 1 order, that i cannot change.

sorry tomos, that isn't an issue with prohashing, that needs to be handled by nicehash. to avoid worker names being given in groups, do not use n= at all.

GregoryGHarding wrote:

tomos81 wrote:

Steve Sokolowski wrote:
Don't use the same worker name for every order. Instead, use different "n=" password arguments, or omit n=.

I am using different name for every worker. but nicehash is making more groups with same worker name within single order - pls see my screenshot above.. they are acting like 2..n same workers with same name within 1 order, that i cannot change.

sorry tomos, that isn't an issue with prohashing, that needs to be handled by nicehash. to avoid worker names being given in groups, do not use n= at all.

yes i know about that. but with new rule of Steve, i need to make 10-15 single workers to get that hashing power that i got before.

Unfortunately, this was a change that had to be made, because the mining server was having undefined behavior. The assumption is that worker names are unique, and that's how the charts are created and miners assigned to coins.

Sometime during the next week, the behavior will be changed so that a duplicate worker name results in the worker names being ignored and an error returned, instead of disconnecting the second miner.

Steve Sokolowski wrote:Unfortunately, this was a change that had to be made, because the mining server was having undefined behavior. The assumption is that worker names are unique, and that's how the charts are created and miners assigned to coins.

Sometime during the next week, the behavior will be changed so that a duplicate worker name results in the worker names being ignored and an error returned, instead of disconnecting the second miner.

what about new password parameter that will add incremental miner names (for nicehash users) for example tomos.nicehashminer is my miner and it will add automatically tomos.nicehashminer.001 etc ?

So the top 2 posts on the 2nd page.
Steve comments?

If the coin was being weighted by the system still thinking it had miners on it, then wasn't it counting the hash those ghost miners had.
If so then it must have added that hash to the AUTOPOOL hash when it divided AUTOPOOL profits to decide how much to pay each of us for our 1MH contributions during that time?

hashingpro wrote:So the top 2 posts on the 2nd page.
Steve comments?

If the coin was being weighted by the system still thinking it had miners on it, then wasn't it counting the hash those ghost miners had.
If so then it must have added that hash to the AUTOPOOL hash when it divided AUTOPOOL profits to decide how much to pay each of us for our 1MH contributions during that time?

The weights didn't change who was paid, since payments in pay per share are not determined by the coins the miner is mining.

Instead, the weights were wrong because additional miners were still being counted in the totals that are used to track hashrate distribution. We added totals a year ago once we found it was too CPU intensive to add up all the hashrates every time coin assignment was performed. It is not known whether profits will be higher or lower as a result of the change, only that they will be more accurate to what is actually earned.

As stated above, the reported profitability at the top of the page was not affected. It simply reports what miners are being paid right now, regardless of whether that number is right or wrong.