[ANN] MiningRigRentals.com - Web pool manager - Easy Mass Rentals - Algos!

[miningrigrentals]

Too many people don't leave a rating. The rating should be automatic, calculated on hash advertised and hash received. I always have my hash under stated but others don't and I  seem to get similar ratings as those whose average fall below their advertised rate. Also there needs to be a clearcut ending average number to look at for the timeline of each rental and the percent of the over/under from the advertised rate should be displayed on the rental page.

It's as if you were in our IRC channel yesterday. Automatic ratings is being worked on at the moment (although we find that with our service, renters don't care as much about rating). They will be calculated on accepted shares. The rental average was also requested yesterday. We have the backend code in place for this and simply need to create the front end display to enable this feature. Soon!

Lol funny, great minds think alike.

I had considered posting my WU rate in the title.

Average hashrate for the rental period is now displayed on completed rentals. Enjoy!

[Hueristic]

Too many people don't leave a rating. The rating should be automatic, calculated on hash advertised and hash received. I always have my hash under stated but others don't and I  seem to get similar ratings as those whose average fall below their advertised rate. Also there needs to be a clearcut ending average number to look at for the timeline of each rental and the percent of the over/under from the advertised rate should be displayed on the rental page.

It's as if you were in our IRC channel yesterday. Automatic ratings is being worked on at the moment (although we find that with our service, renters don't care as much about rating). They will be calculated on accepted shares. The rental average was also requested yesterday. We have the backend code in place for this and simply need to create the front end display to enable this feature. Soon!

Lol funny, great minds think alike.

I had considered posting my WU rate in the title.

Average hashrate for the rental period is now displayed on completed rentals. Enjoy!

Can't find it. You mean here?

https://www.miningrigrentals.com/rental/32525

[miningrigrentals]

Too many people don't leave a rating. The rating should be automatic, calculated on hash advertised and hash received. I always have my hash under stated but others don't and I  seem to get similar ratings as those whose average fall below their advertised rate. Also there needs to be a clearcut ending average number to look at for the timeline of each rental and the percent of the over/under from the advertised rate should be displayed on the rental page.

It's as if you were in our IRC channel yesterday. Automatic ratings is being worked on at the moment (although we find that with our service, renters don't care as much about rating). They will be calculated on accepted shares. The rental average was also requested yesterday. We have the backend code in place for this and simply need to create the front end display to enable this feature. Soon!

Lol funny, great minds think alike.

I had considered posting my WU rate in the title.

Average hashrate for the rental period is now displayed on completed rentals. Enjoy!

Can't find it. You mean here?

https://www.miningrigrentals.com/rental/32525

Yes the display would be there but you must be the renter or rig owner of the rental.

[sdmathis]

Too many people don't leave a rating. The rating should be automatic, calculated on hash advertised and hash received. I always have my hash under stated but others don't and I  seem to get similar ratings as those whose average fall below their advertised rate. Also there needs to be a clearcut ending average number to look at for the timeline of each rental and the percent of the over/under from the advertised rate should be displayed on the rental page.

It's as if you were in our IRC channel yesterday. Automatic ratings is being worked on at the moment (although we find that with our service, renters don't care as much about rating). They will be calculated on accepted shares. The rental average was also requested yesterday. We have the backend code in place for this and simply need to create the front end display to enable this feature. Soon!

Do you have a way of doing this without penalizing rigs that have customers who choose bad pools? You just don't get maximum hash at some pools.

[miningrigrentals]

Too many people don't leave a rating. The rating should be automatic, calculated on hash advertised and hash received. I always have my hash under stated but others don't and I  seem to get similar ratings as those whose average fall below their advertised rate. Also there needs to be a clearcut ending average number to look at for the timeline of each rental and the percent of the over/under from the advertised rate should be displayed on the rental page.

Bad idea. I have a customer renting one of my rigs right now on a very erratic pool and it's causing the hash rate to suffer greatly. You're saying I should be punished because the customer chose a bad pool. I don't think so.

It's not implemented in the fashion he's describing (albeit I don't entirely follow his train of thought). It's not implemented at all at this point. We're simply considering creating a "default" rating. Instead of default being nothing, default will rate well if the hashrate performed well, there will never be negative ratings in an automatic fashion.

[miningrigrentals]

Too many people don't leave a rating. The rating should be automatic, calculated on hash advertised and hash received. I always have my hash under stated but others don't and I  seem to get similar ratings as those whose average fall below their advertised rate. Also there needs to be a clearcut ending average number to look at for the timeline of each rental and the percent of the over/under from the advertised rate should be displayed on the rental page.

It's as if you were in our IRC channel yesterday. Automatic ratings is being worked on at the moment (although we find that with our service, renters don't care as much about rating). They will be calculated on accepted shares. The rental average was also requested yesterday. We have the backend code in place for this and simply need to create the front end display to enable this feature. Soon!

Do you have a way of doing this without penalizing rigs that have customers who choose bad pools? You just don't get maximum hash at some pools.

The idea is to give rigs a bonus for performing well. As you stated, there are other factors at play so we would never allow it to automatically rate negatively. Since the rating is defaulted as "no rating" we could change that and base it off accumulated share rate.

[sdmathis]

Too many people don't leave a rating. The rating should be automatic, calculated on hash advertised and hash received. I always have my hash under stated but others don't and I  seem to get similar ratings as those whose average fall below their advertised rate. Also there needs to be a clearcut ending average number to look at for the timeline of each rental and the percent of the over/under from the advertised rate should be displayed on the rental page.

It's as if you were in our IRC channel yesterday. Automatic ratings is being worked on at the moment (although we find that with our service, renters don't care as much about rating). They will be calculated on accepted shares. The rental average was also requested yesterday. We have the backend code in place for this and simply need to create the front end display to enable this feature. Soon!

Do you have a way of doing this without penalizing rigs that have customers who choose bad pools? You just don't get maximum hash at some pools.

The idea is to give rigs a bonus for performing well. As you stated, there are other factors at play so we would never allow it to automatically rate negatively. Since the rating is defaulted as "no rating" we could change that and base it off accumulated share rate.

I see. Thank you for clarifying that for me.

[coinsolidation]

MRR, there is an issue I need to speak with you about concerning your website.

From the code I read in the most popular stratum-server implementation (stratum-server), it refers to all workers by the username sent, and assigns variables like the difficulty to them.

On your website there is no option to append a unique value like a rig provider id to the username automatically.

So if I rent 20 rigs with a profile and send them to a pool (as I just have), all rigs have the same username and password, and thus the same difficulty. Whether they are 50KH/s or 150MH/s.

This is quite a big issue which can be circumvented by manually choosing a different username and password in the meantime.

But it makes the features like profiles and multibuys you have implemented almost redundant, and may lead to negative reviews when people find the lower spec rigs aren't performing (because their share diff is incorrect), or correspondingly that the large rigs have a share diff too low.

I look forward to hearing from you about this matter and hope it can be resolved quickly.

If you can find him, ahmed who maintains stratum-mining may be able to confirm if this is accurate or not.

Nevertheless, the ability to have a unique identifier for each rig automatically appended would be very useful and ensure this fault cannot happen in any software.

[merc82]

MRR, there is an issue I need to speak with you about concerning your website.

From the code I read in the most popular stratum-server implementation (stratum-server), it refers to all workers by the username sent, and assigns variables like the difficulty to them.

On your website there is no option to append a unique value like a rig provider id to the username automatically.

So if I rent 20 rigs with a profile and send them to a pool (as I just have), all rigs have the same username and password, and thus the same difficulty. Whether they are 50KH/s or 150MH/s.

This is quite a big issue which can be circumvented by manually choosing a different username and password in the meantime.

But it makes the features like profiles and multibuys you have implemented almost redundant, and may lead to negative reviews when people find the lower spec rigs aren't performing (because their share diff is incorrect), or correspondingly that the large rigs have a share diff too low.

I look forward to hearing from you about this matter and hope it can be resolved quickly.

If you can find him, ahmed who maintains stratum-mining may be able to confirm if this is accurate or not.

Nevertheless, the ability to have a unique identifier for each rig automatically appended would be very useful and ensure this fault cannot happen in any software.

You bring up a good point and a feature we're likely going to implement in the near future should help in your situation.. however this is not 100% accurate.

Most stratum vardiff pools have vardiff controlled at the connection level, the workername is merely a way to track your hashrate at the pool for various 'rigs' you might have connected.
For example, I have 2 7970's that I point at my pool on merc.1, and often rent large amounts of hash and point it to merc.1 as well.. my 7970's difficulty doesnt fluctuate when I do this, and the large rentals get appropriate difficulties for their hashrates as well.

We will likely be implementing a 'templating' feature for worker names, but you will have to ensure that the pool you chose either has the workernames existing already, or auto-adds workernames appropriately.

[coinsolidation]

MRR, there is an issue I need to speak with you about concerning your website.

From the code I read in the most popular stratum-server implementation (stratum-server), it refers to all workers by the username sent, and assigns variables like the difficulty to them.

On your website there is no option to append a unique value like a rig provider id to the username automatically.

So if I rent 20 rigs with a profile and send them to a pool (as I just have), all rigs have the same username and password, and thus the same difficulty. Whether they are 50KH/s or 150MH/s.

This is quite a big issue which can be circumvented by manually choosing a different username and password in the meantime.

But it makes the features like profiles and multibuys you have implemented almost redundant, and may lead to negative reviews when people find the lower spec rigs aren't performing (because their share diff is incorrect), or correspondingly that the large rigs have a share diff too low.

I look forward to hearing from you about this matter and hope it can be resolved quickly.

If you can find him, ahmed who maintains stratum-mining may be able to confirm if this is accurate or not.

Nevertheless, the ability to have a unique identifier for each rig automatically appended would be very useful and ensure this fault cannot happen in any software.

You bring up a good point and a feature we're likely going to implement in the near future should help in your situation.. however this is not 100% accurate.

Most stratum vardiff pools have vardiff controlled at the connection level, the workername is merely a way to track your hashrate at the pool for various 'rigs' you might have connected.
For example, I have 2 7970's that I point at my pool on merc.1, and often rent large amounts of hash and point it to merc.1 as well.. my 7970's difficulty doesnt fluctuate when I do this, and the large rentals get appropriate difficulties for their hashrates as well.

We will likely be implementing a 'templating' feature for worker names, but you will have to ensure that the pool you chose either has the workernames existing already, or auto-adds workernames appropriately.

Can you confirm that this is with workers all having an identical username, for example all "pfennig" as opposed to "pfennig.worker1" "pfennig.worker2".

See for example: https://github.com/Crypto-Expert/stratum-mining/blob/b039cbb74dc99b706e758b32d797231b3b24f43d/mining/service.py#L86

Code:

Interfaces.worker_manager.get_user_difficulty(worker_name)

If three workers all have the same worker name, then it is impossible for them not to reference the same value, at this level.

Thank you.

[merc82]

MRR, there is an issue I need to speak with you about concerning your website.

From the code I read in the most popular stratum-server implementation (stratum-server), it refers to all workers by the username sent, and assigns variables like the difficulty to them.

On your website there is no option to append a unique value like a rig provider id to the username automatically.

So if I rent 20 rigs with a profile and send them to a pool (as I just have), all rigs have the same username and password, and thus the same difficulty. Whether they are 50KH/s or 150MH/s.

This is quite a big issue which can be circumvented by manually choosing a different username and password in the meantime.

But it makes the features like profiles and multibuys you have implemented almost redundant, and may lead to negative reviews when people find the lower spec rigs aren't performing (because their share diff is incorrect), or correspondingly that the large rigs have a share diff too low.

I look forward to hearing from you about this matter and hope it can be resolved quickly.

If you can find him, ahmed who maintains stratum-mining may be able to confirm if this is accurate or not.

Nevertheless, the ability to have a unique identifier for each rig automatically appended would be very useful and ensure this fault cannot happen in any software.

You bring up a good point and a feature we're likely going to implement in the near future should help in your situation.. however this is not 100% accurate.

Most stratum vardiff pools have vardiff controlled at the connection level, the workername is merely a way to track your hashrate at the pool for various 'rigs' you might have connected.
For example, I have 2 7970's that I point at my pool on merc.1, and often rent large amounts of hash and point it to merc.1 as well.. my 7970's difficulty doesnt fluctuate when I do this, and the large rentals get appropriate difficulties for their hashrates as well.

We will likely be implementing a 'templating' feature for worker names, but you will have to ensure that the pool you chose either has the workernames existing already, or auto-adds workernames appropriately.

Can you confirm that this is with workers all having an identical username, for example all "pfennig" as opposed to "pfennig.worker1" "pfennig.worker2".

See for example: https://github.com/Crypto-Expert/stratum-mining/blob/b039cbb74dc99b706e758b32d797231b3b24f43d/mining/service.py#L86

Code:

Interfaces.worker_manager.get_user_difficulty(worker_name)

If three workers all have the same worker name, then it is impossible for them not to reference the same value, at this level.

Thank you.

In the stratum implementation you linked the sample config comes with vardiff defaulted to true, which loads this file to control the share difficulties
https://github.com/Crypto-Expert/stratum-mining/blob/b039cbb74dc99b706e758b32d797231b3b24f43d/mining/basic_share_limiter.py

The code you linked in pushes the present sessions difficulty to the connection during the authorize process, that difficulty then changes based on the speed in which the connection submits shares

[coinsolidation]

In the stratum implementation you linked the sample config comes with vardiff defaulted to true, which loads this file to control the share difficulties
https://github.com/Crypto-Expert/stratum-mining/blob/b039cbb74dc99b706e758b32d797231b3b24f43d/mining/basic_share_limiter.py

The code you linked in pushes the present sessions difficulty to the connection during the authorize process, that difficulty then changes based on the speed in which the connection submits shares

Where connection is the a pubsub connection from stratum?

Am I then correct in thinking then
1. all stats will be wrong since they are based on worker name?
2. if the difficulty is too high, say you have a 150MH worker and add another 2 MH worker, that the 2MH worker will not be able to submit any shares for it's difficulty to be adjusted down
3. if the 'big rig' disconnects it will get the starting difficulty of the last session saved diff from another rig to start, instead of it's own?

[merc82]

In the stratum implementation you linked the sample config comes with vardiff defaulted to true, which loads this file to control the share difficulties
https://github.com/Crypto-Expert/stratum-mining/blob/b039cbb74dc99b706e758b32d797231b3b24f43d/mining/basic_share_limiter.py

The code you linked in pushes the present sessions difficulty to the connection during the authorize process, that difficulty then changes based on the speed in which the connection submits shares

Where connection is the a pubsub connection from stratum?

Am I then correct in thinking then
1. all stats will be wrong since they are based on worker name?
2. if the difficulty is too high, say you have a 150MH worker and add another 2 MH worker, that the 2MH worker will not be able to submit any shares for it's difficulty to be adjusted down
3. if the 'big rig' disconnects it will get the starting difficulty of the last session saved diff from another rig to start, instead of it's own?

1. I can't speak for all pools/stats implementation, but I'm confident that most store a difficulty along with each individual share in their database.. so the difficulty associated with the username is irrelevant. Stats should be accurate regardless of using multiple workers or a single worker with different speed hashing..
2. Difficulty is determined at the connection level, so this is incorrect
3. If the stratum has ALLOW_EXTERNAL_DIFFICULTY=true, the difficulty will be pulled from the database, otherwise it will start at the configured difficulty in config.py

Again, there may be some pools out there who do vardiff incorrectly, but the stratum implementation you linked would properly handle various speed rigs connecting under the same worker name and properly hand them different difficulties based on their hashing speed.

We also understand that users would like the ability to track their rented rigs individually at their pool, thus we are implementing (in the near future) a method to allow you to template worker names in your profiles... such as merc.{ID} or merc.{COUNTER} etc -- but the current implementation should cause no issues at pools

[coinsolidation]

Again, there may be some pools out there who do vardiff incorrectly, but the stratum implementation you linked would properly handle various speed rigs connecting under the same worker name and properly hand them different difficulties based on their hashing speed.

We also understand that users would like the ability to track their rented rigs individually at their pool, thus we are implementing (in the near future) a method to allow you to template worker names in your profiles... such as merc.{ID} or merc.{COUNTER} etc -- but the current implementation should cause no issues at pools

Thank you for taking the time to address my concerns and double check this with me.

[mutex]

I keep getting this messages in sgminer for the last few hours:

Code:

[XX:XX:XX] JSON key 'data' not found
[XX:XX:XX] JSON inval data

The rig is rented. Tried all five servers, they all ping fine, and telnet to port 3333 works fine, too, but I don't get any work, so rig stays idle.

Is this issue specific to this particular rental, or what? Will I have to refund renter for the idle time?

[miningrigrentals]

I keep getting this messages in sgminer for the last few hours:

Code:

[XX:XX:XX] JSON key 'data' not found
[XX:XX:XX] JSON inval data

The rig is rented. Tried all five servers, they all ping fine, and telnet to port 3333 works fine, too, but I don't get any work, so rig stays idle.

Is this issue specific to this particular rental, or what? Will I have to refund renter for the idle time?

Hello,

This occurs when the renter's pool choice(s) are not responsive. Please keep in mind we recommend the following:

Set at least 2 MRR servers in your local config along with a pool of choice

1. Closest MRR server to your location
2. Second closest MRR server to your location.
3. Your pool of choice

With the above configuration you will have redundancy on the MRR servers (if the first one fails the second one will resume) and if both MRR servers do not work then the renter's pool is likely unresponsive and you will begin mining at your 3rd pool selection. Provided your pool is listed locally in your config file, you will end up mining for yourself.  This allows you to communicate with the renter (ask them to set more than one pool and or switch pools) and it allows you to compensate the renter without incurring a loss (should you decide to).

[miningrigrentals]

We have added in automatic rental cancellations. If you rent a rig and it's offline at least 20 minutes of the first 30 minutes of the rental, it will automatically cancel and refund you.
We've also added in "rent now" links to your profile page. Profile pages are found here: https://www.miningrigrentals.com/u/your_account_name_here

[bensam123]

There should be a way to set geographic regions for pools. So if you rent out EU rigs and US rigs, you can direct the US rigs to the US pools and the EU rigs to the EU pools. Most big pool websites have multiple pools. This could even be automated by MRR with a simply ping to a location. Further away pools would obviously be in a different geographic region or it could be done through a trace. Either way, it should be done and would help out both renters and owners.

Please add the ability to 'add more time' to existing rig rentals. So once the rental finishes it would re-rent it, only of course if it's still available for the same price, time wanted, and still set as online at the time the rental contract ends.

[miningrigrentals]

There should be a way to set geographic regions for pools. So if you rent out EU rigs and US rigs, you can direct the US rigs to the US pools and the EU rigs to the EU pools. Most big pool websites have multiple pools. This could even be automated by MRR with a simply ping to a location. Further away pools would obviously be in a different geographic region or it could be done through a trace. Either way, it should be done and would help out both renters and owners.

Please add the ability to 'add more time' to existing rig rentals. So once the rental finishes it would re-rent it, only of course if it's still available for the same price, time wanted, and still set as online at the time the rental contract ends.

First suggestion: Region specific pools. I'm not sure I fully understand your suggestion.  Are you saying if a renter selects "Dedicated pool" (example only) and they mass rent rigs, you want the rigs that are in Europe to point to the Dedicated European located stratum?  While this would be technically possible, we would have to build a large database of each pool's stratums IP addresses.  Perhaps you are asking us to reconnect a rig owner's rig to a regionally specific MRR server based on the renter's pool choice? If that's the case it likely wouldn't provide better results as the rig would still be regionally located where the rig owner "should" have specified in the listing. However, we have considered "suggesting" a primary MRR server for rig owners upon rig setup by using geolocation.

Second suggestion: Renter side extensions. This is something we've considered (slightly different concept but with the same result) and have on a future todo list.

Thank you.

[bensam123]

So, for instance Dedicatedpools has two stratums. A euro and a US stratum. When someone sets up a rig, they flag their rig for a location. When I set up pools for renting, I add pools. I would then add a geographic region of the pool or leave it as 'default' or whatever. So if there are two pools, MRR will point a euro miner at a euro pool and a US miner at a US pool, if available.

Priorities have to be taken into account. So if they're both labeled with the same priority the closer pool would take precedence. Coin mining/pool preference > geographic location.


1a. CoinAUS Supool
1b. CoinAEu Supool
2. CoinAUS Poopool
3. CoinAEU Whateverpool

(This wouldn't be automatically done, user would set their own priorities)

This would definitely be helpful for mass renting, where different geographically located miners are lumped together. MRR would direct all the miners for Euro to 1b and all the US miners to 1a. if 1b goes down, all the miners are thrown on 1a, and vice versa. Either way, how close miners are to the stratums determines how smooth mining will be and how many rejects (within reason) a user receives. This would help reduce the 'error' in the graphs caused by miners being directed to pools in different locals.


On a different note I also agree with automatic ratings instead of user ratings. They're very polar. You either have a good experience or a bad experience with rigs, there really is no in between. It's pretty straightforward, miners advertise hash rates, customers buy it, they either get the hashrate or they don't. So you end up with five stars or one stars. Although what causes the reduced hashrate would definitely be questionable and figuring out how exactly it happens and what causes it. Figuring out what exactly went wrong would be problematic. Was it a bad pool? Did the miner go down? Was it one of a few miners? How many errors are the miners spitting out? How many rejects do miners have (I don't know if MRR can actually see this)? Is the pool really far away from the miner (part of what the above idea would help with)? Did the renter not setup pools? Were pools offline?

Earlier tonight I rented a rig as well and it was offline. I was reimbursed immediately for this, but the rig went back up as available immediately after this happened. Rigs really should get flagged as offline and require miners to re-enable them if they're offline.

Also consider adding average hashrate for overall to each rental contract. Right now it shows 5/30/hour, but it doesn't show the average over the whole rental, which would be more useful at the end of the mine for future reference.

It would also be good to add the ability for MRR to send a automated message to rig owners if their hashrate drops below a certain threshold. Like if it's 20% below average or 10Mhs less then average. You could configure it so users can turn it on or off and set thresholds for it.