Stratum protocol shortcoming (Attention lozschor)

After some investigation in response to complaints about disconnections, we discovered a critical flaw in the stratum protocol for which we need to determine a solution.

Most customers use one miner per connection. However, the stratum protocol provides the ability to authorize multiple miners per connection. According to slush, who designed the original protocol, the reason for that ability was so that each mining rig in a "basement full of mining rigs" didn't need to have its own connection to send shares. In contrast, the protocol does not provide the ability to receive shares directed to individual miners.

This solution worked fine when the protocol was developed in 2011, because bitcoin was the only game in town. Miners mined the bitcoin chain only. When a new block was received, everyone in the pool was sent the same work. When that block was stale, it was fine to send all the miners the same work again.

Years later, this paradigm is obsolete, but the protocol hasn't changed. Merge mining, for example, doesn't make sense if every miner is resent work every time a new miner authorizes, because there is no need to send merge mined work for every new block. Static difficulties cannot be accurately computed with multiple miners per connection, especially when one of the miners wants a variable difficulty. Most importantly, mining a static coin with one miner but not with another in the same connection is impossible. These are all because every time work is sent in stratum, there is no way to target a specific mining rig.

Lozshor has encountered this problem. He apparently has two miners connected with different users (lozshor and MineCoins247) on the same connection. One of the miners is set to static mine litecoins, while the other isn't. The disconnections are occurring because the work submitted from each miner doesn't make sense for the other miner, which is mining a different coin.

We're trying to figure out how to deal with this issue, and suggestions are welcome. For now, one way to deal with this is to validate all password arguments for miners who are authenticated in such a way, so that the only way to connect multiple miners would be if all of them have the same password arguments. If there are two miners with differing coins on the same connection, for example, then the default would be chosen, which is to mine the most profitable coin. An error message would be presented to the user indicating that. Unfortunately, there is no way that it is possible to work around this issue because we can't modify the messages the client accepts.

Another proposal that has been discussed is encouraging the formation of a committee to implement changes to the stratum protocol to deal with this and other issues. The problems with the stratum protocol have been mounting for some time, and it would be nice to be able to extend the protocol with features like a method of obtaining what algorithms the client supports and instructing it to mine a specific algorithm.

The workaround for the specific user should be pretty clear in the short term... the second rig can use the port 443 proxy as opposed to the main port 3333.

That's not as easy as it sounds.

I think the reason that there are multiple sessions in one connection is because big mining pools or cloud service providers are aggregating connections. For example, Cryptsy may be detecting how many of its miners want to mine at this pool, combining them into one stratum connection, and their software isn't aware that different users have different preferences because most other pools are not as advanced as this one. The individual users, in this case, would not have the ability to tell Cryptsy to create individual connections for themselves, so their only choice is to mine with default settings.

Steve Sokolowski wrote:
...so their only choice is to mine with default settings.

I can think of a LOT worse things...

Forgive me late reply, I have been incredibility busy with other endeavors.

Hello, thank you for looking into the problem. At the moment I am indeed only using one password/configuration for all my miners that are currently using Prohashing. Please keep up the good work and thank you.

EDIT:

Forgive me, I am mistaken. I did have the difficulty and coin type different for each miner. I have now made them the same. I will see how that affects my mining.

Thank you.

I made use of the new "Worker" menu window now available and after reading the updated settings I entered "n=loszhor_1" and "n=loszhor_2" into the password fields of both miners and the errors mentioned stopped being reported. Even with different mining settings everything appears to be fine.

So it appears that specifically naming each worker will fix the problem. Please keep an eye on it and report back with what you can see on your end.

Thank you.

EDIT:

After more usage of the "Worker" menu I have come to learn that my rental miner isn't one miner as I was lead to believe but actually many miners working together. I am not pleased to learn this but I have set all password miner settings that are "variable" to "static" and now they appear to be much, much more stable. I had initially been putting my settings as if they it was one 100 MH/s miner but I was giving those settings to many 15 MH/s miners instead.

Hey lozschor,

Do you think it would be helpful for me to identify when there are actually multiple miners using a single connection, even if there are no problems with password arguments?

This might explain why some users are getting poor hashrates, because mining companies are ripping them off.

I can easily identify all the customers who are being exploited in this way, if they are indeed being exploited. Some of them probably have no idea of this problem and are wondering why they have so many issues at every pool.

As a farm owner and a sometimes-rental-provider, keep this in mind. If the advertised hashrate of a rental is > 500MH, it's likely a conglomeration of multiple rigs all pointed to the same stratum on the rental site. The Titan is the top hashrate ASIC available - and a Titan, overclocked, with 6 cubes can theoretically surpass 450MH and approach 500MH. Anything more than that indicates more than one rig.

Virtually all of the rental providers siphon off hashes from rigs while they are in operation (I have suspected both BetaRigs and Mining Rig Rentals of doing this multiple times and have tested and determined that either they are stealing, or that the inefficiencies of their services are to blame). Either way, the only service that seems to have eliminated this is nicehash - the rig owners are only paid on valid hashes accepted by the pool, and the renters only pay for valids also. You can be assured that is you use nicehash for renting, that you will also get multiple rigs that are geographically disparate sending hashes.

The other reason why hashrates are so off, is that the renters (most of the time) don't know how to set DIFF for their mining rentals. If you are renting a big hashrate (like greater than 250MH) -- when you put in your pool info, you must either set them on a statically set stratum address from your chosen pool that is high enough to generate shares and not spam the pools. Many of the rig owners offering rentals state specifically in their descriptions what rig(s) you are renting and suggest DIFFs for your rental to get maximum effect. Renting without checking or asking for this info is bound to be frustrating for both the owner and renter. This reason is why I don't rent out my rigs anymore. The renters don't read nor do they pay attention to the DIFF requirements and complain endlessly about non-optimal hashrates... and the owner of the rig takes it up the butt when the site admins swoop in to offer the renter a refund, despite the fact that they paid no attention to the mining directions.

Steve Sokolowski wrote:Hey lozschor,

Do you think it would be helpful for me to identify when there are actually multiple miners using a single connection, even if there are no problems with password arguments?

This might explain why some users are getting poor hashrates, because mining companies are ripping them off.

I can easily identify all the customers who are being exploited in this way, if they are indeed being exploited. Some of them probably have no idea of this problem and are wondering why they have so many issues at every pool.

I think it would, the more information available the better.

rootdude wrote:As a farm owner and a sometimes-rental-provider, keep this in mind. If the advertised hashrate of a rental is > 500MH, it's likely a conglomeration of multiple rigs all pointed to the same stratum on the rental site. The Titan is the top hashrate ASIC available - and a Titan, overclocked, with 6 cubes can theoretically surpass 450MH and approach 500MH. Anything more than that indicates more than one rig.

Virtually all of the rental providers siphon off hashes from rigs while they are in operation (I have suspected both BetaRigs and Mining Rig Rentals of doing this multiple times and have tested and determined that either they are stealing, or that the inefficiencies of their services are to blame). Either way, the only service that seems to have eliminated this is nicehash - the rig owners are only paid on valid hashes accepted by the pool, and the renters only pay for valids also. You can be assured that is you use nicehash for renting, that you will also get multiple rigs that are geographically disparate sending hashes.

The other reason why hashrates are so off, is that the renters (most of the time) don't know how to set DIFF for their mining rentals. If you are renting a big hashrate (like greater than 250MH) -- when you put in your pool info, you must either set them on a statically set stratum address from your chosen pool that is high enough to generate shares and not spam the pools. Many of the rig owners offering rentals state specifically in their descriptions what rig(s) you are renting and suggest DIFFs for your rental to get maximum effect. Renting without checking or asking for this info is bound to be frustrating for both the owner and renter. This reason is why I don't rent out my rigs anymore. The renters don't read nor do they pay attention to the DIFF requirements and complain endlessly about non-optimal hashrates... and the owner of the rig takes it up the butt when the site admins swoop in to offer the renter a refund, despite the fact that they paid no attention to the mining directions.

I am using Mintsy at the moment, my problem with them is that they refuse to tell me what is being specifically rented and will not give me any way of checking its status. I get no command lines or output or even a hardware outline so I can't even tell what I should input for the best settings. Prohashing is literally the only troubleshooting I have ever received. I am very disappointed with Mintsy's renting policies. I am not even allowed to set a failover pool if you can believe that.