Over the past few weeks the Safex blockchain has faced a number of difficulties which has forced the team to push forward a number of updates and hard fork the chain.

The hard fork includes:

A new mining difficulty algorithm

A reduction in the future time limit on blocks



What happened to the blockchain?

There are two separate issues that need to be addressed – the mining difficulty algorithm, and timestamp manipulation.



Difficulty algorithm

As with many CryptoNote forks, the Safex Blockchain adopted the same algorithm to calculate mining difficulty as Monero.

In the blockchain, a difficulty score is added to make a block more or less difficult to mine, to try and keep it as close to the target block time as possible (In Safex’s case, it’s 120 seconds). If a block is found sooner than the 120 second target, the difficulty rises – if it takes longer, the difficulty drops.

Safex’s original difficulty algorithm operated on averages. It would take the difficulty score of the last 720 blocks, remove the quickest 60, and the slowest 60, and then calculate the average over the remaining 600 blocks.

Within a high hashrate blockchain, such as Monero, this algorithm is suitable enough. However, for newer blockchains, that won’t have as much network hashrate as Monero, it has the potential to be exploited.

Miners could potentially exploit this “difficulty adjustment lag” by throwing larger quantities of hashrate at the blockchain, causing them to find a decent number of blocks in quick succession.

Because it would take a minimum of 60 blocks for the difficulty algorithm to react to the increased hashrate, the miner could peacefully mine away. Once they’ve mined past the initial 60 blocks, they still have some runway as the difficulty is calculated and smoothed out over an average of 600 further blocks.

Typically, once the difficulty score increases, the exploiter stops mining – leaving the rest of the miners to deal with a blockchain that has been adjusted to a higher hash rate. In turn, this results in longer block times which obviously is inconvenient and annoying for the mining community.



Timestamp manipulation

This process is a little more complex to explain in a quick article; but in summary, a solo miner would be able to throw enough hashrate at a network (typically via NiceHash) to cause a chain split. The miner then would manipulate the timestamps of blocks they find, which would cause the difficulty on their split chain to drop sustainably.

The miner would then continue to mine the split chain with no competition and then reinsert it back into the main chain. As the split chain is longer than the original chain, it would be accepted by the network, and the miner would get away with mining hundreds of blocks unimpeded.



What has changed?

Safex has implemented the LWMA difficulty algorithm developed by Zawy12. This algorithm is better suited for lower-hash blockchain networks such as Safex.

Again, the subject is too complex for a single article, but you can read more about the algorithm on this Github page.

The LWMA algorithm is designed to be more responsive to spikes in hashrate. The difficulty will rise quicker when more hashrate is added to the network, and it will decrease quicker when the increased hashrate is dropped.

In addition, further changes have been made to thwart the ability to split the chain and manipulate the difficulty score with CRYPTONOTE_BLOCK_FUTURE_TIME_LIMIT. The function rejects blocks with unusual timestamps as well as a few other reliability checks.

Full comparison of what has been changed can be found here.

PsychoSterope, operator of CN Pool commented:

“I see this change as the correct next step in the long term viability and stability of Safex and the community at large.”



Do I need to change anything?

If you’re a miner, you do not have to change any settings in your mining software.

If you run a Safex node, you will have to update it to v0.1.2. The Windows and Ubuntu 18.04 binaries can be found on github.

https://github.com/safex/safexcore/releases/tag/v0.1.2

If you are having group syncing with the right chain, simply delete your original chain files and resync.

The files are located: