In the OP, I suggested an experiment. What's the smallest hash (highest value hash) we've ever found? How many hashes have we found with that value? My prediction is that we've found exactly one hash with that highest value. I finally learned to parse blockchain data, and as it turns out, my prediction was spot on.
The smallest hash we've ever found (as of block #188529) is
00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d. This hash has 67 leading zero bits. The next smallest hash has only 66 zero bits.
I would have predicted there should be two hashes with 66 zero bits, but in fact, there have been five:
http://blockchain.info/block-height/137445http://blockchain.info/block-height/140105http://blockchain.info/block-height/148246http://blockchain.info/block-height/156636http://blockchain.info/block-height/156980I mentioned that this way of looking at hash values leads to a scale-invariant way of measuring time. Let me illustrate this with a couple of graphs.
First, these are the hash values (256 - log2(hash)) as a function of time, the way we normally measure it - in blocks (each block corresponds to roughly 10 minutes). The red line at the bottom represents the difficulty, i.e., the minimum acceptable hash value. You can compare this red line with mndrix's (dated)
chart of log-difficulty over time.
To visualize the scale-invariant properties I'm so excited about, look what happens when we plot the hash values against the
cumulative difficulty, (i.e.,
total work). This is also equal to the
expected total number of hashes computed.
The key things to notice about this graph are:
- The density of points decreases exponentially as you go higher.
If you split the data into rows, then each row contains half as many points as the row below it.
- The density of points is independent of the position along the x-axis.
- The density of points is independent of the shape of the red difficulty line (except for the fact there's no data below it).
- The x-coordinate of each point is uniform random within the entire interval.
Cumulative difficulty, not block-height, is the true way we measure time in Bitcoin. It's a lovely mechanism, and the fact it has these qualities gives me hope that a future incarnation won't need any hard-coded time parameters. A great way of partitioning/subdividing time is to sample according to the hash values. Right off the bat, there are two time periods - the time before the 67-bit block, and the time after the 67-bit block. Within each interval, you can subdivide according to the 66-bit blocks, and then the 65-bit blocks, and so on.
(Here's
the code I wrote to prepare these illustrations)