Feathercoin daemon and wallet production version 0.17.0.2

Large increase in Hash rate variability / p2pool hash


  • Moderators | Tip Wellenreiter

    P2pool hashrate is back to normal

    May be it’s not related, but my feathercoind on the pool server was hanging just now (~ 5:50 PM MEZ)

    If more coins move to Neoscrypt, it is good for the algorithm. It becomes more popular.


  • Moderators | Tip wrapper

    There’s currently a major DDoS on UK University Janet system, so there might be some repercussions of that sort of stuff.
    It looked like some “farms” or private miners , as opposed to coins…


  • Moderators | Tip Wellenreiter

    It’s definitively a p2pool node in Canada, which comes in incredible high hash rates, but only for a short time, some hours only.
    Then it’s hash rate goes down to 0.
    Nevertheless the pools share difficulty is driven high by this node and it takes time to get down to normal share difficulties.
    To be clear, I talk about pool share difficulties only. The block chain difficulty is calculated from the total hash rate, including solo miners and non- p2pool pools, so this is not influenced that hard.


  • Moderators | Tip wrapper

    I agree, seems to be p2pool switching starting up.
    I can see the advantage of the shorter share period of p2pool, which I was critical of, will now come into play. Looks like they need to push it back up once a day? as it had rolled down past 0.0036 from 0.0052 last night, the total hash has increased back up.


  • Moderators | Tip Wellenreiter

    It’s relatively easy to build a coin switching pool with p2pool as long as you switch between Neoscrypt coins.

    But I assume, that somebody builds a small private p2pool cloud, mines at low share difficulty and then connects to the public pool cloud. Then the shares mined in privacy are added to the pools hash rate and payed as any other shares submitted.
    I also noticed, that the pool in question is rebooted every day or even more often, what fits to my theory.


  • 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 …

    https://www.nicehash.com/?p=multialgo


  • 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 …

    https://github.com/p2pool/p2pool/issues/294


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