Page 2 of 2

Re: Proposal: Verified mining

Posted: Wed Sep 16, 2020 3:52 pm
by Steve Sokolowski
The issue with renting others' rigs is that we believe that these other rigs are primarily responsible for the lower luck because whoever is renting those rigs has bad firmware or something else is wrong with them. It's not that you intend to cause problems or even that you know there are problems with these rigs.

Maybe we would need to have a way to specify that you want certain miners to be "unverified," in which case these rented miners could earn the lower rate and verified miners wouldn't have to be responsible if they have low luck.

In response to the second issue, it would be unlikely that the database could be hacked because the documents themselves would not be saved (just their contents) and it would be stored offline. Banks need to store data online as a matter of doing business, which is how hackers get to them.

Re: Proposal: Verified mining

Posted: Wed Sep 16, 2020 6:03 pm
by ryguy
Steve Sokolowski wrote: Wed Sep 16, 2020 3:52 pm The issue with renting others' rigs is that we believe that these other rigs are primarily responsible for the lower luck because whoever is renting those rigs has bad firmware or something else is wrong with them. It's not that you intend to cause problems or even that you know there are problems with these rigs.

Maybe we would need to have a way to specify that you want certain miners to be "unverified," in which case these rented miners could earn the lower rate and verified miners wouldn't have to be responsible if they have low luck.
I understand where you're coming from with this whole policy due to how you perceive the issues with luck, but why would you assume rented rigs are in any way different from personally owned rigs? Perhaps this is some ignorance on my part, but with systems that track share submission how would it be possible to not submit the proper amount of hashrate? I could see this potentially being beneficial if one could detect that a share would find a block and somehow direct that to oneself, but I'm not clear on how that would be implemented, nor would it be a limiting factor between rented or personally owned rigs.

Clearly I'm not aware of your criteria for a "low luck miner", but I see no difference between renting a bad rig with other good rigs from a service and owning a bad rig with other good rigs. Presumably both would cause a similar amount of lower luck. I also recognize that your luck improved significantly once you suspended service to NH customers, but I again see no reason why that would imply anything about rentals in general. My understanding is that NH has their own software implementations, which very well could be the cause of the lower luck, it could be their policies, a combination of both or some other factor.

I thought the idea of being personally liable, as was proposed, would be to encourage individuals that are renting these rigs to somewhat police the owners, while allowing PH to recoup financial losses. This isn't a possibility on NH, which is why suspending service to them made sense to me. MRR, however, is different as individual rigs and not general hashrate is being rented, so if a user becomes suspicious of a rig, it or the entire owner can be excluded from consideration. However to do so requires information from the pool, which likely would be the information that the account has or is approaching low luck, as you said most renters wouldn't be able to tell there was a problem.

The only reason to fully exclude an entire source is for determination if that source is a problem, so I could see this as a temporary policy, but I'm not sure it makes sense as something that would be done permanently. Of course if the entire purpose of this policy is to investigate whether rentals are the source of low luck, then you would have to exclude them assuming you can trust the personally owned rigs. If that's the case, then I have no problem with that. In fact, you'd have to have a pool of miners that is specifically for rentals only, so you could compare them directly to a pool of non-rented rigs that are trusted in order to draw any conclusion about rented rigs. Without separating the rentals specifically, as you did when banning NH customers which allowed you to reach a conclusion about their effect on luck, then the only conclusion you could reach is that some rigs in the non-trusted pool are causing low luck, but not which ones specifically.

But again maybe I'm just ignorant about some of this topic.

Re: Proposal: Verified mining

Posted: Thu Sep 17, 2020 1:18 pm
by mrhashem
The Option that is Optional is good.
It's a good idea. Don't think there are downside of it...

Re: Proposal: Verified mining

Posted: Thu Sep 17, 2020 2:48 pm
by Steve Sokolowski
ryguy wrote: Wed Sep 16, 2020 6:03 pm
Steve Sokolowski wrote: Wed Sep 16, 2020 3:52 pm The issue with renting others' rigs is that we believe that these other rigs are primarily responsible for the lower luck because whoever is renting those rigs has bad firmware or something else is wrong with them. It's not that you intend to cause problems or even that you know there are problems with these rigs.

Maybe we would need to have a way to specify that you want certain miners to be "unverified," in which case these rented miners could earn the lower rate and verified miners wouldn't have to be responsible if they have low luck.
I understand where you're coming from with this whole policy due to how you perceive the issues with luck, but why would you assume rented rigs are in any way different from personally owned rigs? Perhaps this is some ignorance on my part, but with systems that track share submission how would it be possible to not submit the proper amount of hashrate? I could see this potentially being beneficial if one could detect that a share would find a block and somehow direct that to oneself, but I'm not clear on how that would be implemented, nor would it be a limiting factor between rented or personally owned rigs.

Clearly I'm not aware of your criteria for a "low luck miner", but I see no difference between renting a bad rig with other good rigs from a service and owning a bad rig with other good rigs. Presumably both would cause a similar amount of lower luck. I also recognize that your luck improved significantly once you suspended service to NH customers, but I again see no reason why that would imply anything about rentals in general. My understanding is that NH has their own software implementations, which very well could be the cause of the lower luck, it could be their policies, a combination of both or some other factor.

I thought the idea of being personally liable, as was proposed, would be to encourage individuals that are renting these rigs to somewhat police the owners, while allowing PH to recoup financial losses. This isn't a possibility on NH, which is why suspending service to them made sense to me. MRR, however, is different as individual rigs and not general hashrate is being rented, so if a user becomes suspicious of a rig, it or the entire owner can be excluded from consideration. However to do so requires information from the pool, which likely would be the information that the account has or is approaching low luck, as you said most renters wouldn't be able to tell there was a problem.

The only reason to fully exclude an entire source is for determination if that source is a problem, so I could see this as a temporary policy, but I'm not sure it makes sense as something that would be done permanently. Of course if the entire purpose of this policy is to investigate whether rentals are the source of low luck, then you would have to exclude them assuming you can trust the personally owned rigs. If that's the case, then I have no problem with that. In fact, you'd have to have a pool of miners that is specifically for rentals only, so you could compare them directly to a pool of non-rented rigs that are trusted in order to draw any conclusion about rented rigs. Without separating the rentals specifically, as you did when banning NH customers which allowed you to reach a conclusion about their effect on luck, then the only conclusion you could reach is that some rigs in the non-trusted pool are causing low luck, but not which ones specifically.

But again maybe I'm just ignorant about some of this topic.
I'm willing to propose in our 3pm call today that once a miner is verified, we are trusting them to police themselves, as you said. In that case, we could also allow them to use Nicehash miners. We could add a way to show luck and whether the deviation is approaching statistical significance.

My guess is that once the program is adopted, we're going to see luck on the trusted pool shoot up to 99%, while on the untrusted pool it's going to fall to 70% or lower. From the reading I've done, it seems like low-luck miners are prevalent across all pools, and 90% is the average in normal mining. If it is true, as we suspect, that trusted mining will yield higher profits than average miners do, Prohashing will eventually end up being almost exclusively a trusted pool and that will be its selling point.

But all of that depends on whether the trusted miners actually know that their rigs are operating correctly. We don't want to have to sue people who bought secondhand rigs from China and they don't even know that they were ripped off. So it seems that you're right - there has to be some way to provide the trusted miners with feedback so they can investigate themselves what's wrong.

We might as well provide this feedback to everyone, as perhaps people not participating will choose to fix their issues, even if there is no way to ensure they are honest.

Re: Proposal: Verified mining

Posted: Fri Sep 18, 2020 9:58 am
by ryguy
Thanks for considering my thoughts Steve. I know I would appreciate having information that I am approaching low-luck as it would allow me to track down problem rentals and not support them and/or inform the owner of the issues to see if they can do anything about it, assuming they exist.

I am interested to see how this program goes and will continue to use prohashing as my primary pool as long as I am able :)