Stratum mining protocol for Ethereum

NiceHashTech

Hello!

At NiceHash, we have decided to lay down specifications for Ethereum stratum protocol.

Draft is here.

You may ask, why again another stratum. Reasons are explained in the paper. All current implementations are just a "getwork over stratum" and the only thing they solve are so that miners do not query getwork anymore.

Why should miners and pools update to this new stratum?

First of all, I suggest you to get familiar with standard stratum used in Bitcoin (https://slushpool.com/help/#!/manual/stratum-protocol).

If you use "getwork over stratum", then you still need to poll getwork many times on server side, because you should give each miner unique work; so for every miner, you are still doing polling and that is very resource hoggy, not to mention having few thousands ethereum addresses in wallet - for each miner one. But if you share several miners on same wallet, then they may be doing duplicate work; if you accept this duplicate work, then your pool is at lost (your pool may have higher hashing speed if you gave each miner unique work); if you reject this work, then miner's are at lost, since they will be getting unjustified duplicate shares.

The proposed implementation is a bit more "complicated" than the known "getwork over stratum", because it handles extranonce. But extranonce is needed to accomplish what we want... If having 2 bytes of nonce reserved for extranonce set by pool, then your pool needs to poll only 1 ethereum address for 64k miners. And each miner can still reach speeds of up to 938 GH/s before exhausting nonce range and having nothing to work on.

We are open to suggestions about further improvements of the specifications. Let us know, if you have any...

Etherite

I briefly read through your draft and things look good, the main thing is getting pool adoption as I wouldnt want to change our pool if the miners didnt follow.

I dont see any reason why they wouldnt as anything making mining more effecient everyone should jump at.

Ill have a more detailed look when I get home, is there any better way to contact you and discuss?

NiceHashTech

You can contact us at [email protected]

We are already in discussion with Genoil to adopt new stratum in his ethminer; client mining software will not be an issue.

We also have few guys eager to make a pool, but the more we have the better. Eventually, all pools should adopt it.

I have noticed a lot of requests for vardiff. With this stratum implementation, vardiff is as easy as any other stratum. Pool just needs to send set_difficulty.

Etherite

NiceHashTech said:

You can contact us at [email protected]

We are already in discussion with Genoil to adopt new stratum in his ethminer; client mining software will not be an issue.

We also have few guys eager to make a pool, but the more we have the better. Eventually, all pools should adopt it.

I have noticed a lot of requests for vardiff. With this stratum implementation, vardiff is as easy as any other stratum. Pool just needs to send set_difficulty.

Awesome sounds good, will flick through an email and start having a look at things.

Genoil

@bitcanuck as far as I have understood the reasoning behind extranonce is to lock down each pool worker in his own sandbox of nonces, in order to prevent cheating. I could now submit a solution twice, once for the worker that actually found it and the other I could pass through a backdoor to another worker (on a different account) that would also submit it as a solution.

I think the odds of two actually unrelated workers submitting the same nonce for a piece of work is that low, that the pool could also get away with simply rewarding the first worker that submitted the nonce and rejecting the other.

I don't know, I just built the client and will make a compatible client for nicehash if they donate to the project just like they did for earlier feature requests.

I'm not a pool op. Perhaps @dr_pra @miningpoolhub can add to the conversation?

work

@genoil pools prevent that by comparing submitted shares to other submitted shares in the same period and ensuring the nonce hasn't been claimed yet. Verifying a solution is unique is a basic and neccesary protection.

@NiceHashTech there are already 3 seperate "stratum" implementations for ethereum mining that pools need to handle. This would be been a great idea several months ago, but I think you're a bit late to the game proposing yet another method set standard.

NiceHashTech

bitcanuck said:

I stopped at the first paragraph because it is clear you either don't know what you are talking about, or are prone to engaging in emotional reasoning:
"Miners may be doing duplicate work (if they choose same nonces).

Since you are advancing the argument, the onus is on you to prove it. Since the nonce is 64-bits, there are 18,446,744,073,709,551,616 (almost 20 quintillion) different possible nonces, and out of those, there will be billions of valid solutions of sufficient difficulty for the current work. Do the math and you'll see you are wrong.

Hopefully @Genoil recognizes the weakness in your argument so he doesn't waste his time.

I agree, that chances are small if miners select their nonces randomly. But this is not the point; as Genoil mentioned, the current stratum solutions are prone to exploits; same nonce could get submitted twice and the question is, how many pools out there are exploitable that way.

Another good reason to switch to new stratum is to massively reduce resources needed on your pool.

NiceHashTech

work said:

@NiceHashTech there are already 3 seperate "stratum" implementations for ethereum mining that pools need to handle. This would be been a great idea several months ago, but I think you're a bit late to the game proposing yet another method set standard.

We will support this, financially if needed. It is the only way we can offer Ethereum hashing power to be purchased/sold over our system. We cannot do that with any of current stratum implementations. So there is not a question whether this is a good idea, but rather if you think we are missing something important inside proposed stratum protocol.

work

@niceHashTech pools detect and reject duplicate nonces already. I know MPH has explained that over there, each regional server uses a different wallet (to prevent submitting same solution to multiple regions), and each region validates each solution for uniqueness. Every pool for every coin I've ever seen does this (some validate share uniqueness across regional severs too, instead of splitting them).

@genoil I definitely wouldn't waste your time with YET ANOTHER stratum implementation. I can't see something proposed SO DAMN LATE ever picking up much usage.

dr_pra

ethpool.org as well as ethermine.org validate the uniqueness of each share since day one. I don't see the need of an extranonce solution as the search space is large enough and miners are generating their initial nonce randomly.

miningpoolhub

@Genoil
You're right about extranonce1 and pools.
Extranonce1 works well with bitcoins, and I wanted some variables like that at earlier days.
As a workaround, miningpoolhub rejects second arriving duplicate nonce values to prevent fake share insertion.

@NiceHashTech
There could be some normal miner's duplicate work, but it is really small portion of it.
Regarding the ethereum's 14s block time thing, this probability gets much much lower in reality.

Seems like this proposal is good, deeply considered, but quite late. Miningpoolhub would support this new protocol when ethminer is out. But I prefer just stick to current stratum. Not only pool operators, pool miners are already confused about several miners.