BOUNTY for Ethereum pool operators to add NiceHash compatibility

kenshirothefist

Hello,

If anyone is interested in buying Dagger-Hashimoto hashing power to mine Ethereum even without having physical miners: we added beta support for Ethereum Dagger-Hashimoto algorithm to https://www.nicehash.com. Since original Ethereum specification lacks full stratum support, we made a few minor patches to the Ethereum specification in order to be able to put support for Ethereum on NiceHash. The specifications are published at https://www.nicehash.com/sw/Ethereum_specification_R1.txt

Pools and mining software have to be patched in order to be compatible with the new specification. Currently there are no compatible public pools available, but we made a basic Ethereum pool which follows these specifications and other pools can be prepared according to these specifications. Full source code for the patched Ethereum pool can be found here: https://github.com/nicehash/nhethpool. We also patched Genoils ethminer and full source code as well as beta windows binary can be downloaded here: https://github.com/nicehash/cpp-ethereum/releases/tag/NiceHash-1.0.0.

MINING POOL OPERATORS BOUNTY

Since we would like for pools to put support for NiceHash as soon as possible, we will pay 0.5 BTC to each of the first three Ethereum pools operators that will make their pools compatible with NiceHash rented hashing power. Compatible pools will also be listed on our recommended pools page: https://www.nicehash.com/index.jsp?p=pools.

Thank you for your support!


Best regards,
NiceHash team.

work

Proposed standard doc complains about so many different stratum protocols... then goes ahead and creates yet another... yeesh.

miningpoolhub

So finally you released, nicehash.
I hope your miner implementation to be included in genoil-ethminer release too as it's quite confusing to see several binary.
I will check proposal deeply if pool can support it.

kenshirothefist

work said:

Proposed standard doc complains about so many different stratum protocols... then goes ahead and creates yet another... yeesh.

Yes, because we finally did it properly. In the doc we clearly stated what are the weaknesses of other implementations. It's never too late to improve things, isn't it?

dr_pra

Could you please elaborate on the weaknesses you see in the current stratum implementations? As mentioned already in the previous thread you created the nonce search space is large enough so that if a miner chooses his starting nonce randomly (as every miner implementation currently does) there is no real chance of a "nonce" collision.

Also the bandwidth requirements of the current stratum implementations do not pose any challenge for either pools nor miners.

kenshirothefist

dr_pra said:

Could you please elaborate on the weaknesses you see in the current stratum implementations? As mentioned already in the previous thread you created the nonce search space is large enough so that if a miner chooses his starting nonce randomly (as every miner implementation currently does) there is no real chance of a "nonce" collision.

Also the bandwidth requirements of the current stratum implementations do not pose any challenge for either pools nor miners.

See "I. Introduction" here: https://www.nicehash.com/sw/Ethereum_specification_R1.txt. Anyway, it's not a big deal really ... besides the improvements we simply had to alter the specifications in order to be compatible with our hashing power renting system (and make sure no fakeing with fake miners/bots would be possible).

coinotron

Very nice job Nicehash !!

You did what we were to lazy to do Coinotron's and Genoil's Stratum is almost the same as yours.
Only real difference is lack of support of extranonce. Extranonce is really needed if you want to safely offer variable difficulty shares.

You propose 3 byte long extranonce. Have you consider 2 byte extranonce instead?
Pools will still have available 65536 unique values. It is enough even for biggest pool. But protocol will support 938 GH/s miners, so we won't have to change it when ASIC miners arrive.


We can extend our Stratum pool to meet your specs. I think you should offer special bounty for Genoil's to modify his ethminer. It is critical to have one source of miner and stop forking it.

kenshirothefist

coinotron said:

We can extend our Stratum pool to meet your specs. I think you should offer special bounty for Genoil's to modify his ethminer. It is critical to have one source of miner and stop forking it.

Sure, we're already working with Genoil and he promised to include our patches as soon as possible in his ethminer.

coinotron

What about 2 byte extranonce ?

kenshirothefist

coinotron said:

What about 2 byte extranonce ?

ASICs are really really unlikely on Dagger-Hashimoto ... and even if they happen an 1 TH ASIC miner is even more unlikely on Dagger-Hashimoto ... but we if this actually happens we can change this later ... let's leave it as it is for now.

coinotron

OK.

miningpoolhub

@kenshirothefist

I'm a bit curious that why renting system needs extranonce1?

You need it because westhash and nicehash to work simultaneously without the need of checking nonce value for each server?
I think it must be checked on pool side. Whether the hash comes from westhash or nicehash, pool must be checking nonce value duplication on their own.
I like the idea of setting extranonce1 for each miner and it helps server load lower but not sure that it is *really* needed.

Even for your own mining, you can just set two base address for each wallet on each server so that it will produce totally different headerHash and will not make any problem with fake nonce.

hitchpool

Hi,

we have added support for your protocol on our server and tested it with your fork of genoil's miner.
A new port was opened for this protocol version.

Servers are reachable under:
eu1.hitchpool.org:3334

and
us1.hitchpool.org:3334

We will add this to our webpage too, but will run a test on production with our mining rig before that.

*edit: the nicehash pool validator already confirms our pool as working

work

@miningpoolhub I think they need extranonce because they don't want (or can't reasonably) check every share for uniqueness. If I recall correctly, nicehash will mark some shares as valid even if the pool calls them invalid.

miningpoolhub

work said:

@miningpoolhub I think they need extranonce because they don't want (or can't reasonably) check every share for uniqueness. If I recall correctly, nicehash will mark some shares as valid even if the pool calls them invalid.

@work
Oh.. I thought nicehash was counting only valid shares.

@kenshirothefist
Can you tell us about it?

Off the topic, but... this post is now in Jobs & Skills section.
It was pool discussion category at first.

kenshirothefist

We only count valid shares, of course. The vast majority of the development effort in NiceHash system is spent to make sure our system is 100% fair for sellers & buyers: https://www.nicehash.com/index.jsp?p=faq#faqg3

Extranonce is used for us to be able to assign workers to different orders and forward work to target pool - this is one of the core features of NiceHash.

Regarding moving the topic -> well, it was moved by Forum admins, not much that we can do here ....

kenshirothefist

Slightly updated specs (nothing essential, though): https://github.com/nicehash/nhethpool/blob/master/EthereumStratum_NiceHash_v1.0.0.txt

coinotron

@kenshirothefist

I'm testing my pool using Nicehash's pool validator tool.
I'm receiving this strange error:


Resolving pool host coinotron.com... O
Establishing connection with proxy... OK
Establishing connection with pool 178.217.186.125:44433... OK
Sending mining.subscribe... OK
Sending mining.authorize... OK
Error: Extranonce size is 3 (maximum is 2).

In your specs. you stated that extranonce size is up to 3 bytes, while validator says that it is max 2 bytes

kenshirothefist

Valid range for extranonce is indeed 0-3 bytes, but our service cannot work with extranonce being 3, because we take one byte off nonce for ourselves, thus this would make miners get 4 bytes extranonce and only 4 bytes of nonce, which is not enough. If you wish to keep compatibility with our service, then you should set extranonce size to 2 bytes.

If this is an issue for you, then you could make NH port, where extranonce is 2 and port for other miners where extranonce is 3 bytes.

coinotron

No, It is no problem. We are using 2 bytes extranonce right now.
Our pool is ready , passed your verification test.
We are supporting your miner and protocol on our ETH pool on port 3344.
We will add announcement on our main page as soon as Genoil's miner is ready.

NiceHashTech

There is forked ethminer that supports this new stratum protocol: https://github.com/nicehash/cpp-ethereum

We are working on improvements...

kenshirothefist

hitchpool said:

Hi,
we have added support for your protocol on our server and tested it with your fork of genoil's miner.
A new port was opened for this protocol version.

Servers are reachable under:
eu1.hitchpool.org:3334

and
us1.hitchpool.org:3334

Thanks for this, and congratulations for being the first pool to support NiceHash! Bounty paid:

https://blockchain.info/tx/5e42a1bee994fd818dc7f67b28d11fec4309b915217ced0f28f7331376540929

hitchpool

Can confirm we received the transaction! Thanks!

NiceHashTech

coinotron: it would be great, if you slightly increase difficulty. To at least 1. That way, orders on NiceHash will not be getting dead when reaching higher speeds. We are enforcing min diff of 1 when certain high speed is reached.

coinotron

NiceHashTech said:

coinotron: it would be great, if you slightly increase difficulty. To at least 1. That way, orders on NiceHash will not be getting dead when reaching higher speeds. We are enforcing min diff of 1 when certain high speed is reached.

Done. Difficulty is now exactly 1

miningpoolhub

@kenshirothefist

Hi, MiningPoolHub implemented it.
I think bounty is still available, I'll send you PM about our server host, port, and BTC address.
As long as nicehash confirms, I will apply all changes to all our region servers.

I have some questions and suggestion.

(1) diff level.

NiceHashTech said:

it would be great, if you slightly increase difficulty. To at least 1. That way, orders on NiceHash will not be getting dead when reaching higher speeds. We are enforcing min diff of 1 when certain high speed is reached.

How about the vardiff?
Our pool supports vardiff, and here's initial settings I've set for this new stratum port.

starting diff : 1
minDiff : 0.069848127282057
maxDiff : 11.64135454700958

When connection is made but no submit shares for few minutes, pool decreases difficulty step by step. As this decrease can happen repeatedly, it can reach down to minDiff.
Pool doesn't have problem with massive low difficulty shares, but I wonder whether nicehash would wait the warming up phase or not.

minDiff is actually calculated from previous difficulty level which was 300000000.
It is well suited for old 1 gpu rig. As I want to optimize even low hash miner, I would like to set minDiff as low as possible.


(2) previous stratum

I see that your new miner replaced genoil-ethminer's stratum. "-S" option works differently, and it would make things incompatible. Is this what you intended? Whole stratum protocol replacement. Does pool have to detect miner type automatically and treat them with previous stratum protocol, and new stratum protocol from one port?

How about using other option like "-N" nicehash stratum mode. I don't care what option name you use, but breaking compatibility doesn't look good for miners. Maybe @Genoil would leave his opinion here.

(3) little bug.
When pool sends 0 difficulty, miner crashes. It's not big problem, but it would be better if it's fixed.

NiceHashTech

1. We enforce higher diffs because there may be some buyers with malicious pools with sole purpose to overload our service. NiceHash is treated like a very big miner so there is no reason for it to be on low diffs (especially not when mining high diff coins like Ethereum). If your pool ever sets diff lower than 0.5, our stratum proxy will break connection. We suggest you to offer another alternative port where diff is fixed at high value or does not go below 1 ever or you can detect our miner as "NiceHash/1.0.0" and give some high fixed diff (1 or above). That way you can ensure 100% compatibility with our service.

2. That is up to you how you would handle multiple versions of stratum protocol. The proposed one we are talking about here has name "EthereumStratum/1.0.0". Others don't even have a name, because whoever decided to make them was completely ignorant about anything, even it's name. The forked version of ethminer we did is just a fork and supports only EthereumStratum/1.0.0. If there will ever be EthereumStratum/1.0.0 in original Genoil's miner, then I am sure, Genoil will name it somehow and give miners an option to choose from available stratums.

3. Thank you for the report, we are already onto it to fix it.

kenshirothefist

Coinotron also added support, you can use this as target pool on the order:

Stratum hostname: coinotron.com
Stratum port: 3344
Username: COINOTRON-USERNAME.WORKER-NAME
Password: WORKER-PASSWORD

And here is the bounty reward for Coinotron: https://blockchain.info/tx/ff43e2a28c17d445c27ab62742c9483d66a36ab39dbdd2ea94809d05934ad073

Thanks!

miningpoolhub

NiceHashTech said:

1. We enforce higher diffs because there may be some buyers with malicious pools with sole purpose to overload our service. NiceHash is treated like a very big miner so there is no reason for it to be on low diffs (especially not when mining high diff coins like Ethereum). If your pool ever sets diff lower than 0.5, our stratum proxy will break connection. We suggest you to offer another alternative port where diff is fixed at high value or does not go below 1 ever or you can detect our miner as "NiceHash/1.0.0" and give some high fixed diff (1 or above). That way you can ensure 100% compatibility with our service.

2. That is up to you how you would handle multiple versions of stratum protocol. The proposed one we are talking about here has name "EthereumStratum/1.0.0". Others don't even have a name, because whoever decided to make them was completely ignorant about anything, even it's name. The forked version of ethminer we did is just a fork and supports only EthereumStratum/1.0.0. If there will ever be EthereumStratum/1.0.0 in original Genoil's miner, then I am sure, Genoil will name it somehow and give miners an option to choose from available stratums.

3. Thank you for the report, we are already onto it to fix it.

@NiceHashTech

Thank you for detailed explanation.
I like low diff because pool can measure small miner's hashrate more accurately.
Anyway, I implemented "NiceHash/" string detection and forced difficulty 1 as minimum value.
So it will be compatible with NiceHash.

It passes pool validator successfully.
I hope you test our pool again. I sent test server info and bitcoin address PM to @kenshirothefist already.

Thanks.

coinotron

kenshirothefist said:

Coinotron also added support, you can use this as target pool on the order:

Stratum hostname: coinotron.com
Stratum port: 3344
Username: COINOTRON-USERNAME.WORKER-NAME
Password: WORKER-PASSWORD

And here is the bounty reward for Coinotron: https://blockchain.info/tx/ff43e2a28c17d445c27ab62742c9483d66a36ab39dbdd2ea94809d05934ad073

Thanks!

Thanks

kenshirothefist

MiningPoolHub also added support, you can use this as target pool on the order:

Stratum hostname: hub.miningpoolhub.com
Stratum port: 20534
Username: MININGPOOLHUB-USERNAME.WORKER-NAME
Password: WORKER-PASSWORD

And here is the bounty reward for MiningPoolHub: https://blockchain.info/tx/474a3f659cd3cb788e8bdd8558319058dd91f5ee5170a296cb65cc763c2d7e9e

Thanks!

This now concludes our "first three Ethereum pools bounty", however all other pools are of course very much welcome to add support for NiceHash,