Unfair advantage for pools with massive hashrate #145
Comments
|
I second this. |
1 similar comment
|
I second this. |
|
agree our pool died just because not getting any block even with hashing with 150 khs for 48 hours , thats sucks, all moved to mine another coin, too many orphan blocks |
|
"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." I think this is a good idea to all starting coins when something like this happens. |
|
Young and small pools are in danger. We need to do something. |
|
You are right and you can see that also clearly on AEON. It is true that if the situation continue like that, our pool will also move to others coins ! |
|
I would like to add that: It is even not in the interest of the big pools to kill littles ones because: The coin will look 'controled' and centralized so it will loose is value. And more pools will go to others currencies, more the coin will look centralized. So it is a loose - loose situation. |
|
@RustyBlock |
|
I didn't check the code yet, but there has to be the place where we calculate difficulty, just up it there. How to make sure everyone upgrades to the new version is a real question. Would be a soft fork situation with ETN guys needing to coordinate the upgrade. E.g. nodes upgrade and start "signaling" the new version support but still use old settings. Then when most of the nodes upgraded, switch network to new rules and old nodes stop to function. |
|
This does seem to be a cumbersome task, especially for Electroneum company that is already overwhelmed. Do you think we should submit this to HackerOne as a potential vulnerability? BTW, has anyone noticed that the link at the bottom of nanopool.org homepage links to website for the Chinese government? If this is indeed related to the Chinese government, we could really be looking at an attempt of 51% attack. |
|
we have small pool www.asiaetnpool.com due to many days with 80 khs no block found all moved out now we broke and willing to close or sell it out :( its very hard to hit block |
|
@aboljamajem, I don't think there's conspiracy against Electroneum. Currency isn't doing anything yet and it will never be if people learn it was taken over by 51% attack. Link to the government website is just their company registration details, we can relax about 51% issue, however we can see the cases of market abuse by the big players that using the difficulty setting issue. |
|
I agree. |
|
We need a solution for small pools. I suggest a certification system formed by well known devs. They will check if the pool is sincere with the codes so miners are not worried when they want to mine with small pools. Avoiding scam pools too. |
|
You want to slow down everyone's transactions so that your little pool can gain an advantage (which it wouldn't anyway). Brilliant. |
|
No, we want to avoid big pools taking everything, simple as that. |
|
There is no such thing as "big pool", any pool can become big if they throw lot of money at nicehash or somehow attract a lot of mining power elsewhere, not important. It's not a problem, it's ok to have big pools (not more than 51% though). More of them is better for the currecny - it gets stable hashrate. The problem is the mismatch between network's time to find a block and network's time to sync up. Now it's almost the same or network sync time is even longer so all miners get affetced - big and small but big are "less affected" or even have advantage since they can build new blocks on top of their own so network sync delay doesn't matter for them. |
|
I know that Grimm2017 points to block time and network difficulty but it doesn’t matter here. The principal issue is that small pools are dying. |
|
Yes, my suggestion is to slow everyone to the network rate. What's the point in finding blocks faster than we can get them synced around all blockchain? Also creates lot of issues for users of the blockchain who can get their transactions included in the chain that gets killed due to the softforks caused by this crazy speed that network can't handle. It's a mess now. |
|
@RustyBlock or make a fork or an other currency with quality in mind. |
|
We endorse this proposal as well. This has become a problem with many coins lately, not just this one. |
|
Honestly what is the incentive to start a pool yourself after seeing something like this? |
|
Yes, and there is more. Lot's of little pool decrease the fees. but without gaining more H/s. One more easy solution could be pooling for new crypto, that way, making the currency less credible for a time. Is it is well explained to miner they could follow. Little pools could recommand new cryptos and if miner are confident it is good for every body. |
|
@phil2cr I actually did start a pool for GRAFT(GRF) graftmine.net while keeping electromine.net running on 0% fees and no blocks since 10 days. Once Electroneum fix this issue, I will recommend for users to jump back in. |
|
In my opinion ETN was launched too quickly. Could be a good value in some years. |
|
Let me get this straight. |
|
No, we ask the developers to implement safety features that prevents/discourages transforming the decentralized solution to a centralized one |
|
I saw this pool http://poolmining.network/etn/, how is it possible that it took so many blocks with a hashrate so low? |
|
@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. |
|
@Pinto85 : That pool is FAKE and SCAM. If you carefully look at blocks found, they are WEIRD and NOT CORRECT. Cheating newbie miners 🤪🤪🤪 |
|
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. |
|
Electroneum is an shit coin! |
|
I tested my pool for over 24 hours with 100Kh but no block found. |
|
@Pinto85 100 kH/s is too low to find a block in 24 hours. It’s normal. |
|
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 all blocks found at diff 7000 - 7200 .. I have changed maxDiff from 2000 to 700000 but nothing happen better, ps: lost a lot of coins for this test... +2BTC Happy Mining! |
|
@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 |
|
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. |
|
If anything, I'm mining GRF (graft) now. Its still cryptonote based so just some minor adjustments and I'm good to go. |
|
I agree same issue with my pool, must of our miners now moved on because of the block issues from the big update |
|
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 GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJ9w-sK4oTZOfBITmgmH1KeRIRfwOOvAks5tgk-_gaJpZM4RWPqR>.
|
|
i understand that @electroneum is only marketing |
|
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 👍 |
|
@RustyBlock Please look at this electroneum/electroneum#197 |
|
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:
@RustyBlock<https://github.com/RustyBlock> Please look at this electroneum/electroneum#197<electroneum/electroneum#197>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJ9w-jWsPvUOgWcTFdGGRVaYtkV9-erkks5tuERBgaJpZM4RWPqR>.
|
|
We also close our pool because Nanopool has 51% hashing power. |
|
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 GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJ9w-uXXWPNzHL_P-9h9xrkL_1vmzS_-ks5tuEy0gaJpZM4RWPqR>.
|
|
By now it should be pretty obvious that the people behind this project don't give a damn about a healthy mining ecosystem. |
|
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 GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJ9w-qAFZs0Asf1fa7yLI_VF-MIdGNFnks5tuFvEgaJpZM4RWPqR>.
|
|
Yup, and is ok I won't be coming back to ETN |
|
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 GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJ9w-tjMSH8rFkFnahhk6hWPCkqXlBFuks5tuGJXgaJpZM4RWPqR>.
|
|
In the new release (after 30th of May) we are getting 2 minutes for the block. Not 5, if course, but still good. New update introduces 2 minutes block time and revised block reward because now miners will be finding blocks less often. |
|
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 GitHub<#145 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJ9w-rxWg5JuvHC7sU4a59e6urlYYJJ3ks5tuIC9gaJpZM4RWPqR>.
|
|
5 Minutes is a good choice. |
|
after 30 May ETN network hashrate equal to 100 MH/s then we need to change time to 5 mins. |
|
Issue is addressed in the v2 release. Thank you for listening! |
and others
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
The text was updated successfully, but these errors were encountered: