19

The attack allows a group of miners with more than 50% of the network's computational power to change difficulty arbitrarily. When difficulty is adjusted, only the times of the first and last blocks in a retarget period (i.e., the first and last blocks with a certain difficulty) are considered. This attack works by manipulating the timestamp of one of these ...


11

I suppose the only right answer is "because that's how Satoshi implemented it". His reasons for doing may have included easy of implementation, easy to guarantee consistency among nodes, or little worry about instability of correction algorithms.


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


5

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


4

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.


3

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() - ...


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

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


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


2

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


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

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

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

Retargeting on every block would result in ridiculous oscillation in the difficulty level when there's a hot streak and several blocks are found in short succession or a cold streak where a block isn't found for a long period. As for why it's 2016, at an average rate of 1 block per 10 minutes, it readjusts fortnightly. Why 10 minutes was picked is unknown, ...


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

A node will recalculate the difficulty itself every 2016 blocks, and it does so in a deterministic fashion, based upon the previous 2016 blocks. So each node will, given the same 2016 previous blocks, arrive at the same result for the new network difficulty. We know that all the nodes will indeed have the same 2016 previous blocks, since the network ...


1

The target recalculation is not something that is broadcast or something that is announced to nodes. Rather nodes calculate the targets for each block according to a specific algorithm that only requires the blockchain data. It is based on the previous block's target, the block height, and the block timestamps. So each block's target is done completely ...


1

Yes, an attacker could spoof the timestamps on the block and create a covert alternative history. However, this doesn't make much of a difference in this attack. The reason is that, if the attacker chooses to manipulate timestamps to increase the difficulty, then they will end up producing fewer, in count, high-difficulty blocks. On the other hand, if they ...


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.


1

I believe the answer is an emphatic YES, but just after a block has been found I would not immediately start applying the function-of-time difficulty reduction. I believe that would not be desirable, because mining is a random process. One should allow for the natural variability of the process before judging it to be "out of balance" and needing extra-...


1

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


1

What I am trying to figure out is, assuming we have a miner that has 50% of computational power, will the difficulty value change so that miner still finds a block in 10 minutes? The difficulty value will change so that a block is found, on average, every ten minutes. If that is the case, won't that difficulty value be too high for the miners that have ...


1

No, According to the Bitcoin Wiki, the difficulty is only adjusted every 2016 blocks. The difficulty of the mathematical problem is automatically adjusted by the network, such that it targets a goal of solving an average of 6 blocks per hour. Every 2016 blocks (solved in about two weeks), all Bitcoin clients compare the actual number created with this ...


1

Albert's link shows the "emergency difficulty adjustment" code. The basic 2016-block difficulty adjustment is defined in chainparams.cpp: consensus.nPowTargetTimespan = 14 * 24 * 60 * 60; This is the desired time in seconds between difficulty adjustments. You can also see below where they hardcode the corresponding number of blocks: consensus....


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