Preventing NiceHash Pumps

Dear X-CASH community,

Since the birth of the project, we have always been very positive about using a non-modified version of cryptonight v1. This algorithm has several positive aspects which include low electricity consumption, ASIC resilience and high liquidity in the hash rates markets.

We knew from the inception of the project that having it Nicehash compatible could lead to significant network hashrate manipulation once the coin would be listed on the exchanges. At the same time, we saw Nicehash as a mandatory piece of the ecosystem because it allows for better liquidity of the hash rate which leads to a lower discrepancy between market and mining prices. Indeed, every time the market price would spike, miners would be able to adjust the mining price in a matter of minutes so that there is no arbitrage between the two. Without Nicehash, this is merely impossible, at least in a reasonable timeframe.

However, some people have been using Nicehash to send bursts of hash rates at specific frequencies which allow them to arbitrage the difficulty mining algorithm. In short, this allows them to mine significant amounts of XCASH at a (low) difficulty which doesn’t reflect the real difficulty they should mine at. We forecasted this scenario in the whitepaper and warned the community that abuses would lead to an action from our end for this to stop. It is now time to put this in practice.

Among the possibilities reviewed, our current plan is to modify the difficulty algorithm by using zawy’s LWMA algorithm (https://github.com/zawy12/difficulty-algorithms/issues/3). We are setting up a modified version of its LWMA-2 which will allow for fast response time when experiencing network hashrate jump. In short, this algorithm uses a much lower timeframe (90 blocks vs. 720) with an additional difficulty adjustment when blocks are found too fast. We will also be adding an extra adjustment for the difficulty on the downside when blocks are found too slowly. To give you a more pragmatical picture of what this algorithm will do: in the case of a network hashrate jump by three times, the difficulty will be adjusted in around 15 blocks.

We think this solution is currently the best tradeoff before the PoS implementation as it will give us the best of both worlds: high tolerance to Nicehash bursts while keeping Nicehash liquidity. With regards to the timeframe of the implementation, we are in a complicated equation where we had initially planned to hard fork in late October, but we cannot wait until then as this is causing a significant threat for the sustainability of the project. We are currently reviewing the possibility of making an all-in-one hard fork release where we will have: public & bulletproof transactions, new difficulty algorithm and (increased) static ring size. The targetted release for this most likely scenario is October 18th. This is still conditional on a few external elements, and we will confirm and communicate more details in the next days.

Guilhem