Status as of Friday, October 16

A brief status update going into the weekend:

• There are three main tasks for this weekend. First, we plan to release Cryptopia trading tonight, which should improve profitability. There are as many markets in Cryptopia as there are in all other exchanges combined.
• Second, I plan to implement special code to work around Nicehash mining limitations, so that customers renting Nicehash hashpower can still receive a (somewhat suboptimal) experience.
• Third, we are going to take a detour from multiple algorithms to make a change to our orphan handling. After the weekend, when an orphaned block is detected, we will begin mining a second block built on top of the orphaned block. If we find the next block, that means we orphan the block that would have orphaned our block. This change will allow us to have times of "double payouts" when the last block was orphaned. The profitability increase will be significant, especially for coins where orphan rates are high.

Thanks as always!

The Cryptopia sounds promising.
Can you elaborate a little on the Nicehash specific change?

Nicehash created an error message that states that any pool that issues shares of low difficulty is not a "modern" pool. These shares are supported by the stratum protocol and the miners themselves, but their software causes this error message to block them out. Because work restart testing is performed at difficulty 16, that makes Nicehash incompatible with work restart testing.

To eliminate this problem, we will treat Nicehash customers differently than other people, but to make the solution live we need to determine their IP addresses. For right now, we're going to wait until a Nicehash customer replies to my post in the "support" forum identifying themselves as using Nicehash to connect here. Once someone does, then we'll be able to perform a database search to determine Nicehash's IP addresses and enable special filtering specific to their business.

I agree.
I find that, in general, work restart testing is currently incompatible with Nicehash.
Not only does it fail, and cause a less than desirable value to be assigned, but it causes issues with the order itself. (low hashrate, periods of inactivity, etc..)

The solution I use is not allow restart testing to happen by hardcoding the r=xxxx. (Thanks for that option BTW)
Granted this is potentially not optimal but, it works well for me when I use Nicehash.
I do see a decent amount of what I call "loss" but I am pretty sure that is due to the switching nature of Prohashing and how Nicehash deals with such situations, which is a separate topic...

The problem with these cloud mining services is that you don't know exactly what you're getting.

From what I know, none of the mining rental providers displays much information on the type and location of miners that you are actually renting. As kires found out, there are some mining rigs that have a work restart time of 3s, and others that are less than 100ms, which is a huge difference in profitability. Mintsy is the worst of them, as like Cryptsy they don't reply to customer service tickets.

We have another fix for Nicehash that should improve mining performance by the end of the weekend, too, that deals with testing while mining is in progress.

I agree with all that and I hope your fixes provide some benefit.

If I am not mistaken Nicehash works like a aggregating stratum proxy so that the detail of the miners is lost, and potentially not important. (Maybe kinda sorta?)
You ask for 300MH and you get one miner, one connection, with 300MH. 2GH, one miner, one connection with 2GH.
If you do not set values for d=, and in Prohashing's case r=, then most pools will have issues?
All you can do is set d= and r= to something, monitor and adjust.

With some other providers, especially where you are renting a single physical miner, I have seen more a set it and forget it approach. (Thanks Ron Popeil!)

Wuher, owner of IPOminer, basically told nicehash to go screw themselves when nicehash stopped being nice to pools. Steve, talk to Wuher I'm sure he has the info you seek.

How about a password argument to ID NiceHash rigs? N=yasureyoubetcha or something more succinct?