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

[ghost]

I second this.

[bet0x]

I second this.

[cooltaby]

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

[RatusNatus]

"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.

[bobbieltd]

Young and small pools are in danger. We need to do something.

[phil2cr]

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 !

[phil2cr]

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.

[phil2cr]

@RustyBlock "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" How do you think this could be implemented ?

[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.

[ghost]

This does seem to be a cumbersome task, especially for Electroneum company that is already overwhelmed. However, it seems either this, or leave everything as is leading to a potential 51% attack. Which could be huge since we are sitting on a $800mln market cap.

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.

[cooltaby]

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

[RustyBlock]

@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.

[dyablohunter]

I agree.

[bobbieltd]

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.

[ra-dave]

You want to slow down everyone's transactions so that your little pool can gain an advantage (which it wouldn't anyway). Brilliant.

[bet0x]

No, we want to avoid big pools taking everything, simple as that.

[RustyBlock]

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.

[bobbieltd]

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.

[RustyBlock]

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.

[phil2cr]

@RustyBlock or make a fork or an other currency with quality in mind.

[oliverw]

We endorse this proposal as well. This has become a problem with many coins lately, not just this one.

https://coinfoundry.org/pool/etn

[ch-ill]

Honestly what is the incentive to start a pool yourself after seeing something like this?

[phil2cr]

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. As peer electroneum, the communication seems, how to say ? Ambigous at least.

[ghost]

@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.

[phil2cr]

In my opinion ETN was launched too quickly. Could be a good value in some years. and yes you are right, i will also go to other crypto.

[Zer0dn]

Let me get this straight. You complain that you want the creators of the coin to control how it is mined and how it pays out? That is a centralized problem which defeats the purpose of blockchain at its very core. If you had read the technical white papers the entirety of your blockchain solution and payout equations are in there. As for the pools that have the most you are correct however it is an inevitable issue where a site will have a problem and the miners will bail to another pool. That is how SpacePools grew so large because the early pools had issues and they were the only ones not having it and they had a low pool fee. That said I run my own pool as well. In a few months this argument will however become irrelevant as the startup pools that could not wait with no miners will have become impatient and quit. I have developed my own strategies to make my pool valuable to the coin. Do the same for yours if you want it to remain alive. It takes marketing, innovating, and above all good operations.

[ghost]

No, we ask the developers to implement safety features that prevents/discourages transforming the decentralized solution to a centralized one

[Zer0dn]

It is controlled by the free market. Miners are free to mine from whatever pool they deem suits them best. While one mining pool submitting most of the blocks found does not mean that they are centralized because confirmations occur across the chain.

The "creator" should not be the central source controlling the pools. The features were spelled out in the TWP. The market is swarming atm to a few major pools but like I said earlier that isn't something that the devs should control. That is no less centralized than the problem you want them to fix. The solution is to develop good pools that are ready to roll and still running when the pool that has the major population atm has a tech issue and the miners disperse. Having more working pools for them to land in means the network diversifies to a greater degree.

This is just my thoughts and opinions about how to best deal with it.

[phil2cr]

BTW remember : the creators of the cryptonight protocol (ETN is based on this one) precisly build it too avoid one big mining pool take the control over the currency :) ! They permit to avoid ASIC, but maybe didn't foreseen a coin attacked from start.

[RustyBlock]

@Zer0dn, looks like you're not yet understanding the point of the original request but offer generic business advice and conclusions which is right, of course, but your messages are beyond the subject of this discussion. Difficulty calculation is in the code of the daemon, inside the net, nothing to do with centralization / decentralization matters you bring. Now it's set to 60 seconds which is way too low for this network size and speed. It's a hard change because modification of the way that difficulty is calculated on the network requires all nodes "rebuild".

Potential solution: targeting difficulty by number of blocks instead of the fixed time window might be a good idea that will remove big pool advantage, make every miner equal and rewarded according to the work they submitted to the network regardless of how and where they did it.

[Zer0dn]

No I understood it perfectly.

[bet0x]

@Zer0dn You didn't understand, now leave this talk to people who is actually looking for a solution.

A good move will be to do a Q&A on Pool code. Too many forks, no one is contributing except a few.

[Zer0dn]

@bet0x how very presumptuous and ignorant of you. On that note I will do as you requested.

I am not here to troll or harm this project and I apparently incense you.

Sorry for that.

[phil2cr]

"Too many forks, no one is contributing except a few"

Before even thinking of contribuing you have to understand and struggling with the code. Maybe that's why nobody contribute. I would like to contribute ! but before i understand all of these an other version will be on line :)

btw some bug fixed for some long time are even not contributed by the authors themself. Like the version 1.1.5 seems to have vanished.

@Zerodn has not my opinion but it is good to have the point of every one. Please calm down.

The solution of @RustyBlock could be a good one, the point is what to do if the dev team of ETN don't want to upgrade ?

[bittcoin555]

Ok how do i mine on ios apple phone or no these for cpu windows or mac and how do i add this One http://electroneumpool.pw

[bet0x]

@bittcoin555 This is not a support thread. Don't go off topic.

[Namba06]

I agree. We have a small pool http://electroneum.mining-pool.info started on January and after 14 days with 25KHs no block found. It will be good if someone on Electroneum team could help small pool like us. Should we have to update our pool ? Thanks for help, Regards,

[RustyBlock]

You can't do much to improve your pool performance, big or small, all are inefficient and wasting hashing power due to the issue with difficulty setting. If you look at other CryptoNote-based currencies, they set difficulty with expectation of 2 or more minutes per block. Electroneum network is running on the expectation of 60s that in reality brings us close to 30s per block because people periodically push lot of hashing power from Nicehash.

I haven't got much time for this recently but still planning to make a fork and test 4 minutes setting with testnet. Then I'd issue a pull request suggesting to increase difficulty setting to 4 minutes and double the block reward to make sure miners' profitability doesn't get affected.

[Namba06]

Thank you very much. I understand your answer, but do you think we will find a block one day or it has become impossible for a pool of our size?

[RustyBlock]

I can see you found your block 13 days ago so, if you didn't break anything since, you will find another one. You just need to ignore the estimated block time that pool is showing, it simply divides network difficulty by your pool speed assuming all your hashes are useful. However, in reality, lot of your hashing power is going against the future blocks that someone already found so your pool just fails with an error that transaction is missing in transaction pool or something like this. If you check the logs, you may see you found more than one block but it was not accepted.

[phil2cr]

@RustyBlock Thanks for your work. Why not make a fork with your idea and create an other coin on it ? Don't need an ICO if the coin is good for miners. Electroneum is online only since last november...

[briancfalls]

ucrypto dot com has not found a block since the old page was shut down by Amazon and the new page started up 11 days ago, it reset to zero Jan. 19th at 7:41 am and I lost 8 million hashes, I still have 3 million hashes afterward before I got booted from their Facebook page for pointing this out, and not a single fraction of ETN paypout, they have just over 80 loyal miners still and no Blocks ever found. I am now in easyhash getting ETN regular, with 2.7 Mh/s and 2,700 miners and blocks constantly found, but I am also in us-etn-pool hashparty as well, and no block has been found for the past 2 days with a hash rate of 645 Kh/s and 1300 miners.

[RustyBlock]

@phil2cr I don't have time to run new coin and it makes little sense. technology is only 25% of success in this business.

[bet0x]

@phil2cr There is no point on running a fork or another coin. With all the ICO and stuff and alliances they should actually have time to fix this, wich is sad because we have no official response yet. Even nodes are having issues.

[phil2cr]

@RustyBlock @bet0x yes it is sad I don't think that will be fixed quickly. ICO and alliances take time, but on the long run the quality of the blockchain will be the only warranty : as there are so many coins to come ... So why continue to loose hashrate ?

[PhillipVoyle]

I'm seeing the same problem on electroneum.mining-pool.info at the hash rate it's getting (22kh/s) it should find a block every week but has been live for 3 weeks with only one block found. Considering shifting to a larger pool where my machine's work counts for more.

[Pinto85]

Hi, i have a question, the speed of the pool can affect the time of block found? After 10 days i have found a block with 8Kh...I don't understand. My pool is cryptopool.top Thanks

[bobbieltd]

@Pinto85 : speed of pool is the most important to find a block. Luck is the second but in the long run, luck is the same for all pools.

[Pinto85]

@bobbieltd thank, I'll explain better, I meant the speed of the server, network or other not hashrate...

[bobbieltd]

@Pinto85 Sorry, if your server isn’t overloaded ( no high CPU usage, no high RAM usage, no high bandwith usage ), it doesn’t affect block finding.