Unfair advantage for pools with massive hashrate

[RustyBlock]

Hi Electroneum Team, thanks for the great work you are doing. Looking forward to ETN taking over the World soon :)

We are running a small pool at https://www.etn.rustylock.club that was doing quite well until network hash-rate increased and, more importantly, most of the hashing power became concentrated on few pools like Nanopool (https://etn.nanopool.org/) or Spacepools (https://etn.spacepools.org/). Spacepools is much slower now but it was running 100 MH+ before Nanopool started.

Since network speed went significantly up, we observe efficiency of all pools going down, even the big ones report a lot of extra effort (e.g. quite a few high effort %s here https://etn.spacepools.org/#pool_blocks). Even whattomine has a notice about negative luck on ETN mining. I think this is happening because replication of new blocks is taking about the same time it takes to find a new block so network is in constant update mode. Add rebuild operations (caused by forks) to the picture and you can see it looks quite grim. If pool manages to attract about half of the network hashing power or more, this is less of the problem for them because they start with new block immediately after they found the last one and chances are high they get the new one too so other pools have nothing to do but just refresh their daemons without making even one attempt at finding the next block.

Is it possible (or did you even consider this) to make an arbitrary increase of the difficulty to bring block detection time above 5 minutes so all pools have chances to find a new block but not only the ones that occupy 50% of the network hash-rate.

Hope this makes sense and other pool owners will join me in this request.

Kind regards RustyLock Team

[cylim87]

I support this.

[ghost]

@electroneum do something please

[Pinto85]

I saw this pool http://poolmining.network/etn/, how is it possible that it took so many blocks with a hashrate so low? I would just like to understand better, thanks

[RustyBlock]

@Pinto85, see all payments made to one miner and number of hashes submitted is quite high despite the current speed and number of miners connected. Most likely this guy is using nicehash to buy bursts of very high speed so blocks are found quickly. Anyone can do it but you can also check and calculate his real profits which is likely negative so he is doing it for making long term gains while suffering short term losses.

[bobbieltd]

@Pinto85 : That pool is FAKE and SCAM. If you carefully look at blocks found, they are WEIRD and NOT CORRECT. Cheating newbie miners 🤪🤪🤪

[bobbieltd]

Does anyone have a solution for young small pool ? My semiPOOL can’t compete with big pools 😰😰😰. Only few miners. Situation is worsen because luck keeps bad.

[cl0ck3r]

Electroneum is an shit coin!

[Pinto85]

I tested my pool for over 24 hours with 100Kh but no block found. There is something wrong @electroneum

[bobbieltd]

@Pinto85 100 kH/s is too low to find a block in 24 hours. It’s normal.

[mounirrquiba]

Hello @RustyBlock @aboljamajem @bet0x @cooltaby @RatusNatus @electroneumRepo i have do some tests after this issue posted results:

With 9.9MH/s for 24h -> 2 blocks With 5 MHs fot 24H -> 1 block With less -> no block

all blocks found at diff 7000 - 7200 ..

I have changed maxDiff from 2000 to 700000 but nothing happen better, pool -> http://etncoin-pool.org

ps: lost a lot of coins for this test... +2BTC

Happy Mining!

[MrCoolLV]

@Pinto85 i agree with you, 120 pumped 120kh/s for 5 days and no block this all started happing "after" etn crash, soon after the rebuild no more blocks after the crash.. before the crash was fine block per day or other day

[reaperx7]

The pool I frequent, pool.hashusa.win has hit a heavy block for about a month now without a solve. It's getting worse. We were getting about 35kh/s and a block every 5-7 days. Since the big update, we have only gotten about 2kh/s and the block time has been over a month.

We can't compete against nicehash, and bigger pools hauling in hundreds of kh/s in power. Most of us have switched to the Android miner to get anything, but getting 10 ETN takes forever.

I don't want to say it but the block difficulty for larger pools needs to be adjusted so these pools averaging the rates they are getting get higher difficulty blocks while smaller pools get easier ones.

[reaperx7]

If anything, I'm mining GRF (graft) now. Its still cryptonote based so just some minor adjustments and I'm good to go.

[MrCoolLV]

I agree same issue with my pool, must of our miners now moved on because of the block issues from the big update

[reaperx7]

Unless the pool generation time is pushed back to at least 10-15 minutes per generation and pool search times pushed out to at least 20-30 minutes with 5 minutes wait for retries between seeks, this is going to get ugly. I really do not want to have to rely on 3-5 h/s for the rest of my ETN mining to get anything significant using the mobile miner. They also need to implement an orphan dumping mechanism to auto drop orphan blocks out of the network and pools to allow pools to get fresh blocks faster if orphans are found.

On Mar 21, 2018 6:04 AM, MrCoolLV notifications@github.com wrote:

I agree same issue with my pool, must of our miners now moved on because of the block issues from the big update

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/electroneum/electroneum-pool/issues/145#issuecomment-374929072, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJ9w-sK4oTZOfBITmgmH1KeRIRfwOOvAks5tgk-_gaJpZM4RWPqR.

[Pinto85]

i understand that @electroneum is only marketing

[mounirrquiba]

Ok, let's try good diff coins: https://bbscoin.xyz or https://stellite.cash/

Happy Mining ;)

@RustyBlock @aboljamajem @bet0x @cooltaby @RatusNatus @Panthro @perl5577 @Pinto85 @phil2cr @PhillipVoyle 👍

[mobias]

@RustyBlock Please look at this https://github.com/electroneum/electroneum/issues/197

[reaperx7]

The amount of available sponsored pools has shrank considerably since this issue was opened. Nanopools and Spacepools literally have choked everything out by causing redundant orphan blocks to get picked up by smaller pools which causes people to not want to mine.

If this trend continues two massive pools will control more than 51% of the block chain, which could cause a problem with mining efforts by independent miners and other pools. Remember if 51% of a blockchain can be controlled it has a higher risk of being attacked.

This is where the timed block generation measure and solving wait times and orphan checking and an orphan dumping system needed badly. Nobody wants to wait till an orphan block is solved only to hit more repeated orphans.

On May 1, 2018 4:17 AM, mobias notifications@github.com wrote:

@RustyBlockhttps://github.com/RustyBlock Please look at this electroneum/electroneum#197https://github.com/electroneum/electroneum/issues/197

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/electroneum/electroneum-pool/issues/145#issuecomment-385649224, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJ9w-jWsPvUOgWcTFdGGRVaYtkV9-erkks5tuERBgaJpZM4RWPqR.

[mobias]

We also close our pool because Nanopool has 51% hashing power.

[reaperx7]

I think a viable solution would be to do this:

• Set a mandatory timer of at least 5 minutes from the time of solving a block to picking up a new block generated.

• If a pool gets more than 20% hashing power of the entire blockchain, and the generation timer has not expired, the pool has to pick up a mandatory orphan block dumped by smaller pools.

• Any pools with less than 20% hashing power would be able to automatically dump an orphan block back into the blockchain and pick up a fresh generated block if one exists in the waiting list. No pools with less than 20% hashing power are required to solve an orphan block.

• If no orphan blocks exist in the network, all pools regardless of hashing power must still wait until the timer expires to pick up a new block, highest priority of pickup is reserved for lowest hashing power.

On May 1, 2018 4:53 AM, mobias notifications@github.com wrote:

We also close our pool because Nanopool has 51% hashing power.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/electroneum/electroneum-pool/issues/145#issuecomment-385654660, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJ9w-uXXWPNzHL_P-9h9xrkL_1vmzS_-ks5tuEy0gaJpZM4RWPqR.

[oliverw]

By now it should be pretty obvious that the people behind this project don't give a damn about a healthy mining ecosystem.

[reaperx7]

Especially when some of nanopool's highest hashes are in the 27 million h/s range. Those guys eat up literally all the coins.

I would estimate even with an Nvidia DGX workstation running quad Tesla V100s or Quadro GV100s with 4-way NvLink and the highest end dual Xeon or Threadripper CPU, that you'd barely get a fraction of that hashing power.

Those seems like numbers only achieved by ASIC machines.

On May 1, 2018 5:57 AM, Oliver Weichhold notifications@github.com wrote:

By now it should be pretty obvious that the people behind this project don't give a damn about a healthy mining ecosystem.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/electroneum/electroneum-pool/issues/145#issuecomment-385664754, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJ9w-qAFZs0Asf1fa7yLI_VF-MIdGNFnks5tuFvEgaJpZM4RWPqR.

[MrCoolLV]

Yup, and is ok I won't be coming back to ETN

[reaperx7]

The problem is, unless its corrected in Monero, this problem is going to spread around all the cryptonote cryptocurrencies and eventually any dream of decentralization is going to be lost. Even implementing it in ETN or GRF would allow a backport to XMR and every other cryptonote out there.

The other problem is, the difficulty rating has exploded over the past no the due to this issue.

I would dare to accuse nanopools and spacepools of using specialized ASIC machines to gain an unfair advantage, but if I did, I might be correct, because even some miner rigs don't get the hashing power levels they're hitting by far.

On May 1, 2018 6:25 AM, MrCoolLV notifications@github.com wrote:

Yup, and is ok I won't be coming back to ETN

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/electroneum/electroneum-pool/issues/145#issuecomment-385670016, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJ9w-tjMSH8rFkFnahhk6hWPCkqXlBFuks5tuGJXgaJpZM4RWPqR.

[RustyBlock]

In the new release (after 30th of May) we are getting 2 minutes for the block. Not 5, if course, but still good. Mind that issie with block time is separate from asics problem. I started this request before aby asics arrived. Block timing of 1 minute is not a good choice because it's almost equal to the time needed to propagate the block data to most of the nodes. This means big part of the hashing power goes wasted, working for a block that is gone already, or creating orphans.

New update introduces 2 minutes block time and revised block reward because now miners will be finding blocks less often. Combined with anti-asic measures, it will be awesome for the community.

[reaperx7]

Two minutes is a start, but you still have the problem of nano and space both grabbing extremely high hashing power where they can solve blocks in minutes. Five minutes, plus a prioritization rule set, plus a requirement of dedicating highest hashes for getting rid of orphans rather than just anyone, and making sure all pools have equal footing would be better still.

Its still going to be lopsided, but two minutes is a start, but when you have a unknown rig design generating 27,000,000+ h/s it's at least better than nothing to curb the problem.

On May 1, 2018 8:35 AM, RustyBlock notifications@github.com wrote:

In the new release (after 30th of May) we are getting 2 minutes for the block. Not 5, if course, but still good. Mind that issie with block time is separate from asics problem. I started this request before aby asics arrived. Block timing of 1 minute is not a good choice because it's almost equal to the time needed to propagate the block data to most of the nodes. This means big part of the hashing power goes wasted, working for a block that is gone already, or creating orphans.

New update introduces 2 minutes block time and revised block reward because now miners will be finding blocks less often. Combined with anti-asic measures, it will be awesome for the community.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/electroneum/electroneum-pool/issues/145#issuecomment-385701716, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJ9w-rxWg5JuvHC7sU4a59e6urlYYJJ3ks5tuIC9gaJpZM4RWPqR.

[mobias]

5 Minutes is a good choice.

[mobias]

after 30 May ETN network hashrate equal to 100 MH/s then we need to change time to 5 mins.

[RustyBlock]

Issue is addressed in the v2 release. Thank you for listening!