Miners work together to keep the difficulty low

[Bobcat]

I have been monitor the difficulty for the past few weeks thru allchains.info and I noticed that the dif change base on the total GH on the btc network

Two week ago: total btc GH ~7000+ and the the est next dif about  -5%
Last week: total btc GH ~ 8000 and the est next dif about  +2%
This week: total btc GH ~10000+ and the est next dif about  +26%  which is about 1464931.53474


As you can see the more GH in the network increase the more dif will increase till the next cycle in (1d 20hr). So I am thinking if miners stop mining an hour or two before the the next cycle start, it will drop the GH that and the dif will drop and remain for another 10 day till the next cycle start again, Once the dif drop and miner can start mine again.

I dont know how the calculation work of the dif change, but so far base on what i have seen if we can maintain the GH around 7000-8000 before the dif change cycle then the dif should stay around 1 milllion.

What do you guys think ?

[DeepBit]

So I am thinking if miners stop mining an hour or two before the the next cycle start, it will drop the GH that and the dif will drop and remain for another 10 day till the next cycle start again, Once the dif drop and miner can start mine again.

I wonder why so many people think of this method.
1. No, miner's won't stop mining.
2. An hour or two won't make difference because measurement window is 2 weeks.

[DeathAndTaxes]

Even assuming you could get all miners to agree (which you can't) why would I want to lose 1 hour of revenue?
Even if it cost me nothing I wouldn't try and halt all economic activity for a couple hours.

I dont know how the calculation work of the dif change, but so far base on what i have seen if we can maintain the GH around 7000-8000 before the dif change cycle then the dif should stay around 1 milllion.

Difficulty change is based on the how long it took to complete the last 2016 blocks.  On average it will take 20,160 minutes or 336 hours.  If it takes less then difficulty rises by the amount necessary to increase time to 20,160 minutes.  If it takes more time then difficulty falls by the amount necessary to reduce time to 20,160 minutes.

[Bobcat]

Even assuming you could get all miners to agree (which you can't) why would I want to lose 1 hour of revenue?
Even if it cost me nothing I wouldn't try and halt all economic activity for a couple hours.

I dont know how the calculation work of the dif change, but so far base on what i have seen if we can maintain the GH around 7000-8000 before the dif change cycle then the dif should stay around 1 milllion.

Difficulty change is based on the how long it took to complete the last 2016 blocks.  On average it will take 20,160 minutes or 336 hours.  If it takes less then difficulty rises by the amount necessary to increase time to 20,160 minutes.  If it takes more time then difficulty falls by the amount necessary to reduce time to 20,160 minutes.

Yes your explaination make sense.
Obviously, I not clear how the dif calculation work, I thought when the dif change it looks at the current network hash rate then do its calculation.

[DeathAndTaxes]

Even assuming you could get all miners to agree (which you can't) why would I want to lose 1 hour of revenue?
Even if it cost me nothing I wouldn't try and halt all economic activity for a couple hours.

I dont know how the calculation work of the dif change, but so far base on what i have seen if we can maintain the GH around 7000-8000 before the dif change cycle then the dif should stay around 1 milllion.

Difficulty change is based on the how long it took to complete the last 2016 blocks.  On average it will take 20,160 minutes or 336 hours.  If it takes less then difficulty rises by the amount necessary to increase time to 20,160 minutes.  If it takes more time then difficulty falls by the amount necessary to reduce time to 20,160 minutes.

Yes your explaination make sense.
Obviously, I not clear how the dif calculation work, I thought when the dif change it looks at the current network hash rate then do its calculation.

Yeah you got to watch those online difficulty estimators.  They are simply guestimating what the difficulty will be based on historical hashrate and projecting out current hashrate.  Also remember hashrate is not known.  Estimators are using prior block times to make an estimate of the hashrate.  So if the network gets "lucky" and solves 5 blocks 10% quicker than normal the estimators will think the network has a 10% higher hashrate.

I have found this estimator (namecoin & bitcoin) to be one of the best.
http://dot-bit.org/tools/nextDifficulty.php

Looks like it is predicting a 8% rise in difficulty to ~1.25M

[gmaxwell]

I dont know how the calculation work of the dif change, but so far base on what i have seen if we can maintain the GH around 7000-8000 before the dif change cycle then the dif should stay around 1 milllion.

What do you guys think ?

The difficulty algorithm is linear (well, except for the clamps at 1/4 and 4x). Assuming constant mining power, this means speedup next cycle plus the slowdown on the cycle after it would only match the work not done on this cycle. You come out the same.  And someone defecting from the voluntary slowdown would make more (they'd still get the benefit of whatever shift the slowdown did achieve, plus they'd mine during the 'down' time).

[sharky112065]

I have been monitor the difficulty for the past few weeks thru allchains.info and I noticed that the dif change base on the total GH on the btc network

Two week ago: total btc GH ~7000+ and the the est next dif about  -5%
Last week: total btc GH ~ 8000 and the est next dif about  +2%
This week: total btc GH ~10000+ and the est next dif about  +26%  which is about 1464931.53474


As you can see the more GH in the network increase the more dif will increase till the next cycle in (1d 20hr). So I am thinking if miners stop mining an hour or two before the the next cycle start, it will drop the GH that and the dif will drop and remain for another 10 day till the next cycle start again, Once the dif drop and miner can start mine again.

I dont know how the calculation work of the dif change, but so far base on what i have seen if we can maintain the GH around 7000-8000 before the dif change cycle then the dif should stay around 1 milllion.

What do you guys think ?

The difficulty increase will not be +26%. Allchains.info was reset so, the displayed increase will not be what we will see when it actually increases.

[Costia]

I dont know how the calculation work of the dif change, but so far base on what i have seen if we can maintain the GH around 7000-8000 before the dif change cycle then the dif should stay around 1 milllion.

What do you guys think ?

The difficulty algorithm is linear (well, except for the clamps at 1/4 and 4x). Assuming constant mining power, this means speedup next cycle plus the slowdown on the cycle after it would only match the work not done on this cycle. You come out the same.  And someone defecting from the voluntary slowdown would make more (they'd still get the benefit of whatever shift the slowdown did achieve, plus they'd mine during the 'down' time).

but you can hop chain blocks and make money mining an alt coin while waiting for the bitcoin difficulty to drop for 2 weeks
the main problem is coordination between miners - but if a few of the largest pools unite they might actually be able to do that
But i am still not sure if its profitable
if the hashrate drops to 1THash/sec for 2 weeks, will the difficulty drop by a factor of the for the whole next 2 weeks? i.e. will a block will be generated every minute for 2 weeks if a day after the difficulty change the hashrate jumps to 10Thash/s? (meaning a step function is not linear)

[Costia]

What I was/am missing is the formula that says how the next target is calculated.
I tried the wiki but didnt find it
did you take the calculation from the source code?

[Meni Rosenfeld]

What I was/am missing is the formula that says how the next target is calculated.
I tried the wiki but didnt find it
did you take the calculation from the source code?

N = New difficulty (at block 2016N)
O = Old difficulty
T2 = timestamp of block 2016N - 1
T1 = timestamp of block 2016N - 2016
N = O * (2 weeks) / (T2-T1)

Of course, in actuality the calculation is based on target, new target = old * (T2-T1) / (2 weeks) and the difficulty derives from it. I didn't see the code for this but I'm guessing first an integer division by 1209600 (seconds in two weeks) is done and then the multiplication. There's also the [1/4, 4] limit.

There's actually a bug in this calculation, it should have used T1 = timestamp of block 2016N - 2017, and this bug makes possible a form of attack. But at this point it is considered not worth correcting it.

It's supposed to be explained at https://en.bitcoin.it/wiki/Difficulty#What_network_hash_rate_results_in_a_given_difficulty.3F but maybe it's not very explicit. Also see http://bitcoin.stackexchange.com/questions/855/what-keeps-the-average-block-time-at-10-minutes.

EDIT: Here's the relevant piece of code (from main.cpp). It appears the bignum used can handle doing the multiplication first and then division:

Code:

static const int64 nTargetTimespan = 14 * 24 * 60 * 60; // two weeks
static const int64 nTargetSpacing = 10 * 60;
static const int64 nInterval = nTargetTimespan / nTargetSpacing;

...

    // Go back by what we want to be 14 days worth of blocks
    const CBlockIndex* pindexFirst = pindexLast;
    for (int i = 0; pindexFirst && i < nInterval-1; 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;

[Costia]

thanks.
so this is impossible
the decay is much slower than the rising of the difficulty

I cant think of an attack that can exploit the -2016 instead of -2017, its just a 1 block index
since the actual rate is random there always might be shared blocks in 2 adjacent 2 week estimates
there are way more than 2017 blocks - so no negative numbers\overflows
If an attack wanted to delay a block it wont matter much either
I would actually move it 120 blocks back to -121 and -2137 - so only confirmed blocks are used
only thing is if the total hashrate is constant - the difficulty will slowly drift up(?)

[film2240]

I'd like to see difficulty drop again soon unless someone can help me reach above 400MHash/s on my HD6950 to eek out the most performance out of it (probably best to direct me to a thread that covers this already).

I think that we should work together to force difficulty to drop again when the trends show rises in difficulty.

[DeathAndTaxes]

I'd like to see difficulty drop again soon unless someone can help me reach above 400MHash/s on my HD6950 to eek out the most performance out of it (probably best to direct me to a thread that covers this already).

I think that we should work together to force difficulty to drop again when the trends show rises in difficulty.

There is no working together.  We all share the same pie.  If you drop out well that is a bigger slice for me.

Gimmicks and half baked ideas of "cheating" the protocol don't address the reality that mining is a zero sum competitive game.

[Meni Rosenfeld]

I'd like to see difficulty drop again soon unless someone can help me reach above 400MHash/s on my HD6950 to eek out the most performance out of it (probably best to direct me to a thread that covers this already).

I think that we should work together to force difficulty to drop again when the trends show rises in difficulty.

There is no working together.  We all share the same pie.  If you drop out well that is a bigger slice for me.

Gimmicks and half baked ideas of "cheating" the protocol don't address the reality that mining is a zero sum competitive game.

I don't know why I didn't mention this earlier given the topic of the OP. But the attack that involves the off-by-one bug in the difficulty adjustment is one where someone with >50% of the hashrate can mess with the timestamps to artificially decrease the difficulty, so instead of generating the total prescribed 7200 BTC per day, they are generated much more rapidly. So if all miners collude, they can game the system to increase the pie.

But you wouldn't do that, right?

See also ArtForz's original post about the attack and this StackExchange question.

[Brunic]

I'd like to see difficulty drop again soon unless someone can help me reach above 400MHash/s on my HD6950 to eek out the most performance out of it (probably best to direct me to a thread that covers this already).

400 MHash? You're going to kill your card. I've got 6 of them, and the max I went was 380 MHash before I was afraid of blowing it up.

I think that we should work together to force difficulty to drop again when the trends show rises in difficulty.

The only way to drop it is to quit the market. If you find a way to convince miners who invested thousand of dollars in mining equipment to quit the market, go for it.