Tag Info

Hot answers tagged difficulty-retargetting

18

Meni's answer is good. I just want to give some practical detail method about difficulty calculation, perhaps helpful for future views of this question's answer. Let's take a look at Satoshi's genesis block header (part of related info): \$ bitcoin-cli getblockhash 0 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f \$ bitcoin-cli ...

16

Contrary to popular belief, the target is not actually based on the number of leading zeroes. This is a major simplification that is used to get the general idea across, but is not actually how the code works. Instead, the target is just a number that is adjusted by the ratio between the actual time between blocks and the expected time between blocks (with ...

14

As Andrew's answer points out, the 'number of leading zeros' is just a simplification, so I thought I would give an example to more concretely illustrate this: Block hashes are usually represented in hex format, which utilizes the character set [0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f]. But for simplicity, we can just use a base 10 number set [0,1,2,3,4,5,6,7,8,9], ...

11

They aren't really necessary. The reason that they are included can only be known by Satoshi, and AFAIK, he did not state why he chose to include nBits in the block header (or many other things that are just arbitrary). This is one of the many things that Satoshi chose to do and no one really knows why. It remains in the block header today because removing ...

7

How strict are the time validation rules? Very. If the next block is mined more than 2 hours after the current block, would this not stall the blockchain? No. It doesn't break the rule "Full nodes will not accept blocks with headers more than two hours in the future according to their clock." Nor does it break the rule "Must be strictly ...

6

Yes, there is a risk with adjusting the difficulty every block. It entirely depends on the method of adjusting. With how Bitcoin does it, if you adjusted every block, the difficulty would vary wildly due to the variance in times between blocks. However other algorithms for determining the difficulty may be able to account for that. Adjusting every 2 weeks ...

6

The original bitcoin adjusted difficulty every 2016 blocks, which would nominally be 14 days @ 6 blocks per hour. The 238th such adjustment is due at block 479,808, and we are presently (early 4 Aug 2017) at 478,620 or 1188 blocks away on BCC. I assume the original adjustment interval has not been changed. 35 blocks were generated in the last 24 hours, so ...

6

I think you have a misconception about what this clause means: Full nodes will not accept blocks with headers more than two hours in the future according to their clock. You appear to be interpreting this as, if a new block is more than two hours later than the previous block, then do not accept it. That is incorrect. This clause is not about gaps in time ...

5

The update frequency results in some trade-offs. Faster updates increase the exposure to isolation attacks-- where a partitioned part of the network speeds back up to the nominal speed. Faster updates also increase the amount of oscillation possible. On the plus side they make the network respond faster to changes. Many altcoins have changed to faster ...

5

I would like to give my 2 cents here, by expliciting the relationship between the probability of mining a block given the current target t and the corresponding difficulty d as it is calculated in bitcoin core. So cryptographic hash functions are idealized by the random oracle abstraction [https://en.wikipedia.org/wiki/Random_oracle]. We can therefore model ...

5

Directly committing to the nbits allows you to determine how much work was used to produce the header statelessly before looking for (or fetching) information about prior headers. This can help fend of DOS attacks sending junk headers to force you to do work determining or fetching their ancestors.

4

The function is CalculateNextWorkRequired in pow.cpp L#49: unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params) { if (params.fPowNoRetargeting) return pindexLast->nBits; // Limit adjustment step int64_t nActualTimespan = pindexLast->GetBlockTime() - ...

4

I think the question isn't so much whether this is possible, but whether this is desirable. The block rate limit has several functions: Keeping the stale block rate low, so that the effort a collusion attacker has to do is not much higher than honest miners (per block). Keeping validation on non-mining full nodes feasible. The second of these goals is ...

3

If the maximum target was 2256-1, every candidate block would be a valid block. As even the CPU miner in Bitcoin's first software release was capable of doing 100 kH/s or more, this would have led to a very rough start of the chain, with 1000s of blocks produced per second until the difficulty adjusted. Because of that reason, the maximum target was ...

3

nullc answered this on Reddit. Adjusting every block (or faster in general) increases user's vulnerability to isolating attacks. Say I manage to isolate your node so that it's only talking to my node -- not a particularly hard attack. Then using some mining hashpower (perhaps that I've also isolated-- which is harder, or I'm paying for myself) I mine blocks ...

3

The first rule is well understood. The second rule, ensures that difficulty gets readjusted quicker if the MTP between blocks is big (12h.) In practice: Check the MTP of the current block (mining time of a block 6 blocks earlier) compare to the MTP time of a block mind 6 blocks earlier if the difference is 12 hours then difficulty will reset for example: ...

3

No, it is because those are unrelated values. The number of miners (more preciselly the cumulative hash power) influences the security of the network, but not the speed of mining the blocks (in long term). In short term (within the current window of 2016 blocks), it can influence the block generation speed, but after the window completes, difficulty retarget ...

3

For a good portion of its history the bitcoin network has seen continuous increases in difficulty, which warps the average block time to be below 10 minutes until the next difficulty adjustment. If the reverse were true the block time would be longer in kind. This latency serves to protect nodes against isolation attacks where you could otherwise ...

3

The difficulty is actually represented by the target threshold encoded in the nBits value in the block header. Where difficulty represents the human readable representation ("how often do we need to try to find a solution"), the target threshold defines the prefix a block must undershoot in order to be valid. This means that the 256-bit block hash ...

2

The difficulty adjustment algorithm is as follows (from the source code): unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params) { if (params.fPowNoRetargeting) return pindexLast->nBits; // Limit adjustment step int64_t nActualTimespan = pindexLast->...

2

The target is a number which the hash of a block header must be less than or equal to in order for that block to be considered valid. This target number, when represented as a 256 bit number, has several leading zeros. The actual number of leading zeros is irrelevant and doesn't matter to anything, but us humans talk about the number of leading zeros as a ...

2

It's a security property that the difficulty is not retargeted quickly, not a technical or design limitation. It prevents a case where you can isolate a node, or a portion of the network, wait a brief period, and then mine at a vastly lower difficulty in order to defraud those users. If the mining rate drops, the fees rise, and more miners are incentivized ...

2

In brief with hindsight: It's a mistake. You have to keep in mind that Bitcoin is the very first Cryptocurrency. It has all the legacy designs and did not anticipate every possible problem. This includes the block-size, which initiated the huge Bitcoin 2x fork debate. And btw, it's not every 2 weeks. Bitcoin has no means of calculating time accurately ...

2

I understand that as the bitcoin difficulty adjustment becomes harder the hash output will require more 0s in the beginning of the hash. This is slightly incorrect: a higher difficulty will require a valid block hash to have more leading zeros, but validity is not determined by counting the number of zeros. Rather, it is determined by comparing the value of ...

2

The retargeting every 2016 blocks is computed as follows: previous_target * (T2-T1) / (20160 minutes) Where: T2: timestamp of previous block T1: timestamp of block at current height - 2016 Target adjustment bounded to factor 4 Ignoring the target adjustment limit: For the resulting target to be zero, T2-T1 would need to equal zero. That would require an ...

2

The target is calculated by each node in the network independently. Bitcoin is a decentralized system, so there is no authority that will set the target. The network is its own authority. On this network, each participant (node) follows certain rules. These rules are the same for everyone, and govern how the network behaves. They include things such as the ...

2

I don't know a way to get this directly through the RPC without looking at multiple blocks and comparing them, but the math formula is easy: floor(current_number_of_blocks / 2016) * 2016 - 1 The floor function rounds a number down to an integer value; it's available in most programming languages, although it's sometimes named something to do with integers (...

2

as the popularity of bitcoin keeps on increasing, wouldn't more transactions take place daily? Yes, scaling of Bitcoin is a recognised issue. For people who use Bitcoin as a currency, as its creators intended, the solution is mostly off-chain payment systems such as the Lightning network. For speculators and day traders who treat Bitcoin as nothing other ...

1

Litecoin is a fork of Bitcoin Core, and uses the same difficulty adjustment period (2016 blocks), which on Litecoin is 3.5 days because the block time is 2.5 minutes instead of 10. See chainparams.cppL#85: consensus.nPowTargetTimespan = 3.5 * 24 * 60 * 60; // 3.5 days consensus.nPowTargetSpacing = 2.5 * 60;

1

2016 blocks at an expected interval of 10 minutes are exactly 14 days. Likely the window for the difficulty period and interval were picked first and 2016 resulted from that.

Only top voted, non community-wiki answers of a minimum length are eligible