Bitcoin Difficulty Adjustment – All the resources on the internet

/ Alex Waltz

This is all the material I read in preparation for making this thread.
I am pretty sure there was nothing on the internet on the topic that is not on this list.


This is organized by topic, and in some places, I took notes of things I considered relevant or worth mentioning.
The whole point of this was to organize the links in a way i can find them after i closed all the 1000 tabs i had opened.

· Difficulty – Explanations

· Bitcoin.it wiki

Difficulty stored in blocks

Each block stores a packed representation (called “Bits”) for its actual hexadecimal . The target can be derived from it via a predefined formula. For example, if the packed target in the block is 0x1b0404cb (stored in little-endian order: cb 04 04 1b), the hexadecimal target is

0x0404cb * 2*(8(0x1b – 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

What is the minimum difficulty?

  • The minimum difficulty, when the target is at the maximum allowed value, is 1.

The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks
Time is in the blocks
f the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty is in proportion to the amount of time over or under two weeks the previous 2016 blocks took to find.

For example, using Python we calculate the average time to generate a block using a 1Ghash/s mining rig when the difficulty is 20000:
$ python -c "print 20000 * 2**32 / 10**9 / 60 / 60.0" 23.85

· In-depth explanation of Bitcoin Mining Difficulty

Target (or bits): The target states how low a block hash must be in order to fulfill the mining condition

Difficulty: This is a numerical expression of how difficult it is to find a valid hash compared to the easiest difficulty of 1
For individuals, the difficulty value is more comfortable to interpret than the target

A difficulty of 6,000,000 means it takes 6,000,000 times more tries (on average) to find a valid hash than with the easiest difficulty of 1.

This means, the higher the target, the lower is the difficulty.

To make the difficulty target forgery-proof, it is part of the block header and serves as the input value of the SHA256 hash function during mining.

new difficulty = current difficulty * expected time / actual time

To prevent large changes in the difficulty, a single retarget doesn’t change the new target by more than a factor of 4 in either way.

Has target calculator

· Gregs post on Difficulty

· Target – Explanations

· Target Bitcoin.it wiki

The target is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 hash of a block’s header must be lower than or equal to the current target for the block to be accepted by the network. The lower the target, the more difficult it is to generate a block.

Every 2016 blocks (which should take two weeks if this goal is kept perfectly), every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference.

A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.

· Gregs explanation on Target

· Pieter Wullie explains target ~ difficulty

· How is nBits converted to target

· Off by 1 error

· r/btc post

That spans an amount of time spent mining 2015 blocks.

Think of it this way: today’s date minus yesterday’s date is one day worth of time.
The iteration goes back 2014 blocks, not 2015 (nInterval-1 == 2015, notice that i must be less than 2015 for the for-block to execute). So, we end up comparing timestamps of blocks 2015 blocks apart.

You’re right on all your loop calculations. It ends up being pIndexFirst = pIndexLast – 2015, as you say.

pindexFirst = pindexLast-2015. This is a span of 2016 blocks.

No, it’s quite clearly a span of time spent mining 2015 blocks. You’re making the mistake of calling it a span of 2016 because if you count the first index, all the ones in between, and the last index, you have 2016 indices. But the time between first and last index is 2015 blocks worth of time.

What you’re not understanding is that, after the loop, we have two block indices that are 2015 blocks apart. It then measures the time between them, which is the time spent mining 2015 blocks.

I’m not sure how to make this clearer…maybe something like this:

Imagine we execute a similar loop to walk back from the current time 10 days (loop subtracts one day 10 times).

So our current time is (Nov 22 at whatever local time), and after 10 iterations our past time is (Nov 12 at whatever local time). This is a span of 10 days (equal to the amount of loop iterations). It’s not a span of 11 days, even though there are 11 day numbers if you look at it like this: [10th, 11th, 12th, 13th, 14th, 15th, 16th, 17th, 18th, 19th, 20th, 21st, 22nd]. The fact remains that the code is interested in the time between the two endpoints, not the number of indices.

· SE explanation

· Code snipets

· Satoshi

· Currently

· Not actually 10 minutes

· Rusty blog

 There are 2015 spaces between 2016 blocks, but the code divides by 2016.
 
 I’m sure no one else cares about that 0.3 second mistake, since block times are never that precise anyway.

· Russell O’Connor why it takes 20 minutes

· Meni’s paper

Specifically, if the difficulty is D, the probability for a hash to be a block is 1/ 2^32 * D

More precisely, it is 2^16 − 1 /2^48 x D
We will ignore this distinction

This means that if the network hashrate is H, the rate at which blocks are found is H / 2^32 x D

· zawy – Correction to diff algo

· Pieter’s thread

· Pieter’s Gist

· Time warp attack

· Gmax post on mailinglist

· People talking about TWA

· The Van Wirdum Sjorsnado: The Time-Warp Soft Fork

A new block may not be more than 2 hours in the future

the off by one comes because you dont compare last block of each period

Rule for the past
The block has to be at least 1 second more the medial of last 11 blocks.

Matt corello added 600 seconds constraint

block time is 10 minutes and 0.6seconds

600.6 seconds

We can use this for scaling.

We can “attack” the blockchain to get it to the correct 600 seconds block time.

· BIP clean up consensus

· ArtFotrz explanation

· Lopp’s article

· Harding – SE explanation

· Thymos – SE explanation

Brings up that you can mess the medians even with ~30% hash rate

· Time jacking article 2011

· Time jacking BT thread 2011

· Mailing list post by zawy ’18

· Satoshi wanted to implement NTP

· Talk about using NTP in bitcoin

Mike Hearn thinks is ok, other people dont.

· The verge hack explained

Given the unpredictable variance in the time it takes for data to propagate through the peer-to-peer network, it’s entirely possible for block times to appear “out of order,” even when all parties are being perfectly honest.

· Stack exchange question Verge vs Bitcoin

quote

Reality, however, often has a way of stubbornly refusing to conform to the axioms of free market economics.

· Bitcoin’s Block Timestamp Protection Rules

As far as we know, these time protection rules existed since Bitcoin launched in 2009. When designing the system, Satoshi had to innovate at least three layers deep:

Proof of work system → Difficulty adjustment system → Robust time protection rules

While this may not seem especially ingenious to us now, we have had almost 11 years’ experience with such systems. That Satoshi had thought all this through before any such network existed is quite remarkable, in our view.

Median Past Time (MPT) Rule – The timestamp must be further forwards than the median of the last eleven blocks. The median of eleven blocks implies six blocks could be re-organised and time would still not move backwards, which one can argue is reasonably consistent with the example, provided in Meni Rosenfeld’s 2012 paper, that six confirmations are necessary to decrease the probability of success below 0.1%, for an attacker with 10% of the network hashrate.

Future Block Time Rule – The timestamp cannot be more than 2 hours in the future based on the MAX_FUTURE_BLOCK_TIME constant, relative to the median time from the node’s peers. The maximum allowed gap between the time provided by the nodes and the local system clock is 90 minutes, another safeguard. It should be noted that unlike the MPT rule above, this is not a full consensus rule. Blocks with a timestamp too far in the future are not invalid, they can become valid as time moves forwards.

· Why 2016 – Gmax answer

We don’t know the hash rate we just know how fas blocks are generated.

The difficulty is known.

Smaller sample size would have more noise when calculating hashrate –

Isolating attacks.
Currently i would have to isolate you for 2016 blocks

Overlapping updates also have some mathematical/implementation complication– because each block is at a different difficulty

There is also a related exotic attack: Did you know that in bitcoin an attacker which maintains any constant fraction of the networks hashrate, no matter how small (e.g. 0.000001% it just has to scale with the network) will eventually overtake the honest chain if he attacks long enough?

The 4x/0.25x difficulty change rule is also another complication. Any non-linearity in the rules opens up strategic behavior:

Difficult is fundamentally a security mechanism

· Why factor of 4

· Peter Todd

The Bitcoin protocol limits the rate at which the difficulty can decrease to no less than 1/4th of the prior period’s difficulty per adjustment period.

Code that restricts this

· SE answer

· Mining Incentives – Part 1 – The Economics of the Difficulty Adjustment

If more than 2016 blocks were mined in a two week period, mining becomes more difficult, such that if the hashrate remains constant,

The maximum adjustment in any one period is a factor of 4 (i.e. a range of 25% to 400% of the old difficulty).

What the difficulty adjustment may mean is that the profit margins of the most marginal miner quickly tend to zero.

· Chain work stakc exchange

Antonie also explain how chain work is actually calculated.

The chainwork value is really just the total amount of work in the chain.

log2_work

https://bitcoin.stackexchange.com/questions/37268/parameters-in-updatetip-calculation-of-log2-work

· I calculated what chance does a single hash has of being valid.

· Satoshi makes post about difficulty changes

Leave a Reply