New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from Jan 31, 2012

Conversation

Projects
None yet
5 participants
@gavinandresen
Contributor

gavinandresen commented Dec 5, 2011

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)

@TheBlueMatt

View changes

Show outdated Hide outdated src/main.cpp Outdated
@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 7, 2011

Contributor

Other than that one concern, ACK

Contributor

TheBlueMatt commented Dec 7, 2011

Other than that one concern, ACK

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Dec 7, 2011

Member

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

Member

luke-jr commented Dec 7, 2011

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

@gavinandresen

This comment has been minimized.

Show comment
Hide comment
@gavinandresen

gavinandresen Dec 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?

Contributor

gavinandresen commented Dec 8, 2011

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

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Dec 8, 2011

Contributor

mmm, fair enough

Contributor

TheBlueMatt commented Dec 8, 2011

mmm, fair enough

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Dec 8, 2011

Member

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

Member

luke-jr commented Dec 8, 2011

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

@coblee

View changes

Show outdated Hide outdated src/main.cpp Outdated
@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Dec 8, 2011

Member

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

Member

luke-jr commented Dec 8, 2011

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

@gavinandresen

This comment has been minimized.

Show comment
Hide comment
@gavinandresen

gavinandresen Dec 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.

Contributor

gavinandresen commented Dec 9, 2011

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

This comment has been minimized.

Show comment
Hide comment
@gavinandresen

gavinandresen Dec 15, 2011

Contributor

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

Contributor

gavinandresen commented Dec 15, 2011

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

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jan 11, 2012

Member

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

Member

luke-jr commented Jan 11, 2012

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

// Testnet has min-difficulty blocks
// after nTargetSpacing*2 time between blocks:
if (fTestNet && nTime > nTargetSpacing*2)
return bnProofOfWorkLimit.GetCompact();

This comment has been minimized.

@laanwj

laanwj Jan 11, 2012

Member

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

@laanwj

laanwj Jan 11, 2012

Member

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

This comment has been minimized.

@gavinandresen

gavinandresen Jan 12, 2012

Contributor

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

@gavinandresen

gavinandresen Jan 12, 2012

Contributor

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

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.

@gavinandresen gavinandresen merged commit c52296a into bitcoin:master Jan 31, 2012

jpentland pushed a commit to jpentland/bitcoin that referenced this pull request Feb 7, 2016

ptschip pushed a commit to ptschip/bitcoin that referenced this pull request Jul 11, 2017

Merge pull request bitcoin#686 from ptschip/release_headers
[Backport to Release PR#685] Do not continue if header will not connect
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment