Status as of Friday, July 21, 2017

[Steve Sokolowski]

Good morning! Here's a few thoughts for today.

• I'm back, after some time away for my other job. I was disappointed to see that service quality wasn't the best while I was gone. This weekend, I'll be working on splitting apart the mining server into smaller components, which will be distributed across even more cores.
• The problems earlier in the week were caused by misconfigured miners, which were sending shares at an extremely low difficulty. There are some miners with enormous hashrates, as high as 50GH/s, which have x11 static difficulties of 0.1. Now, when one of these miners connects, we reassign that miner to a higher dynamic difficulty. The customer has the opportunity to either raise the static difficulty to prevent the error, or simply do nothing, in which case the system will raise the difficulty and reduce load. In either case, profitability is not affected by difficulty.
• Chris, meanwhile, is devoting his time to writing automation programs. Now, he can discontinue a coin automatically; one command will do everything from modifying the database, to paying out customers, to selling out all our reserve on the market, to shutting down the daemon, to removing the block explorer data, and to deleting out the blockchain.
• Other than that, there isn't much to say - the weekend will be devoted to backend performance improvements that won't be visible to anyone here. I'll report back on Monday. In the meantime, be wary of bitcoin prices, and don't sell Bitcoin Cash, despite its expected initial crash. The group who is pushing what's happening now as having "solved" the blocksize debate is incorrect, and the ratio of BTC/BTCC is going to make a surprising adjustment in a few months as the current misguided euphoria fades away.

[Tom3]

Thanks for your work. I would be happy to come back to your altcoin pool.
What I am wondering is what you mean the group who is pushing what's happening now as having "solved" the blocksize debate is incorrect. You are not a btc pool.
For all who do not know, check this page: www.xbt.eu
95.1% is wrong.

[FRISKIE]

@Tom3,

Steve's guidance is prudent, to hold BCC and wait for a few months.

Either BIP91 supporters are correct, and all will be well.

Or they are not, and BCC will be rising

Cheers,
FRISKIE

[mine_x]

Steve,

I appreciate your efforts to make pool stable and still profitable. However the last feature you have applied when low stat diff miners with BIG hashrate are switching to high diff by pool decision - in order to keep share per second less than 1, seems did not give the effect. What I see is that after the low stat diff has been switched to high vardiff by pool, the diff is slowly rising to 544k and no way back!!! - the diff is always 544k !! despite of shares per second miner is submitting later. This feature should be modified - allowing miner to switch to lower stat diff BACK from bloody 544 k if the No. of shares is below 1 per seconds or 1 share per 2 seconds. It is absolutely necessary since the 544 k is just killing the part of miners of our pool which are using NH orders (not the bots, just usual stable few GH fixed). I performed some measures and the 544 k (your feature with no way back to stat diff by any means, no way! ) causing the all NH orders are getting very negative delta. The fixed NH orders are profitable only with stat diff. I am not sure is this 544 k with no way back to stat diff (moderate one at least - 32k? ) feature set just to avoid any NH orders in our pool ??

Please comment, I believe this information will be useful for many miners here. Comments are about Scrypt only.

[Steve Sokolowski]

Steve,

I appreciate your efforts to make pool stable and still profitable. However the last feature you have applied when low stat diff miners with BIG hashrate are switching to high diff by pool decision - in order to keep share per second less than 1, seems did not give the effect. What I see is that after the low stat diff has been switched to high vardiff by pool, the diff is slowly rising to 544k and no way back!!! - the diff is always 544k !! despite of shares per second miner is submitting later. This feature should be modified - allowing miner to switch to lower stat diff BACK from bloody 544 k if the No. of shares is below 1 per seconds or 1 share per 2 seconds. It is absolutely necessary since the 544 k is just killing the part of miners of our pool which are using NH orders (not the bots, just usual stable few GH fixed). I performed some measures and the 544 k (your feature with no way back to stat diff by any means, no way! ) causing the all NH orders are getting very negative delta. The fixed NH orders are profitable only with stat diff. I am not sure is this 544 k with no way back to stat diff (moderate one at least - 32k? ) feature set just to avoid any NH orders in our pool ??

Please comment, I believe this information will be useful for many miners here. Comments are about Scrypt only.

Unfortunately, there's nothing we can do about this issue right now. The system has too many non-NiceHash customers and we have to prioritize those with the load we can handle.

We hope to turn off this error in the future once we improve capacity, but we don't have an estimate as to when that will be.

[mine_x]

Lets imagine capacity will be improved after the weekend and the pool will work just excellent. Then probably you should just limit lowest static diff (as many pools do) and then turn this buggy "one way diff increase" off, especially taking into account not only NH miners, but also the usual miners. As I read from chat and forum, the real L3+ is also getting 544 k diff soon just after the start of hashing and this diff causes share submission by usual L3+ not only 1 per second, but one per few minutes. From my practice, the extra high diff is causing looses for all pool. The managing of diff up-down per each miner as I have proposed above will eat resources of system. The limits for lowest stat diff seems to me most wise step to be implemented since it is just setting, not managing of diff depending on share per time load.

[megaquake]

Lets imagine capacity will be improved after the weekend and the pool will work just excellent. Then probably you should just limit lowest static diff (as many pools do) and then turn this buggy "one way diff increase" off, especially taking into account not only NH miners, but also the usual miners. As I read from chat and forum, the real L3+ is also getting 544 k diff soon just after the start of hashing and this diff causes share submission by usual L3+ not only 1 per second, but one per few minutes. From my practice, the extra high diff is causing looses for all pool. The managing of diff up-down per each miner as I have proposed above will eat resources of system. The limits for lowest stat diff seems to me most wise step to be implemented since it is just setting, not managing of diff depending on share per time load.

set your l3+ difficulty too d=65536 thats what I use, and with NH use d=131072 per every 1gh, you may see fluctuations in pool reported speed way above and way below but earnings will balance out and most likely make more.

[mine_x]

sounds good