Prohashing Mining Pool Forums

I wanted to make a post proposing some possible changes to static coin mining.

Earlier today, we noticed that some customers appeared to be using an undocumented API to put huge amounts of hashpower on low-difficulty coins. We modified the API, which would cause third party software using it to stop working, and noticed that profitability increased. The increased profitability won't be fully reflected in today's earnings because it was so late in the day. Because this API was undocumented, we made no warranty that it would remain unchanged.

Static coin mining is intended to mine a specific coin all the time. The customers in question are reducing others' profitability by causing the pool to orphan its own blocks, and by increasing the difficulty of those coins for switching miners.

While AppleMiner suggested addressing the problem by disallowing static coin mining, I don't think that is necessary yet. I want to hear some feedback about the best way to allow full-time static coin miners to mine, while encouraging other miners to join the dynamic mining pool. My initial thought is to simply change the terms of service to prohibit static coin switching. If that isn't sufficient, then we can prohibit users from mining more than a limited number of unique static coins per day. In conjunction with these changes, I'll also work on a captcha to eliminate the possibility of automated software subscribing to it. On the other hand, I want to limit the number of changes because this issue has yet again delayed SHA-256 mining.

What are your thoughts about static coin mining? Should this type of mining be unrestricted, or should there be limits on usage?

you guys have been familiar with the people using undocumented API for a long time and refused to do anything about it. i said back then it would effect profitability, and the response i got was that its so small its not important.

if you want to limit the static coin mining now, limit it by hashrate, the same way you limited connections to specific low difficulty coins back a few months ago.. regardless of if they get the undocumented api working again, the system wont let them connect to the targeted coins if their over their hash limit or d/c miners that force the hashrate higher than a set % limit

OR

you can throw a simple timer on worker connections that use the c= command, cannot reconnect with different c= until X minutes from last c= connect

GregoryGHarding wrote:you guys have been familiar with the people using undocumented API for a long time and refused to do anything about it. i said back then it would effect profitability, and the response i got was that its so small its not important.

if you want to limit the static coin mining now, limit it by hashrate, the same way you limited connections to specific low difficulty coins back a few months ago.. regardless of if they get the undocumented api working again, the system wont let them connect to the targeted coins if their over their hash limit or d/c miners that force the hashrate higher than a set % limit

OR

you can throw a simple timer on worker connections that use the c= command, cannot reconnect with different c= until X minutes from last c= connect

I like this timer idea. It's a lot simpler than limiting the number of coins mined in a day or anything like that, and it doesn't require persistent storage.

It's true that this possibility has existed for a long time, but it has never been a significant problem until now. That's either because more customers are doing it now, or (more likely) because there were other bugs that were more urgent and caused more problems due to the lack of manpower.

it seems like a waste to put huge amounts of hashrate on low difficulty coins. maybe try telling (another challenge in itself) the people doing it to stop it because they don't understand what they're doing to the network and pool, and if they do understand what they're doing and keep doing it then ban them. i don't really see a problem with static mining low difficulty coins with small miners if the rest of the pool isn't mining it due to h= or miner assignment queue, but too much hashrate just breaks things.
i agree with hashrate limits on coins based on their difficulty. right now i think a lot of small miners have moved away from prohashing with the minimum static difficulty, leaving that spot to be filled with big miners, so it's not that unexpected to see people with L3+ trying to static mine easy coins.
another thought, limit the amount of information about individual coin profitability.

When you see a miner with huge amounts of hashrate on low difficulty coins ...just ban those IP address for an hour ...rinse and repeat ...IMHO

another idea is to make a new mining mode that could be selected in pw arguments, making the miner assignment for dynamic coin mining so it assigns coins to workers based on network difficulty and worker hashrate so it beats out any API they could come up with. obviously profits would be miserable but miners get to see more blocks found while getting enough miners on enough coins to make a dent in the profitability of whoever decides to dump huge hash on easy coins.
maybe this is moving in the other direction and would lead to a lot of shitcoins piling up that can't be sold if anything goes wrong with exchanges, but it's just an idea.

Impose an undocumented feature fee on mined coin of 50% to discourage this behavior. Socialize the fee into the rest of the pool for other miners. S

Steve Sokolowski wrote:I wanted to make a post proposing some possible changes to static coin mining.

Earlier today, we noticed that some customers appeared to be using an undocumented API to put huge amounts of hashpower on low-difficulty coins. We modified the API, which would cause third party software using it to stop working, and noticed that profitability increased. The increased profitability won't be fully reflected in today's earnings because it was so late in the day. Because this API was undocumented, we made no warranty that it would remain unchanged.

Static coin mining is intended to mine a specific coin all the time. The customers in question are reducing others' profitability by causing the pool to orphan its own blocks, and by increasing the difficulty of those coins for switching miners.

While AppleMiner suggested addressing the problem by disallowing static coin mining, I don't think that is necessary yet. I want to hear some feedback about the best way to allow full-time static coin miners to mine, while encouraging other miners to join the dynamic mining pool. My initial thought is to simply change the terms of service to prohibit static coin switching. If that isn't sufficient, then we can prohibit users from mining more than a limited number of unique static coins per day. In conjunction with these changes, I'll also work on a captcha to eliminate the possibility of automated software subscribing to it. On the other hand, I want to limit the number of changes because this issue has yet again delayed SHA-256 mining.

What are your thoughts about static coin mining? Should this type of mining be unrestricted, or should there be limits on usage?

I think there should be a minimum time in seconds that is required to mine a statically mine a coin before being allowed to switch to another coin manually. If people want to use "switching" they should be using the dynamic mining pool, not one they derived themselves from the API. The amount of time should be large enough to allow someone to change that wants to change for legitimate reasons while simultaneously discouraging someone from creating their own "dynamic switching" between only coins they desire. Those that try to switch too quickly lose connectivity for a short time as an initial action done and those that persist this activity should be disconnected from mining for an extended period... similar to how flooding lockouts work.. first few times it's only a few second delay and a warning for switching too quickly. Multiple repeated infractions result in something like a 10 minute IP ban or something to prevent these individuals from using multiple accounts to "switch coins" and bypass any checks in place.

whichever solution is opted for, i think it's majorily important that it does not effect the pools profits, even if it's not taking down profits by a lot, there should not be an incentive what so ever to be abused for some individual to ruin the profits for the rest.

Eyedol-X wrote:

Steve Sokolowski wrote:I wanted to make a post proposing some possible changes to static coin mining.

Earlier today, we noticed that some customers appeared to be using an undocumented API to put huge amounts of hashpower on low-difficulty coins. We modified the API, which would cause third party software using it to stop working, and noticed that profitability increased. The increased profitability won't be fully reflected in today's earnings because it was so late in the day. Because this API was undocumented, we made no warranty that it would remain unchanged.

Static coin mining is intended to mine a specific coin all the time. The customers in question are reducing others' profitability by causing the pool to orphan its own blocks, and by increasing the difficulty of those coins for switching miners.

While AppleMiner suggested addressing the problem by disallowing static coin mining, I don't think that is necessary yet. I want to hear some feedback about the best way to allow full-time static coin miners to mine, while encouraging other miners to join the dynamic mining pool. My initial thought is to simply change the terms of service to prohibit static coin switching. If that isn't sufficient, then we can prohibit users from mining more than a limited number of unique static coins per day. In conjunction with these changes, I'll also work on a captcha to eliminate the possibility of automated software subscribing to it. On the other hand, I want to limit the number of changes because this issue has yet again delayed SHA-256 mining.

What are your thoughts about static coin mining? Should this type of mining be unrestricted, or should there be limits on usage?

I think there should be a minimum time in seconds that is required to mine a statically mine a coin before being allowed to switch to another coin manually. If people want to use "switching" they should be using the dynamic mining pool, not one they derived themselves from the API. The amount of time should be large enough to allow someone to change that wants to change for legitimate reasons while simultaneously discouraging someone from creating their own "dynamic switching" between only coins they desire. Those that try to switch too quickly lose connectivity for a short time as an initial action done and those that persist this activity should be disconnected from mining for an extended period... similar to how flooding lockouts work.. first few times it's only a few second delay and a warning for switching too quickly. Multiple repeated infractions result in something like a 10 minute IP ban or something to prevent these individuals from using multiple accounts to "switch coins" and bypass any checks in place.

Based upon what people here have said, I think I've come up with an improvement to GregoryGHarding's initial suggestion. I can make it so that once an IP address starts mining a static coin, a timer begins and the miner is not allowed to switch to a different coin until the timer expires.

This is better than Greg's suggestion because if the timer begins at the end of mining, normal users will always have to wait before changing to a new coin, even if they made a mistake. With this minor modification, we can make the timer something as low as 60s, and normal users won't even notice that there is a timer at all.