I think previous ethminer's random approach is better. There could be some probability of extranonce duplication in a pool since it is only limited to 2 bytes, 65536. 65536 is not that big, in reality. This number will overflow and reset from 0 frequently than expected because there's infinite connection retry miners.
So there's some probability of setting same extranonce to few miners. And there's more probability of duplicated work from miners than before because they will start calculation from 0. The worse thing is that miners set with same extranonce will calculate same range at the same time. What a waste of resource, isn't it?
I think you used some workaround trick to limit the nonce overflow in GPU calculation to not modify OpenCl, CUDA codes. (Not sure, just guessing. Am I right?) Setting extranonce value fixed at OpenCL, CUDA codes and nonce increasing must be implemented correctly to avoid this issue.
Your new stratum spec states about duplication work between miners, but your miner implementation makes duplication more than before. I think you should take this issue seriously.
Original Stratum works this way. Pool gives each miner range in which it should be looking for valid nonces. This gives pool software easy way to discard all malicious miners sending "fake" shares.
I don't know why NiceHashes pool verificator accepts only 2 byte extranonces while their specification and miner as well allows for up to 3 bytes extranonces.
I don't know why NiceHashes pool verificator accepts only 2 byte extranonces while their specification and miner as well allows for up to 3 bytes extranonces.
I already replied to this question before but let me reply again; We take one byte off minernonce and plug it into extranonce. If extranonce was already 3, then we would make it being 4 and that would leave miners with only 4 bytes to use as a nonce and max speed of 14mhs @ 5min block (very bad unlike scenario but can happen anyway) - this would mean that miners would start doing duplicate work due to nonce range exhaustion. We solve this by limiting max extranonce to 2.
On miner side, nonce exhaustion would be possible, if miner was hashing with somewhere like 1ghs (each card) and there was no block (no new work) for more than 5 minutes. The miner implementation is not perfect, it does not consider this scenario, because we consider it impossible to happen with current hardware and that said, it is being enough for our miners until professional miner coders decide to improve it.
If there is a duplication of work anywhere, then it is there due to a mistake or a bug in code we didn't forsee and we will fix it.
And about specifications; regarding this part are flawless; original stratum protocol is working that way for about 4 years now and there were no found flaws in it regarding duplicate work.
Original Stratum works this way. Pool gives each miner range in which it should be looking for valid nonces. This gives pool software easy way to discard all malicious miners sending "fake" shares.
@coinotron I also know stratum protocol and why extranonce is intended. I recall that they use 4 bytes for extranonce1 at bitcoin & altcoins. Much much bigger space than ethereum new stratum. The main problem is that extranonce has very little space at ethereum stratum. Only 2 bytes and It makes problem because several miners would get same extranonce value. Or it would need to overcome some limitation.
@NiceHashTech So you mean that pool need to guarantee extranonce uniqueness for each miner by using some queue? I understand your point. I just wanted some randomly initialized counter instead.
And about specifications; regarding this part are flawless; original stratum protocol is working that way for about 4 years now and there were no found flaws in it regarding duplicate work.
Well, one limitation is added by this stratum implementaiton then. 65536, the 2 bytes limitation.
(1) What if more than 65536 miners connect to one pool? They will need to get unique extranonce value but will be failed. I personally don't think ethereum mining to be end soon. 65536 is not that big number regarding the bitcoin rigs out there. (2) It can also be used by abusing miners. Some miners can consume 65536 connections if they intend to. So no more miners can connect.
Maybe you would suggest to extend the extranonce value 3 bytes. Or just split the pool server and set unique wallet address for each of them to overcome 65536 limitation.
It also introduces one more limitation regarding the nicehash's 1 byte off, and gpu index. Nonce range will be smaller than previous implementation.
OK. Mainly, without the 65536, your spec seems flawless. But, don't you think these all implementations make things more and more complex which were not even an issue with previous ethminer? I recall KISS principle now. It doesn't need to be like this complexity.
I understand that nicehash needs one byte of extranonce to manage internally. So this was the main purpose of your implementation. How about just allowing normal pool mining with 0 length of extranonce, and only your renting system to use some length of extranonce like 1 byte. And nonce count starts from random number.
It will solve 65536 limitation issue, block abusing miners who consumes extranonces, and compatible with Nicehash.
All of the limitations here are mainly due to limitation of Ethereum not having anything else but getwork. It has no getblocktemplate like Bitcoin, which enables more nonce space. So we have to work with what we have.. and we have 8 byte nonce, we need to split it somehow and this is the only way... if you know better one, let me know.
Now regarding the issues you pointed out.
Yes, your pool should take care of not giving same extranonce to miners.
2 bytes gives you 64k yes. If you need more, just use more wallets. But each wallet can support 64k. With previous stratums, each wallet was able to support only 1 miner. So, isn't 64k better than 1? nhethpool has the ability to link multiple wallets, each one supporting up to 32k miners when using extranonce2. If your pool grows very large, just use several wallets and you are good to go It will still consume much less resources than having any other stratum where you can do 1 miner per wallet.
Your pool may set extranonce "". This means that miner can use 8 bytes for nonce. There is nothing wrong with it and it is allowed to do. In fact, that way, you can probably make easy proxy for other stratums <-> EthereumStratum/1.0.0. But you still need to have some sort of share checker, because other stratums require mixhash to be sent too, which you need to calculate on your own in proxy.
And current implementations do work as you can see, we have 12 GHs rented and more is coming, but now it is more profitable to mine Lyra2REv2 on NiceHash if you have NVIDIA GPU.
All of the limitations here are mainly due to limitation of Ethereum not having anything else but getwork. It has no getblocktemplate like Bitcoin, which enables more nonce space. So we have to work with what we have.. and we have 8 byte nonce, we need to split it somehow and this is the only way... if you know better one, let me know.
Yeah, I know this problem too. Seems like nonce should be longer but it's length is fixed already. AFAIK There's no other way.
2 bytes gives you 64k yes. If you need more, just use more wallets. But each wallet can support 64k. With previous stratums, each wallet was able to support only 1 miner. So, isn't 64k better than 1? nhethpool has the ability to link multiple wallets, each one supporting up to 32k miners when using extranonce2. If your pool grows very large, just use several wallets and you are good to go It will still consume much less resources than having any other stratum where you can do 1 miner per wallet.
Surprised that your pool source code supports many functions. I thought it was only for stratum demonstration. Maybe your nicehash internal code?
64k vs 1 miner seems quite not true. There's no pool running 1 miner per wallet. I understand what you are talking about but we already achieved pool mining with previous implementation, nearly infinite miners can mine together by random nonce approach.
Random approach is expected to distribute miner works uniformly and it works as intended. Your approach slices job explicitly for miners and it works too. Same purpose, different method/approach used.
Our pool just checks all nonce globally. Duplication happens very very rarely but happens. Seems like miner program bug sending duplicate work or some attempts of abusing user I think. But I can tell that duplication work is really really rare. Seems like there's no duplication share even for a month lately.
Your pool may set extranonce "". This means that miner can use 8 bytes for nonce. There is nothing wrong with it and it is allowed to do. In fact, that way, you can probably make easy proxy for other stratums <-> EthereumStratum/1.0.0. But you still need to have some sort of share checker, because other stratums require mixhash to be sent too, which you need to calculate on your own in proxy.
I plan to use zero length extranonce for normal miners in our pool. Renting users will have 1 byte of extranonce from nicehash proxy, and it will be fine too.
Can you modify the source code by starting nonce as random when nonce length is zero? So your official miner works as previous ethminer. (If extranonce length is 0 and nonce starts from 0, then all miners will calculate same thing across that pool) This will not break anything, just increases compatibility.
I just want things simple. I don't like to deal with extranonce1 uniqueness, split wallet per 65536 miners if there's already much simpler way. I just want to make pool compatible with NiceHash, and I'm satisfied with it. Will you modify the official miner code a little bit?
We only modified Genoil's ethminer to be compatible with NiceHash. This is not our project and our intentions are only to modify it in a way to suit us and to fulfill our needs. If you wish certain feature added, you better talk to Genoil.
And as it goes to be compatible with NiceHash as a pool - if you do not set extranonce (if you set it to ""), then we cannot guarantee any kind of uniqueness of nonces. Our system will most likely establish several connections and then further delegate same work to miners. As a result, we will pay miners for their work but buyers buying on our service and pointing towards you will probably get rejects due to duplicate work.
I don't know what kind of programming language you use for your pool, but any kind of language (except C) offers you some in-built datastructure you can use for queue of extranonces, so adding this is not really a hard thing. When pool starts, just queue all possible extranonces. When miner comes, take last extranonce from the queue. Put it's extranonce back to the queue when miner is gone.
Is it already merged to genoil build? I can't find them. Can you point that commit?
I thought that you already released your miner program to miners on your own. So I thought you are the main contributor for your miner program, and asked to modify your source code. Already 14GH is on your site. Where did all the daggerhashimoto rental miners get that binary from?
You don't need to worry about nonce duplication on our pool. We already implemented checking every nonce each other globally. We will reject second arriving duplicate works.
Actually, the problem is not fake shares, but "same nonce counting range" between miners.
I don't know the inner logic of your rental system. Seems like you want to merge maximum 256 miners to one connection to pool. And your unique 1 byte extranonce will be set for each miners, right?
I would prefer that your implementation start from random number when extranonce length is 0 or 1, then. 6 bytes of random space is huge, so there should be no collision normally. This will not make overflow issue too regarding the gpu index() boundary. So it should be no problem then.
(1) I think nonce starting from random number will work flawlessly when extranonce length is short like 0 or 1. (Nonce starting from 0 would be needed when extranonce is longer due to overflow issue) - No problem. No compatibility issue. - Very easy implementation from current source code. Only 2~3 lines of code will work.
(2) Or I have to implement unique extranonce thing, and have to overcome 65536 limitation per wallet. - Quite many lines of code, need testing. - Lower server performance by running several wallet daemon. geth is not light you know. - And it's vulnerable regarding the massive TCP connection attack. Abusing user can make 65536 connections easily to block new connection for that pool.
Maybe you would think 65536 miners will not come to reality in near future. Maybe, and maybe not. But I would like to make things that can scale more than 10 years. If ethereum grow up like bitcoin, then 65536 miner would be not a big number then.
Please compare above two ideas. I definitely prefer first one.
One more note. I use nodejs (NOMP) and it is quite messy to guarantee extranonce uniqueness because of multi thread. yes, It's not impossible but I prefer simple, light weight thing. Not want to deal with process message things. Simple is more stable and robust, I think. And easy to scale.
There is already ethminer implementation following specifications and it starts nonce range from 0. I will tell you why. If your range is limited, eg. you are allowed to iterate only last X bits of nonce, and you start at random location, then you effectively "shorten" your range, because you end up at the end faster. Except if bitmasking every nonce prior hashing. That is something we didn't do in first forked ethminer we released. Now there are thousands builds already in use - and as always, you cannot expect them all to update.
Besides, miners on NiceHash will still get paid for every share that gets potentionally rejected @ your pool due to being duplicate (as long as it is not duplicate by the specs). With your implementation of same extranonces, you are not hurting miners of NiceHash, but rather buyers of NiceHash, as they get % of shares being rejected as duplicates; you can see that on this picture - it is order of a customer. A proper implementation yields 0% duplicates.
As far as it goes about 64k attacks. If someone attacks your pool with 64k connections, it will not matter what kind of software you run behind. That is DDOS and will knock your pool down any way. We had similar issues in the past and what you need to have in place are good filters - detect malicious behavior of miners and block them. And if you do reach 64k true miners, one being approximately 40 mhs (that is an average), then your pool would have 2621 GH/s of hashing speed and I am sure you would be able to get enough out of fees to setup another wallet
1. I suggested random nonce only when extranonce length is 0 or 1. extranonce 0 length works like previous ethminer and it doesn't make any problem as you know. extranonce 1 length would be used from nicehash like renting service and it will work well too because gpu index bit is also set. So there shouldn't be some random number that will overflow immediately. No need to worry about bitmask too. (gpu index will limit the maximum nonce number at start)
Even wider range than starting from 0 because nonce bytes can be 7~8 bytes. Your spec says 5~6 bytes. It's totally better.
2. I believe there's no duplicate share normally. That graph seems a bug came out from ethminer I think. There's some bug that submits same share several times at certain condition and I opened an issue about it at genoil repository.
And that seems not from our pool. I closed nicehash stratum testing port after your confirmation. I will open port again after merging two stratum type into one. I thought it would be better to not open 2 stratum ports because users will get confused with it.
And also I want to tell that our pool distributed extranonce randomly. It doesn't guarantee uniqueness perfectly but it was almost unique. That kind of duplication share graph cannot be happen too, going down and going up in the middle of graph.
If you say that there can be massive duplicate share, then current ethereum pool mining couldn't be ran. This is so so so so so low probability.
3. 65536 connection limitation is the most thing I don't like. Connection don't need to insert share for a while. Pool can't distinguish normal miner and abusing connection that fast. If abusing user just open that many TCP connections, then pool is totally vulnerable to it. Even I make 10 wallet, abusing user can easily lock down whole pool. If current new ethminer spreads, there's no chance to fix this vulnerability later. Please don't take it easy. DDoS is the most effective attack these days and this is more easier than DDoS. Massive connection and wait a while will accomplish it easily.
4. I'm not asking you to change the spec. I just want the miner to count from random number only when extranonce length is 0 or 1. It will not harm rental buyer, seller, other pools.
5. So, is it okay for me to distribute your implementation after I fix those nonce lines. You told me that you are not the official distributor, then I may be one of ethminer dev then. I would help implementation merged to genoil.
6. What I want from you is just don't block short extranonce length rental miners later. It will be fine, compatible with all pools.
Like I said already, forked ethminer is already used by thousands of miners. We cannot force them to update. Some miners will always start mining from minernonce 0 and those miners would then constantly create duplicates for you. There is no effective way to force them to update.
Also, a modification you need to do on your side requires 10 minute of work if using proposed queue method for assigning extranonces.
Regarding miners; you assign extranonce when miner subscribes - do not assign on pure TCP connect establishment. Resource exhaustion of TCP/IP stack of your server is your bigger worry if someone decides to DDOS you with 64k fake rigs. And like I said, these types attacks are easy to filter out. It is much harder to filter bandwidth attacks.
I can tell you how someone can create CPU exhaustion having wildly accepted ethereum stratum implementation relying on randomness - but you still gladly use it. Having just 1000 miners (64 times less than your worry), each sending duplicate shares. This would create a lot of CPU utilization for checking all shares, because you check each share against globally received shares from all customers. I believe that is why pools use rather high difficulty, where miners usually find 1 share per 5 minutes of mining, so that checking shares for duplicates is not so intensive process.
Therefore another great thing of EthereumStratum/1.0.0 are low diff shares for miners - so that every second of mining can be rewarded, payouts are more predictable and consistent and that is all what miners like.
Like I said already, forked ethminer is already used by thousands of miners. We cannot force them to update. Some miners will always start mining from minernonce 0 and those miners would then constantly create duplicates for you. There is no effective way to force them to update.
Also, a modification you need to do on your side requires 10 minute of work if using proposed queue method for assigning extranonces.
Regarding miners; you assign extranonce when miner subscribes - do not assign on pure TCP connect establishment. Resource exhaustion of TCP/IP stack of your server is your bigger worry if someone decides to DDOS you with 64k fake rigs. And like I said, these types attacks are easy to filter out. It is much harder to filter bandwidth attacks.
I can tell you how someone can create CPU exhaustion having wildly accepted ethereum stratum implementation relying on randomness - but you still gladly use it. Having just 1000 miners (64 times less than your worry), each sending duplicate shares. This would create a lot of CPU utilization for checking all shares, because you check each share against globally received shares from all customers. I believe that is why pools use rather high difficulty, where miners usually find 1 share per 5 minutes of mining, so that checking shares for duplicates is not so intensive process.
Therefore another great thing of EthereumStratum/1.0.0 are low diff shares for miners - so that every second of mining can be rewarded, payouts are more predictable and consistent and that is all what miners like.
Okay. I will just follow your suggestions since I can't force update already miners using it. When I first suggested new idea, hash was not that big but it's already 21GH/s on your site. WOW. I'm quite curious that where did users get that miner binary? Can you point one of repository or download link?
Two ideas both have pros and cons. I agree that your original spec is quite good. I was just suggesting because I want it to be the final, ultimate, ideal implementation. There's so massive protocol, spec on ethereum pool mining out there. I don't want more implementation after this.
I will make extranonce thing perfect unique soon, and make it compatible with previous stratum port. Making extranone unique is not that big problem, I know how can deal it.
I feel like maybe I was too anxious about 64k attack.
Also, 1000shares/s can be easily calculated from our pool. Pool is extremely optimized. Our pool's share target time is about 20 seconds. We don't use high difficulty actually. There's not much pools support vardiff, so they had to stick to high diff.
Anyway, great work you guys. I will make new stratum port compatible with current one and open it soon.
Great news. I think I have completed making two stratum compatible in one port, and almost ready to announce. I'm testing real rental hash from nicehash and have some questions.
1. What is the maximum speed (or difficulty) for your one connection to pool? Is it limited? 2. How does Delta calculated from your service? Pool didn't reject share, but your delta thing goes up and down like rollercoaster. Is this normal?
3. Seems like miner program submits share twice by bug sometimes. (It's already reported bug from genoil-ethminer and nicehashminer would have this bug too) Is nicehash checking nonce duplication before sending to pool? Or just sending it to pool without any check.
2. How does Delta calculated from your service? Pool didn't reject share, but your delta thing goes up and down like rollercoaster. Is this normal?
This depends on the way your pool serves, accepts & rejects shares and also depends on how good you are doing mining jobs (see point C. here: https://www.nicehash.com/index.jsp?p=faq#faqg3). A bit of up&down is normal, it evens out during a lifetime of an order.
3. Seems like miner program submits share twice by bug sometimes. (It's already reported bug from genoil-ethminer and nicehashminer would have this bug too) Is nicehash checking nonce duplication before sending to pool? Or just sending it to pool without any check.
Hmm, this shouldn't be an issue. @coinotron had a similar issue and solved it, maybe you should contact him for som hint.
Mining Pool Hub's ethereum 20535 port supports both stratum protocol now. Also Ethash auto profit switching port 17020, Ethash multi-algo endpoint 12020 are also compatible.
Small issue popped up today. I'm have been mining using NiceHash rented hashrate for the past few days and it was working perfect on Mining Pool Hub until today. All of a sudden the same connection strings are not working anymore. The error message is related to difficulty setting on the pool.
Another issue i'm having is not being able to connect to Coinotron at all. Here are my configs and error messages, any help would be appreciated.
Update to the above post, I managed to connect again without any issues to Mining Pool Hub using this setting. europe1.ethereum.miningpoolhub.com:20535. The hub.miningpoolhub.com string still does not work.
Coinotron is still having connection issues: What is the correct connection string for Coinotron that currently works? Using the above connection details could you provide a successful setting,
Comments
As looking at the source code, NiceHash miner nonce hashes from 0, not from random number as previous ethminer.
https://github.com/nicehash/cpp-ethereum/blob/f9e9ce62d59d33140fa305baafb04b74dc0720fa/libethcore/EthashGPUMiner.cpp#L173
I think previous ethminer's random approach is better. There could be some probability of extranonce duplication in a pool since it is only limited to 2 bytes, 65536.
65536 is not that big, in reality. This number will overflow and reset from 0 frequently than expected because there's infinite connection retry miners.
So there's some probability of setting same extranonce to few miners. And there's more probability of duplicated work from miners than before because they will start calculation from 0. The worse thing is that miners set with same extranonce will calculate same range at the same time. What a waste of resource, isn't it?
I think you used some workaround trick to limit the nonce overflow in GPU calculation to not modify OpenCl, CUDA codes. (Not sure, just guessing. Am I right?)
Setting extranonce value fixed at OpenCL, CUDA codes and nonce increasing must be implemented correctly to avoid this issue.
Your new stratum spec states about duplication work between miners, but your miner implementation makes duplication more than before. I think you should take this issue seriously.
I don't know why NiceHashes pool verificator accepts only 2 byte extranonces while their specification and miner as well allows for up to 3 bytes extranonces.
miningpoolhub: You can check our nhethpool source and you will see that there is a queue datastructure for assigning extranonces to miners. No two miners ever have same extranonce at the same time, thus two miners never do the same work: https://github.com/nicehash/nhethpool/blob/master/nhethpool/EthereumInstance.cs#L451
On miner side, two video cards never get to hash the same nonce range:
https://github.com/nicehash/cpp-ethereum/blob/master/libethcore/EthashCUDAMiner.cpp#L184
On miner side, nonce exhaustion would be possible, if miner was hashing with somewhere like 1ghs (each card) and there was no block (no new work) for more than 5 minutes. The miner implementation is not perfect, it does not consider this scenario, because we consider it impossible to happen with current hardware and that said, it is being enough for our miners until professional miner coders decide to improve it.
If there is a duplication of work anywhere, then it is there due to a mistake or a bug in code we didn't forsee and we will fix it.
And about specifications; regarding this part are flawless; original stratum protocol is working that way for about 4 years now and there were no found flaws in it regarding duplicate work.
I also know stratum protocol and why extranonce is intended. I recall that they use 4 bytes for extranonce1 at bitcoin & altcoins. Much much bigger space than ethereum new stratum.
The main problem is that extranonce has very little space at ethereum stratum. Only 2 bytes and It makes problem because several miners would get same extranonce value. Or it would need to overcome some limitation. @NiceHashTech
So you mean that pool need to guarantee extranonce uniqueness for each miner by using some queue?
I understand your point.
I just wanted some randomly initialized counter instead. Well, one limitation is added by this stratum implementaiton then.
65536, the 2 bytes limitation.
(1) What if more than 65536 miners connect to one pool? They will need to get unique extranonce value but will be failed. I personally don't think ethereum mining to be end soon. 65536 is not that big number regarding the bitcoin rigs out there.
(2) It can also be used by abusing miners. Some miners can consume 65536 connections if they intend to. So no more miners can connect.
Maybe you would suggest to extend the extranonce value 3 bytes. Or just split the pool server and set unique wallet address for each of them to overcome 65536 limitation.
It also introduces one more limitation regarding the nicehash's 1 byte off, and gpu index.
Nonce range will be smaller than previous implementation.
OK. Mainly, without the 65536, your spec seems flawless.
But, don't you think these all implementations make things more and more complex which were not even an issue with previous ethminer?
I recall KISS principle now. It doesn't need to be like this complexity.
I understand that nicehash needs one byte of extranonce to manage internally. So this was the main purpose of your implementation. How about just allowing normal pool mining with 0 length of extranonce, and only your renting system to use some length of extranonce like 1 byte.
And nonce count starts from random number.
It will solve 65536 limitation issue, block abusing miners who consumes extranonces, and compatible with Nicehash.
Now regarding the issues you pointed out.
Yes, your pool should take care of not giving same extranonce to miners.
2 bytes gives you 64k yes. If you need more, just use more wallets. But each wallet can support 64k. With previous stratums, each wallet was able to support only 1 miner. So, isn't 64k better than 1? nhethpool has the ability to link multiple wallets, each one supporting up to 32k miners when using extranonce2. If your pool grows very large, just use several wallets and you are good to go
Your pool may set extranonce "". This means that miner can use 8 bytes for nonce. There is nothing wrong with it and it is allowed to do. In fact, that way, you can probably make easy proxy for other stratums <-> EthereumStratum/1.0.0. But you still need to have some sort of share checker, because other stratums require mixhash to be sent too, which you need to calculate on your own in proxy.
And current implementations do work as you can see, we have 12 GHs rented and more is coming, but now it is more profitable to mine Lyra2REv2 on NiceHash if you have NVIDIA GPU.
AFAIK There's no other way.
Surprised that your pool source code supports many functions. I thought it was only for stratum demonstration. Maybe your nicehash internal code?
64k vs 1 miner seems quite not true. There's no pool running 1 miner per wallet.
I understand what you are talking about but we already achieved pool mining with previous implementation, nearly infinite miners can mine together by random nonce approach.
Random approach is expected to distribute miner works uniformly and it works as intended.
Your approach slices job explicitly for miners and it works too. Same purpose, different method/approach used.
Our pool just checks all nonce globally. Duplication happens very very rarely but happens. Seems like miner program bug sending duplicate work or some attempts of abusing user I think.
But I can tell that duplication work is really really rare. Seems like there's no duplication share even for a month lately.
I plan to use zero length extranonce for normal miners in our pool. Renting users will have 1 byte of extranonce from nicehash proxy, and it will be fine too.
Can you modify the source code by starting nonce as random when nonce length is zero?
So your official miner works as previous ethminer. (If extranonce length is 0 and nonce starts from 0, then all miners will calculate same thing across that pool)
This will not break anything, just increases compatibility.
I just want things simple. I don't like to deal with extranonce1 uniqueness, split wallet per 65536 miners if there's already much simpler way. I just want to make pool compatible with NiceHash, and I'm satisfied with it. Will you modify the official miner code a little bit?
Thanks.
And as it goes to be compatible with NiceHash as a pool - if you do not set extranonce (if you set it to ""), then we cannot guarantee any kind of uniqueness of nonces. Our system will most likely establish several connections and then further delegate same work to miners. As a result, we will pay miners for their work but buyers buying on our service and pointing towards you will probably get rejects due to duplicate work.
I don't know what kind of programming language you use for your pool, but any kind of language (except C) offers you some in-built datastructure you can use for queue of extranonces, so adding this is not really a hard thing. When pool starts, just queue all possible extranonces. When miner comes, take last extranonce from the queue. Put it's extranonce back to the queue when miner is gone.
Is it already merged to genoil build? I can't find them. Can you point that commit?
I thought that you already released your miner program to miners on your own. So I thought you are the main contributor for your miner program, and asked to modify your source code.
Already 14GH is on your site. Where did all the daggerhashimoto rental miners get that binary from?
You don't need to worry about nonce duplication on our pool. We already implemented checking every nonce each other globally. We will reject second arriving duplicate works.
Actually, the problem is not fake shares, but "same nonce counting range" between miners.
I don't know the inner logic of your rental system.
Seems like you want to merge maximum 256 miners to one connection to pool. And your unique 1 byte extranonce will be set for each miners, right?
I would prefer that your implementation start from random number when extranonce length is 0 or 1, then.
6 bytes of random space is huge, so there should be no collision normally. This will not make overflow issue too regarding the gpu index() boundary. So it should be no problem then.
(1) I think nonce starting from random number will work flawlessly when extranonce length is short like 0 or 1. (Nonce starting from 0 would be needed when extranonce is longer due to overflow issue)
- No problem. No compatibility issue.
- Very easy implementation from current source code. Only 2~3 lines of code will work.
(2) Or I have to implement unique extranonce thing, and have to overcome 65536 limitation per wallet.
- Quite many lines of code, need testing.
- Lower server performance by running several wallet daemon. geth is not light you know.
- And it's vulnerable regarding the massive TCP connection attack. Abusing user can make 65536 connections easily to block new connection for that pool.
Maybe you would think 65536 miners will not come to reality in near future. Maybe, and maybe not. But I would like to make things that can scale more than 10 years. If ethereum grow up like bitcoin, then 65536 miner would be not a big number then.
Please compare above two ideas.
I definitely prefer first one.
One more note.
I use nodejs (NOMP) and it is quite messy to guarantee extranonce uniqueness because of multi thread. yes, It's not impossible but I prefer simple, light weight thing. Not want to deal with process message things.
Simple is more stable and robust, I think. And easy to scale.
Besides, miners on NiceHash will still get paid for every share that gets potentionally rejected @ your pool due to being duplicate (as long as it is not duplicate by the specs). With your implementation of same extranonces, you are not hurting miners of NiceHash, but rather buyers of NiceHash, as they get % of shares being rejected as duplicates; you can see that on this picture - it is order of a customer. A proper implementation yields 0% duplicates.
As far as it goes about 64k attacks. If someone attacks your pool with 64k connections, it will not matter what kind of software you run behind. That is DDOS and will knock your pool down any way. We had similar issues in the past and what you need to have in place are good filters - detect malicious behavior of miners and block them. And if you do reach 64k true miners, one being approximately 40 mhs (that is an average), then your pool would have 2621 GH/s of hashing speed and I am sure you would be able to get enough out of fees to setup another wallet
extranonce 0 length works like previous ethminer and it doesn't make any problem as you know.
extranonce 1 length would be used from nicehash like renting service and it will work well too because gpu index bit is also set. So there shouldn't be some random number that will overflow immediately. No need to worry about bitmask too. (gpu index will limit the maximum nonce number at start)
Even wider range than starting from 0 because nonce bytes can be 7~8 bytes. Your spec says 5~6 bytes.
It's totally better.
2. I believe there's no duplicate share normally. That graph seems a bug came out from ethminer I think. There's some bug that submits same share several times at certain condition and I opened an issue about it at genoil repository.
And that seems not from our pool. I closed nicehash stratum testing port after your confirmation. I will open port again after merging two stratum type into one. I thought it would be better to not open 2 stratum ports because users will get confused with it.
And also I want to tell that our pool distributed extranonce randomly. It doesn't guarantee uniqueness perfectly but it was almost unique. That kind of duplication share graph cannot be happen too, going down and going up in the middle of graph.
If you say that there can be massive duplicate share, then current ethereum pool mining couldn't be ran. This is so so so so so low probability.
3. 65536 connection limitation is the most thing I don't like.
Connection don't need to insert share for a while. Pool can't distinguish normal miner and abusing connection that fast. If abusing user just open that many TCP connections, then pool is totally vulnerable to it.
Even I make 10 wallet, abusing user can easily lock down whole pool.
If current new ethminer spreads, there's no chance to fix this vulnerability later. Please don't take it easy. DDoS is the most effective attack these days and this is more easier than DDoS. Massive connection and wait a while will accomplish it easily.
4. I'm not asking you to change the spec. I just want the miner to count from random number only when extranonce length is 0 or 1.
It will not harm rental buyer, seller, other pools.
5. So, is it okay for me to distribute your implementation after I fix those nonce lines. You told me that you are not the official distributor, then I may be one of ethminer dev then. I would help implementation merged to genoil.
6. What I want from you is just don't block short extranonce length rental miners later. It will be fine, compatible with all pools.
Also, a modification you need to do on your side requires 10 minute of work if using proposed queue method for assigning extranonces.
Regarding miners; you assign extranonce when miner subscribes - do not assign on pure TCP connect establishment. Resource exhaustion of TCP/IP stack of your server is your bigger worry if someone decides to DDOS you with 64k fake rigs. And like I said, these types attacks are easy to filter out. It is much harder to filter bandwidth attacks.
I can tell you how someone can create CPU exhaustion having wildly accepted ethereum stratum implementation relying on randomness - but you still gladly use it. Having just 1000 miners (64 times less than your worry), each sending duplicate shares. This would create a lot of CPU utilization for checking all shares, because you check each share against globally received shares from all customers. I believe that is why pools use rather high difficulty, where miners usually find 1 share per 5 minutes of mining, so that checking shares for duplicates is not so intensive process.
Therefore another great thing of EthereumStratum/1.0.0 are low diff shares for miners - so that every second of mining can be rewarded, payouts are more predictable and consistent and that is all what miners like.
@NiceHashTech
Okay.
I will just follow your suggestions since I can't force update already miners using it.
When I first suggested new idea, hash was not that big but it's already 21GH/s on your site. WOW.
I'm quite curious that where did users get that miner binary?
Can you point one of repository or download link?
Two ideas both have pros and cons.
I agree that your original spec is quite good.
I was just suggesting because I want it to be the final, ultimate, ideal implementation.
There's so massive protocol, spec on ethereum pool mining out there. I don't want more implementation after this.
I will make extranonce thing perfect unique soon, and make it compatible with previous stratum port.
Making extranone unique is not that big problem, I know how can deal it.
I feel like maybe I was too anxious about 64k attack.
Also, 1000shares/s can be easily calculated from our pool. Pool is extremely optimized. Our pool's share target time is about 20 seconds. We don't use high difficulty actually. There's not much pools support vardiff, so they had to stick to high diff.
Anyway, great work you guys.
I will make new stratum port compatible with current one and open it soon.
Thanks.
BTW: all pools that are still not compatible with NiceHash rented hashing power are welcome to add support.
I think I have completed making two stratum compatible in one port, and almost ready to announce.
I'm testing real rental hash from nicehash and have some questions.
1. What is the maximum speed (or difficulty) for your one connection to pool? Is it limited?
2. How does Delta calculated from your service? Pool didn't reject share, but your delta thing goes up and down like rollercoaster. Is this normal?
3. Seems like miner program submits share twice by bug sometimes. (It's already reported bug from genoil-ethminer and nicehashminer would have this bug too)
Is nicehash checking nonce duplication before sending to pool? Or just sending it to pool without any check.
I'm happy with your service. Great job.
Thanks for you good job on the pool!
I will open all nicehash compatible ports in few minutes. Thanks.
Mining Pool Hub's ethereum 20535 port supports both stratum protocol now.
Also Ethash auto profit switching port 17020, Ethash multi-algo endpoint 12020 are also compatible.
us-east1.ethereum.miningpoolhub.com:20535
europe1.ethereum.miningpoolhub.com:20535
asia1.ethereum.miningpoolhub.com:20535
Thank you nicehash.
Sorry that it took some days to complete.
Another issue i'm having is not being able to connect to Coinotron at all. Here are my configs and error messages, any help would be appreciated.
Coinotron is still having connection issues: What is the correct connection string for Coinotron that currently works?
Using the above connection details could you provide a successful setting,