Bitcoin Forum

Current difficulty is at 55 589.518126. What is this a measure of? Is this directly related to the # of leading zeros in the SHA256 block hash we are working on? How is it possible to adjust difficulty only marginally every 2016 blocks?

 

https://en.bitcoin.it/wiki/Difficulty

Is there somewhere where I can see difficulty history? The following link is dead -

http://nullvoid.org/bitcoin/difficultiez.php

I found it in google's cache, but it stopped at Block 106848.

Try sipa's graphs at:
http://bitcoin.sipa.be/

I added sipa's graphs to wiki page about difficulty.

The difficult is a multiple of the minimum difficulty level, which is just an arbitrary 64 bit binary integer that the hash must be less than to qualify.  The leading zeros thing is an approximatation of the method, but not entirely accurate.  If the clients were just counting leading zeros, then the difficulty could only increase as a log of 2 ( each additional leading zero doubles the difficulty).  Basicly, the 'target' is a 64 bit integer that the binary interpretation of the sha-256 hash must be less than, and the target number is adjusted up or down by a process similar to a 'fuzzy logic' type of system; always seeking it's balance.  In this case, the balance point is 6 block per hour, and every two weeks or so, the system makes a calculated guess as to how much the target must be raised or lowered based upon the average blocks per hour seen during the prior two week span.  All of the clients make this calculation independently, but because it's a deterministic calculation based upon a shared set of data, they all come up with the same answer.  The clients don't use the 'difficulty' at all, but use only the 'target'.   The 'difficulty' is just a metric devised to allow us humans to make sense of it all, because for us to look at the targets, it would be difficult for us to draw useful information from the target or it's changes over time.  Since the difficulty is expressed as a ratio (number of times more unlikely for a given hashing attempt will produce a hash below the target) it makes it easier for humans to look at the difficulty number and prior difficulty numbers and derive useful meaning from it.

http://blockexplorer.com/q/nethash

Is that actually right, or do all clients use the new difficulty that was calculated by the node that generated the first block at that new difficulty?

In the latter case, different nodes could calculate slightly different difficulty-adjustments due to lack of perfect time synchronization, but only the "winning" node's calculation is used going forwards.

I manually maintain a table from that source:
https://spreadsheets.google.com/pub?hl=en&hl=en&key=0AmcTCtjBoRWUdHVRMHpqWUJValI1RlZiaEtCT1RrQmc

That would be really insecure. All nodes calculate it independently. All nodes use the same time, which is based upon block timestamps.

Actually, I'm not positive, but my own understanding was that all generating nodes calculate this independently.  Whatever differences that could exist would be very small, not likely to cause rejections.

Yep. The algorithm is actually pretty simple. The goal is to generate 2016 blocks in two weeks, so to calculate the next difficulty:
- Calculate the actual timespan time taken to create the last 2016 blocks: subtract the timestamp in block N-2016 from the timestamp in block N (where N is the highest block number)
- Calculate the new difficulty as: current difficulty * actual timespan / target timespan

I the actual timespan is longer than two weeks, the difficulty for the next two weeks will be lower. If the actual time span is less than two weeks, the difficulty for the next two weeks will be higher.

The block finder provides the timestamp? I remember hearing about some rough restrictions on acceptable times relative to other blocks. Is there enough play to allow exploitation by a miner who preferred difficulty to be a little lower.

They could modify it somewhat. The timestamp must be greater than the median of the last 11 blocks and not more than two hours in the future (according to network-adjusted node time).