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

Large increase in Hash rate variability / p2pool hash

  • Moderators | Tip Wellenreiter

    Just noticed, that the block chain hash rate also fluctuates a lot.

    BC difficulty at 2015-12-12 07:09:32 or block 999936 was 1.668
    BC difficulty at 2015-12-12 07:55:56 or block 999994 is 5.125

    So we definitively have some switching pools here. 😞

    Also the number of transactions is increasing, what is a good sign.

  • Moderators | Tip wrapper

    Our problem might be success … i.e. FTC has become a “most profitable” coin …


  • Moderators | Tip wrapper

    @Wellenreiter said:

    We have something like this since a long time already:

    from feathercoin main.cpp:

    // Check timestamp
    if (block.GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
        return state.Invalid(error("CheckBlockHeader() : block timestamp too far in the future"),
                             REJECT_INVALID, "time-too-new");

    So this can’t be the reason for the current hash rate variations.

    What we could change is the allowed time window, which is currently 2 times the block rate or 2 minutes, but we need to give some room for clock drifts and can’t go below 1 minute anyway.

    Nevertheless 2 minutes is a quite large window, as I assume that all mining systems use NTP and the clock drift should be counted in milliseconds rather than seconds.

    On the other hand due to network delay the propagation of a new block should be delayed only and the only danger we would have is, that the time stamp could move to the past, what is normal.

    May be @ghostlander or @lizhi can give their opinion.

    I agree with you, this was disused before and I was for tightening this. I see no reason to be > 1 times. If it did fail it would fail safer and more secure.

    if (block.GetBlockTime() > GetAdjustedTime() + 60 * 60)

    It may be worth a couple of patches, there is also a review and sharpening the parameters of eHCR (reduce short block average to 13 blocks and extend the long period, I discussed with Bush on previous data), removing the difficulty damping. Based on the current charts and trend of multi algo switching. prob cause HF though. 😞

  • Moderators | Tip wrapper

    Some signs the increase in p2pool global pool rate is a genuine GPU miners connecting in China, which might explain how so big, so quick. Not dismissing p2pool switching as a thing though.

  • Regular Member | Tip RIPPEDDRAGON

    cant wait to get my 20 remaining gpus back up and running, I will probably just park them mining ftc while they offset the cost of heating for the winter

  • Moderators | Tip Wellenreiter

    Additional 20 GPU will generate a spike in hashrate 😉

  • Moderators | Tip wrapper

    I’ve been monitoring LTC p2pool for an issue on github. I’ve been able to upload a couple of charts, which are showing some interesting developments as the global LTC p2pool hash rate has gone down by 50% overnight …


  • Moderators | Tip wrapper

    Here’s the results of Litecoin p2pool share difficulty monitoring.

    difficulty v hash ltc p2pool14-19 1 2016

  • Moderators | Tip Wellenreiter

    The trends look quite ok for me 🙂

  • Moderators | Tip wrapper

    Unfortunately, it is all Scrypt ASICs, so they can’t switch to mining FTC. 😉

    So they must have “pool” switched to get a big change in p2pool hash.

Log in to reply