MINING RIG RENTAL NO HASHRATE

[wcass69]

I have rented and tried multiple Mining Rig Rental rigs and cannot connect to your site.
Here are my settings:
stratum+tcp://prohashing.com:3333
mocap3069
a=sha-256 n=RENT d=13970
I change it to another site and the rental works fine.
Any suggestions?

[Steve Sokolowski]

I have rented and tried multiple Mining Rig Rental rigs and cannot connect to your site.
Here are my settings:
stratum+tcp://prohashing.com:3333
mocap3069
a=sha-256 n=RENT d=13970
I change it to another site and the rental works fine.
Any suggestions?

The difficulty you're using isn't a power of 2. Difficulties must be provided in powers of 2, so you can either remove the "d=" argument or change it to a power of 2 if you want to have a static difficulty.

[ryguy]

The difficulty you're using isn't a power of 2. Difficulties must be provided in powers of 2, so you can either remove the "d=" argument or change it to a power of 2 if you want to have a static difficulty.

Steve, I have noticed this issue as well on MRR and since I do not have a difficulty setting in my password arguments (just a=sha-256) that is not the problem. It appears that certain SHA256 rigs will not produce hashrate on PH even though they run fine on other pools. As such, there is no way to reliably rent SHA256 from MRR to this pool.

[Steve Sokolowski]

The difficulty you're using isn't a power of 2. Difficulties must be provided in powers of 2, so you can either remove the "d=" argument or change it to a power of 2 if you want to have a static difficulty.

Steve, I have noticed this issue as well on MRR and since I do not have a difficulty setting in my password arguments (just a=sha-256) that is not the problem. It appears that certain SHA256 rigs will not produce hashrate on PH even though they run fine on other pools. As such, there is no way to reliably rent SHA256 from MRR to this pool.

In those cases, are you able to connect to the system at all, or does the system just not allow connections?

I know that MiningRigRentals retries too often when someone uses invalid password arguments from a rental, and they have a limited number of IP addresses. I think that causes other renters to be banned if someone else was using an invalid username or password.

[ryguy]

It connects fine, however, no hashing appears to be done. If it was a connection issue I would get a message about authorization failures or the rig would fall over to my backup pool, but that's not what happens. The worker(s) merely produce 0 hashrate while connected.

The strange part is that it is not every SHA256 rig that I have rented and nothing appears to be different about the ones that have the issue and those that do not.

[CSZiggy]

If its SHA being rented, do they maybe have asic boost enabled to inflate numbers and with it not supported here causes some error?

[ryguy]

I know that MiningRigRentals retries too often when someone uses invalid password arguments from a rental, and they have a limited number of IP addresses. I think that causes other renters to be banned if someone else was using an invalid username or password.

Doesn't that seem like a serious logic issue (and potential vector for malicious activity)? If this is true, then someone could intentionally rent a rig from MRR with bad credentials and get anyone that is renting there (or at least on that IP from MRR) to be banned from your pool. Why would you not just ban the connection with the bad credentials instead?

[ryguy]

If its SHA being rented, do they maybe have asic boost enabled to inflate numbers and with it not supported here causes some error?

Possibly, but I do not believe I have a way to determine that.

[Steve Sokolowski]

I know that MiningRigRentals retries too often when someone uses invalid password arguments from a rental, and they have a limited number of IP addresses. I think that causes other renters to be banned if someone else was using an invalid username or password.

Doesn't that seem like a serious logic issue (and potential vector for malicious activity)? If this is true, then someone could intentionally rent a rig from MRR with bad credentials and get anyone that is renting there (or at least on that IP from MRR) to be banned from your pool. Why would you not just ban the connection with the bad credentials instead?

This isn't just a problem with MiningRigRentals; anyone who uses a shared connection can do that to other customers. Next week, we'll be aggressively submitting abuse reports to more ISPs.

There are a few customers who have submitted support tickets about this issue. I responded that the only choice was for them to switch hosting facilities, because the hosting provider did not respond to the abuse report filed against the other customer who was causing too many invalid authentication attempts on the same IP address. The only way to reasonably block traffic is to drop it at the router, because it takes too much CPU to process authentication requests, and both the good and the bad customers come from the same address.

Comcast, for all everyone has to say about their customer service, takes abuse reports seriously. We got three of their customers disconnected already. One of my goals over the next week is to go through all the addresses who are wasting resources and getting the residential customers disconnected who are calling checkPassword on the website or authorize on the mining server millions of times. I'm sure their husbands or wives or kids will be happy to learn they now can't get Internet service because they are running software to log into mining servers every millisecond.

[ryguy]

I know that MiningRigRentals retries too often when someone uses invalid password arguments from a rental, and they have a limited number of IP addresses. I think that causes other renters to be banned if someone else was using an invalid username or password.

Doesn't that seem like a serious logic issue (and potential vector for malicious activity)? If this is true, then someone could intentionally rent a rig from MRR with bad credentials and get anyone that is renting there (or at least on that IP from MRR) to be banned from your pool. Why would you not just ban the connection with the bad credentials instead?

This isn't just a problem with MiningRigRentals; anyone who uses a shared connection can do that to other customers. Next week, we'll be aggressively submitting abuse reports to more ISPs.

There are a few customers who have submitted support tickets about this issue. I responded that the only choice was for them to switch hosting facilities, because the hosting provider did not respond to the abuse report filed against the other customer who was causing too many invalid authentication attempts on the same IP address. The only way to reasonably block traffic is to drop it at the router, because it takes too much CPU to process authentication requests, and both the good and the bad customers come from the same address.

Comcast, for all everyone has to say about their customer service, takes abuse reports seriously. We got three of their customers disconnected already. One of my goals over the next week is to go through all the addresses who are wasting resources and getting the residential customers disconnected who are calling checkPassword on the website or authorize on the mining server millions of times. I'm sure their husbands or wives or kids will be happy to learn they now can't get Internet service because they are running software to log into mining servers every millisecond.

So essentially because there are users that are (intentionally or not) causing problems you throw the baby out with the bath water? I understand why you would just drop the traffic if the connection is coming from a residence or some other unknown point, but when the traffic is coming from a known service, such as MRR, why would you punish everyone to avoid a bad actor?

Essentially you're telling me that if I continue to send you mining rigs from MRR I have some percentage chance of getting kicked off through no fault of my own.