how fix diff adjustment attack ?

[tseries]

How possible fix adjustment atack ?



the sample of pow code used on altcoin ( scrypt  coin based on old sources of litecoin)

main.cpp

Code:

int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 500 * COIN;

            if(nHeight == 1)
            {
            nSubsidy = 160000000 * COIN;
            }

    // Subsidy is cut in half every 840000 blocks
    nSubsidy >>= (nHeight / 840000);

    return nSubsidy + nFees;
}

static const int64 nTargetTimespan = 10 * 60;
static const int64 nTargetSpacing = 5 * 60;
static const int64 nInterval = nTargetTimespan / nTargetSpacing;

//
// minimum amount of work that could possibly be required nTime after
// minimum work required was nBase
//
unsigned int ComputeMinWork(unsigned int nBase, int64 nTime)
{
    // Testnet has min-difficulty blocks
    // after nTargetSpacing*2 time between blocks:
    if (fTestNet && nTime > nTargetSpacing*2)
        return bnProofOfWorkLimit.GetCompact();

    CBigNum bnResult;
    bnResult.SetCompact(nBase);
    while (nTime > 0 && bnResult < bnProofOfWorkLimit)
    {
        // Maximum 400% adjustment...
        bnResult *= 4;
        // ... in best-case exactly 4-times-normal target time
        nTime -= nTargetTimespan*4;
    }
    if (bnResult > bnProofOfWorkLimit)
        bnResult = bnProofOfWorkLimit;
    return bnResult.GetCompact();
}

unsigned int static GetNextWorkRequired(const CBlockIndex* pindexLast, const CBlockHeader *pblock)
{
    unsigned int nProofOfWorkLimit = bnProofOfWorkLimit.GetCompact();

    // Genesis block
    if (pindexLast == NULL)
        return nProofOfWorkLimit;

    // Only change once per interval
    if ((pindexLast->nHeight+1) % nInterval != 0)
    {
        // Special difficulty rule for testnet:
        if (fTestNet)
        {
            // If the new block's timestamp is more than 2* 10 minutes
            // then allow mining of a min-difficulty block.
            if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
                return nProofOfWorkLimit;
            else
            {
                // Return the last non-special-min-difficulty-rules-block
                const CBlockIndex* pindex = pindexLast;
                while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
                    pindex = pindex->pprev;
                return pindex->nBits;
            }
        }

        return pindexLast->nBits;
    }

    // LiteBitcoin: This fixes an issue where a 51% attack can change difficulty at will.
    // Go back the full period unless it's the first retarget after genesis. Code courtesy of Art Forz
    int blockstogoback = nInterval-1;
    if ((pindexLast->nHeight+1) != nInterval)
        blockstogoback = nInterval;

    // Go back by what we want to be 14 days worth of blocks
    const CBlockIndex* pindexFirst = pindexLast;
    for (int i = 0; pindexFirst && i < blockstogoback; i++)
        pindexFirst = pindexFirst->pprev;
    assert(pindexFirst);

    // Limit adjustment step
    int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
    printf("  nActualTimespan = %"PRI64d"  before bounds\n", nActualTimespan);
    if (nActualTimespan < nTargetTimespan/4)
        nActualTimespan = nTargetTimespan/4;
    if (nActualTimespan > nTargetTimespan*4)
        nActualTimespan = nTargetTimespan*4;

    // Retarget
    CBigNum bnNew;
    bnNew.SetCompact(pindexLast->nBits);
    bnNew *= nActualTimespan;
    bnNew /= nTargetTimespan;

    if (bnNew > bnProofOfWorkLimit)
        bnNew = bnProofOfWorkLimit;

    /// debug print
    printf("GetNextWorkRequired RETARGET\n");
    printf("nTargetTimespan = %"PRI64d"    nActualTimespan = %"PRI64d"\n", nTargetTimespan, nActualTimespan);
    printf("Before: %08x  %s\n", pindexLast->nBits, CBigNum().SetCompact(pindexLast->nBits).getuint256().ToString().c_str());
    printf("After:  %08x  %s\n", bnNew.GetCompact(), bnNew.getuint256().ToString().c_str());

    return bnNew.GetCompact();
}

bool CheckProofOfWork(uint256 hash, unsigned int nBits)
{
    CBigNum bnTarget;
    bnTarget.SetCompact(nBits);

    // Check range
    if (bnTarget <= 0 || bnTarget > bnProofOfWorkLimit)
        return error("CheckProofOfWork() : nBits below minimum work");

    // Check proof of work matches claimed amount
    if (hash > bnTarget.getuint256())
        return error("CheckProofOfWork() : hash doesn't match nBits");

    return true;
}

// Return maximum amount of blocks that other nodes claim to have
int GetNumBlocksOfPeers()
{
    return std::max(cPeerBlockCounts.median(), Checkpoints::GetTotalBlocksEstimate());
}

[bathrobehero]

I can't help you with a stuck coin but here are some thoughts:

Since every difficulty retargeting logic can only change the difficulty when a block is found, they can all be "attacked" by getting them stuck with a lot of hashrate.

This is why coins like Digibyte have multiple PoW algorithms - if one algo is stuck in a high diff, the chain can move forward by finding block with other algos.

And if an algo's diff is stuck, it should be possible that whenever a block is found with another algo, the difficulty of the algo that is stucked could be lowered. I don't know if it's the case with Digibyite or similar coins (Joincoin, Myriad, Verge, Aurora, etc).

[bathrobehero]

i find info about

 bitcoins' testnet uses a rule where difficulty drops to 1 when no block has been found for 20 min.
i can be usual to fix this bug ? end how to secure this funcion if use it for main network

i say about this

Code:

  // Only change once per interval
    if ((pindexLast->nHeight+1) % nInterval != 0)
    {
        // Special difficulty rule for testnet:
        if (fTestNet)
        {
            // If the new block's timestamp is more than 2* 10 minutes
            // then allow mining of a min-difficulty block.
            if (pblock->nTime > pindexLast->nTime + nTargetSpacing*2)
                return nProofOfWorkLimit;
            else
            {
                // Return the last non-special-min-difficulty-rules-block
                const CBlockIndex* pindex = pindexLast;
                while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit)
                    pindex = pindex->pprev;
                return pindex->nBits;
            }
        }

        return pindexLast->nBits;
    }

I can't imagine that being secure. You can set your wallet 20 minutes in the future and mine a low diff block over and over so you'll have the longest chain. But I'm not a programmer.

Your best bet is probably renting hashrate to find the next block and hope for the difficulty retarget that it lowers the diff in just the next block.

Otherwise, you have to hardfork if you want to avoid ASICs kicking the diff into the moon.

[Argon2]

If this can be done your coin is not secure. Move to a PoW Algorithm that is egalitarian.

[monsterer2]

If this can be done your coin is not secure. Move to a PoW Algorithm that is egalitarian.

any algorithm can be killed when for them create asic. It's not reason to mow to other algorithm need fix problem. If it's not fixed - even bitcoin can be killed with this.

You've created this problem for yourself by lack of understanding. Bitcoin cannot suffer from this problem, since the state of the art in ASICs is already mining on that chain.

You made the mistake of using a PoW which already had vastly accelerated mining technology on a brand new coin.

[taxmanmt5]

The reason I'm answering the question the way I am, is because he used the word attack. I don't get the full gist of what you're asking here, but I'm going to take a shot in the dark and assume that you're looking at a single minor pushing the difficulty well above the mass majority of other minors. If that is the case, they are basically shooting themselves in the foot. Well they may be the only minors that is producing any coins. the difficulty is only going to stay at the higher number while that particular person Is mining.

[fancy2973]

the code is fine, not sure what you want to fix. if the diff too high that your network is blocked, just blacklist the last block and restart from there, it's easy.

[monsterer2]

if for some reason even 30% hash rate off any coin go away the transaction stop. Cataclysm, war with china etc... Quantum computer from NSA runed for 5 second end leave network.
This problem exist , it's problem not crypto algorithm - it's problem diff algorithm !

Ok use new algoritm how you say ? but if miner's left coin ? what to do ? You dont know ? whay you write on this topic ? Test net hv function for drop diff whay it not secure  end use ?

Those are unforeseeable, end of days style events. What you have done was entirely predictable and frankly stupid. I feel sorry for the people who hold whatever coin it is you have created.

[monsterer2]

coin been adjustment do huge diff  with asic's end now i try to fix it , but cannot find any info how do this.

Ok. Kind of sounds like this has already happened from what you wrote. If it hasn't happened, you know what to do.

[monsterer2]

For anyone wondering, the coin in question is LBTC.

https://bitcointalk.org/index.php?topic=1981858.msg20340189#msg20340189

Stay clear.

[virasog]

Even if a single minor, with highly reduced resources, mine's that coin, if it eventually solves the block, then the fact that the block was solved by a minor at a smaller hashrate will eventually bring the difficulty back down. If you have any resources at all, then you can always consider renting some hash rate online, and slowly ramping it back down to where you wanted to be. If this is the case, then at least you're going to get some block rewards off of doing it.

[taxmanmt5]

The reason I'm answering the question the way I am, is because he used the word attack. I don't get the full gist of what you're asking here, but I'm going to take a shot in the dark and assume that you're looking at a single minor pushing the difficulty well above the mass majority of other minors. If that is the case, they are basically shooting themselves in the foot. Well they may be the only minors that is producing any coins. the difficulty is only going to stay at the higher number while that particular person Is mining.

but if miner's leave it's stay on huge diff  end blockchain not move transaction - what ever you say , i think it's bug end need to fix that any way .

While they might get a quick pump of money, they are quickly going to become the only bag holder, and hopefully no one's going to be buying the coin from them. The point is, if you think about a coin like Bitcoin, this technically happened with mining pools, Farms, and Asics. There were short periods of time when small isolated groups controlled most of the mining, but because of the popularity of the coin, everyone else caught up at the same technology. If this is not what you're referring to, then I really don't understand the question. but one last possible thought, let's say it's only you and a couple miners mining in your coin, and for whatever reason the difficulty has gotten much higher then the amount of effort resources anyone is putting into it.