Status as of Wednesday, May 23, 2018

[Steve Sokolowski]

Good morning!

• Last night, we attempted a release to significantly improve profitability for most miners, but failed and reverted the changes. The problem is that when a NiceHash miner connects with a large amount of hashrate, and the miner happens to be assigned to any mining server except the master, the hashrates that are extrapolated from the master do not accurately represent the pool's distribution of work across all the coins. The solution is to write a centralized process that listens to hashrate totals from all the servers and to add them together, and then to use those proportions to determine payouts. Once released, the effect will be that large NiceHash rentals will be paid less, because they will cause a greater proportion of the pool's mining to fall upon the less profitable coins, and that other miners will be paid 4% more, because we will be able to lower our target profit that was previously being used to offset the losses caused by the bug. Unfortunately, however, the release failed and we will need to continue troubleshooting the problem today.
• The upcoming holiday will see the system move into "reduced support" mode between Friday and Sunday. Regular support will resume on Monday. As has happened for the past three years, during reduced support periods simple tickets are resolved quickly, while complex but individual issues may see a delay until regular support resumes.
• After the issue with hashrates is resolved, we will be moving onto support for ASICBoost, followed by the resumption of Ethereum mining development. Now that the website is stable and notifications have been improved, Constance's current task is work on charity mining. Having had less time since his hiring, Vance is still working to make his portion of the system (the backend trader) more reliable and has already made significant progress towards detecting and disabling coins with forks and other errors so that less money is wasted. We think that about 1.5%, or a half million dollars, of the pool's revenue was wasted due to bugs, slippage, and unnecessary fees last year while we were unable to obtain a lawyer to give us permission to proceed. This 1.5% can be passed onto customers if eliminated, and our goal is to half the amount of wasted money in the next few months.

[Varashilo]

the effect will be that large NiceHash rentals will be paid less.


This is bad news, what % of profit will be lost with new release?

[CSZiggy]

why bother, no one cares.

[Steve Sokolowski]

Good morning!

[*] the hashrates that are extrapolated from the master do not accurately represent the pool's distribution of work across all the coins.
The solution is to write a centralized process that listens to hashrate totals from all the servers and to add them together, and then to use those proportions to determine payouts. Once released, the effect will be that large NiceHash rentals will be paid less, because they will cause a greater proportion of the pool's mining to fall upon the less profitable coins, and that other miners will be paid 4% more, because we will be able to lower our target profit that was previously being used to offset the losses caused by the bug. Unfortunately, however, the release failed and we will need to continue troubleshooting the problem today.

So if before the nicehash power wasn't computed correctly to determine payouts and after changes it will, how won't that new payout value affect EVERY miner for what they get paid out and not just the nicehash power.

I'm lost on this effect on nicehash causing a greater proportion of the pool to go to less profitable coins. Does anyone adding 10+ machines not face the same results? The adding of the power forces people onto lower coins. The people mining those less profitable coins will be making less right? Then the less payouts trickle down to everyone on the pool right?

Are you somehow flagging incoming connections from nicehash so they aren't paid 4% more? Otherwise same as the lowered payouts, that 4% more returned due to bugs will also filter to the nicehash power miners.

Sounds to me like the pool was just calculating its power incorrectly to base the payouts and now you are adding the power correctly so the payouts match better. But payouts are payouts, if they go down 10%, don't they go down 10% for everyone? Not just people coming in from 1 miner rental?

If the 4% more paid due to bugs doesn't cover the amount lost due to accurately figuring the hashpower to compute the payout rates, then I think it might help the pool from losing money but I don't see any payout gains, if anything losses from this.

NiceHash miners tend to join at the times that the pool is the most profitable, and then they leave during periods where profitability is less. NiceHash miners are more likely to connect to a slave mining server than the primary, because there are more slave mining servers than primaries.

The hashrates are incorrect because there is an incorrect assumption that the total hashrate would be, on average, the primary hashrate times the number of servers. It turns out that the load isn't equally distributed, because hashrate from NiceHash all tends to go to one server. In the case of equihash mining, sometimes we would be only able to assign a maximum of 100KS/s out of a total pool hashrate of 300Ks/s on a particular coin without orphaning our own blocks, and 3MS/s would suddenly arrive at the pool on the same slave. The slave server would correctly understand that so much hashrate can't mine the coin, and assign that hashrate to ZCash. Until this release, there was no way to communicate that new weighting to the share inserters, so miners were wrongly credited at the primary server's weighting, which was 33% the profitable coin. Now, it will be 3% the profitable coin, which is the accurate total across all servers.

Once fixed, the actual total hashrates will be used, lowering profitability during some periods when lots of NiceHash miners come in, because a lot of them will be assigned to litecoins and the correct proportion of hashrate assigned to each coin will now be able to be used for calculations. The 30% lower profits during those periods will be able to be distrbuted to customers by raising profitability overall by 4%.

[CSZiggy]

why bother, no one cares.

[Steve Sokolowski]

Until this release, there was no way to communicate that new weighting to the share inserters, so miners were wrongly credited at the primary server's weighting, which was 33% the profitable coin. Now, it will be 3% the profitable coin, which is the accurate total across all servers.

Once fixed, the actual total hashrates will be used, lowering profitability during some periods when lots of NiceHash miners come in, because a lot of them will be assigned to litecoins and the correct proportion of hashrate assigned to each coin will now be able to be used for calculations. The 30% lower profits during those periods will be able to be distrbuted to customers by raising profitability overall by 4%.

"Once released, the effect will be that large NiceHash rentals will be paid less, "
I still don't see how this only effects NiceHash rentals and not every single miner. Having the corrected payouts means everyone mining will get those payouts and not just the nicehash rentals. So if someone brings in 20GH of scrypt from mining-rig-rentals won't it affect the same way? It gets added to all the hash from all the other servers, values get used to calc payout, and all the miners get that payout.



Are the nicehash miners coming in on PPS autopool?
I would think they have bots running, and anytime donation coin pops up at 6.0 cents vs the litecoins at .59 cents they mine with c=donationcoin.
When donation coin pops off and nothing else is up they leave. If they were in the autopool I see how you could shift the new incoming hash to zcash or litecoins, but do many come in at high profit times and mine on the autopool? Or are they targeting just 1 coin in static mode then switching or leaving?

You're right that this issue doesn't just affect NiceHash miners, but anyone who quickly connects lots of hashrate. It doesn't affect MiningRigRentals for a different reason - because MiningRigRentals has an exploit where their customers can rent miners that send hundreds of thousands of invalid authentication requests through the service, and get everyone banned because they all come from the same IP address. I don't think that MiningRigRentals is usable here at the moment because of that problem.

As the post states, every miner is affected because the weights will now more accurately reflect the coins being mined at the time that the hashrate goes up a lot. Those periods will now be accurate, allowing the money that was being wasted during those short periods to be distributed to miners who are connected all the time.