Feathercoin daemon and wallet production version 0.19.1
Old daemon and wallet version 0.18.3

Feathercoin Difficulty 3-4-2017

  • Moderators | Tip wrapper

    I’ve done an examination of the Feathercoin Transaction Blocks Difficulty calculation over 1000 blocks.

    The result were much as before last time it was tested in June 2016.

    It can be seen that, eHRC algorithm kicks in and increases the difficulty as the hash rate rises, the quickly reduces it as the hash decreases.

    The resulting average block time is 1 min 6 secs, for the current level of difficulty variation. In that, there always has to be a delayed response and variations are significant compared to the baseline hash.

    Difficulty varies from 5 to 13 with an average of about 7
    Highest difficulty is 18, lowest 3 showing continued hash switching between coins, probably due to multicoin pools.
    Most of the Transaction blocks are within 30 secs to 1.5 minutes

    1 block out of 100 had an anomalous time (44, 42, 44) mins. (607)



  • Regular Member | Tip gonnaforget

    How many times were there ten blocks in a minute and a half? That seems pretty improbable.

  • Moderators | Tip Wellenreiter

    @gonnaforget said in Feathercoin Difficulty 3-4-2017:

    How many times were there ten blocks in a minute and a half? That seems pretty improbable.

    You simply can’t avoid that.
    If the hash rate multiplies within the timeframe of one or two blocks, blocks are found within seconds.
    A way to mitigate that is to reduce the damping and change the averages used to calculate the difficulty.
    The big drawback of that is, that it opens the BC to special attacks, forcing the difficulty to go up and down in a predicable way and very fast, what can be used for ‘selfish mining’.
    Selfish mining is a term for somebody throwing a big hashrate at a coin when the diff is low, earning a lot of coins, an as soon as the hash rate goes up, switching over to mine another coin, leaving the remaining miners with a high difficulty and low hash rate, what causes the difficulty to drop slowly, as it takes a long time to find the next block and propagate a new difficulty.

    Our eHRC algorithm has prooved to give the best results to keep the feathercoin block generation stable.

  • Moderators | Tip wrapper

    @Wellenreiter is correct. The greater the baseline / p2pool / non switching level, the less effect the coin switchers have.

    That is why, in particular @Wellenreiter has maintained p2pool for Feathercoin to maintain a distributed network.

    eHRC was tested over a number of months to compensate for various “attacks” or big changes on the mining hash rate FTC and other coins were experiencing. At that time it was Litecoin ASIC miners switching coins, later Multicoin mining became the main culprit (after switching to Neoscrypt)

    However, all algorythms can not see in the future, they can only react. To do this eHRC looks at the short term hash rate, over minutes, the medium hash rate over hours and long term over a day and re-targets the difficulty at each block.

    The eHRC system was tested against Kimoto Gravity Well and gave comparable results with optimum settings. However, is a simple enhancement of the standard Bitcoin method of calculating difficulty (and therefore has no untested concepts or methods), but with vastly reduced number of calculations / energy / sync time usage over KGW.

    The algorythm is designed to maintain an average of 1 minute blocks. If there is a lot of hash variation this can increase to 1 min 6 secs over a day. However some blocks will be found more quickly if someone (say like Nicehash) can move their power from coin to coin and only mine at high profitability ( ie low difficulty)

  • Regular Member | Tip gonnaforget

    Gotcha. That makes a lot of sense, and I can totally see why that could be a problem, especially if ASIC miners were going around, targeting each coin for a short time then switching to the next.

  • Regular Member | Tip Phlosen

    At least for now, ASIC is out of the Picture. But Multipools can still cause a simillar effect

Log in to reply