Testnet difficulty calculation changes, to take effect Feb 15 2012 #686

gavinandresen commented at 10:03 PM on December 5, 2011: contributor

Allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. Normal rules apply every 2016 blocks, though, so there may be a very-slow-to-confirm block at the difficulty-adjustment blocks (once per month, assuming testnet is in it's normal "difficulty too high for number of people mining it" state).

This will almost certainly cause a testnet blockchain split after Jan 15. I'll update the Testnet Faucet, I'll ask theymos if he can update the testnet block explorer bitcoind.

(date slipped from Jan 1 to Feb 15)

in src/main.cpp:None in 4d056f61ec outdated

 694 | +        return nProofOfWorkLimit;
 695 |  
 696 |      // Only change once per interval
 697 |      if ((pindexLast->nHeight+1) % nInterval != 0)
 698 | +    {
 699 | +        // Special rules for testnet after 1 Jan 2012:

TheBlueMatt commented at 5:13 PM on December 7, 2011:

Why inside the interval check? If we are on the cusp of an interval, why shouldn't we allow min-diff blocks?

TheBlueMatt commented at 5:13 PM on December 7, 2011: member

Other than that one concern, ACK

luke-jr commented at 11:11 PM on December 7, 2011: member

At the same time, I propose adjusting the testnet base58 versions to match with the new proposed base58 version spec.

gavinandresen commented at 2:45 AM on December 8, 2011: contributor

RE: why keep the regular-difficulty-every-2016-blocks:

Because if you don't, and hashing power drops, then it will never adjust downward properly because the common case for non-cusp blocks is "find the last block with something other than minimum work and return its difficulty."

Example: Imagine difficulty is at 1111 before block 201600, and that block ends up taking 60 minutes to find. Imagine the normal difficulty adjustment would drop difficulty to 600.

If we allow block 201600 to have difficulty 1, then block 201601 would also be looked for at difficulty 1111, because there's no previous block with the new difficulty.

I wrote the code that way so testnet is as close to mainnet as possible; I didn't want a completely different testnet non-cusp-block calculation (yes, I COULD figure out what the last difficulty adjustment interval was and factor out the difficulty computation into yet another method... benefit doesn't seem worth the extra code complexity).

RE: adjusting testnet base58 version: okey doke. What's the right number for testnet under your scheme? 192?

TheBlueMatt commented at 2:47 AM on December 8, 2011: member

mmm, fair enough

luke-jr commented at 2:49 AM on December 8, 2011: member

Yes, 192 for testnet pubkey-addresses. 196 for testnet script-addresses (OP_EVAL).

in src/main.cpp:None in 4d056f61ec outdated

 703 | +            // then allow mining of a min-difficulty block.
 704 | +            if (pblock->nTime - pindexLast->nTime > nTargetSpacing*2)
 705 | +                return nProofOfWorkLimit;
 706 | +            else
 707 | +            {
 708 | +                // Return the last non-min-difficulty-block

coblee commented at 9:11 PM on December 8, 2011:

What if the correct difficulty for this interval is min difficulty? Wouldn't this code return something higher from a block that it finds in the previous inteval? It should probably stop at the interval change and use the difficulty there.

const CBlockIndex* pindex = pindexLast; while (pindex->pprev && pindex->nHeight % nInterval != 0 && pindex->nBits == nProofOfWorkLimit) pindex = pindex->pprev; return pindex->nBits;

luke-jr commented at 9:19 PM on December 8, 2011: member

The new anti-orphan-flood code won't break this, will it?

gavinandresen commented at 2:30 AM on December 9, 2011: contributor

coblee: Nice catch! You're right, this would prevent difficulty from ever dropping all the way down to min difficulty.

luke-jr: Nice catch! You're right, the orphan block DoS code needs to take into account this change.

I won't have time to fix this until I'm back next week.

gavinandresen commented at 9:02 PM on December 15, 2011: contributor

Code updated/rebased to fix the issues pointed out by coblee and luke-jr.

luke-jr commented at 9:34 PM on January 11, 2012: member

Is this going to be merged before 15 Jan? ;)

Testnet difficulty calculation changes, to take effect Feb 15 2012

Allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block.
Normal rules apply every 2016 blocks, though, so there may be a very-slow-to-confirm block at the difficulty-adjustment blocks.

c52296a73e

in src/main.cpp:None in 6af708f122 outdated

 668 | @@ -669,6 +669,11 @@ int64 static GetBlockValue(int nHeight, int64 nFees)
 669 |  //
 670 |  unsigned int ComputeMinWork(unsigned int nBase, int64 nTime)
 671 |  {
 672 | +    // Testnet has min-difficulty blocks
 673 | +    // after nTargetSpacing*2 time between blocks:
 674 | +    if (fTestNet && nTime > nTargetSpacing*2)
 675 | +        return bnProofOfWorkLimit.GetCompact();

laanwj commented at 10:19 PM on January 11, 2012:

I'm not sure whether this affects anything, but this does not check pblock->nTime > 1326585600 like the other one.

gavinandresen commented at 2:30 PM on January 12, 2012:

It is OK-- the code that calls ComputeMinWork call pblock->GetBlockTime() which just return pblock->nTime.

gavinandresen merged this on Jan 31, 2012

gavinandresen closed this on Jan 31, 2012

jpentland referenced this in commit c1beae6866 on Feb 7, 2016

ptschip referenced this in commit 85499f29fd on Jul 11, 2017

rajarshimaitra referenced this in commit 5104a13b34 on Aug 5, 2021

DrahtBot locked this on Sep 8, 2021