16.8 A little more on Satoshi's blocks

Recommended reading:
A new mystery about Satoshi hidden in the Bitcoin block-chain
NPW 16.7 Satoshi's hashrate

0. Introduction
One of the main comments I received (apart from typo lists - thanks for proof reading, all those who did) about yesterday's post was disappointment that I had not tackled the distribution of the nonce's least significant byte (LSB). I didn't really think it was going to be useful, but I am nothing if not a crowd pleaser.

1. Nonces, extra nonces, and least significant bytes
Think of the nonce as a continuously increasing number, which is only recorded when a block is solved, after which it resets. Since the time between blocks is an exponential random number, the nonce will also be close to an exponential random number.

Given that first few digits will tend toward an exponential distribution, the most significant byte will be a geometrically distributed random variable. The LSB should be cycling from 00 to FF and around again, and therefore should be uniformly distributed.

Sergio Demian Lerner (SDL) found that the LSB was not uniformly distributed for Satoshi's blocks, which might imply either a restricted nonce range, or that a smaller nonce was being appended with a small set of numbers.

So I asked Martin Harrigan (of QuantaBytes fame) for the data I was needed, then converted the nonces back to hex and found the least significant byte (LSB) for each one. The histograms for blocks I'd assigned to Satoshi and those to Not Satoshi were similar to those that SDL generated:

The nonce LSB for blocks I had attributed as being solved by someone other than Satoshi are distributed uniformly as expected, and the nonce LSB for Satoshi's blocks are confined to just some narrow bands of values. There has been much made of this, but I wasn't sure that the 1D binned histogram would be as relevant as a 2D binned histogram:

The "Not Satoshi" blocks are uniformly distributed for any given time, and the increase in density that occurs as time passes is due to the increasing (non-Satoshi) network hashrate. By contrast Satoshi's LSB 2D histogram seemed very interesting. 

First I needed to clean the data up - or at the very least figure out if blocks that did not fit into Satoshi's usual nonce-range actually belonged to him. It turns out they don't - each one is a block where one miner's extra nonce has crossed Satoshi's, leading to false positives when I was completing the manual block attribution.

After cleaning up the data a little, the histogram of Satoshi's nonce range over time becomes much clearer:

I was rather excited by the step pattern - was this proof that changing the nonce range over time affected the hashrate? Unfortunately not. As can be seen below, the change in hashrate always preceded the change in nonce range:

So, this adds a little more to the general picture but as far as I can tell doesn't really give any more information about the type of computer he used.

2. Summary

•  The LSB range 0 to 9 was always used, but the LSBs from 19 to 58 had changing restrictions over time. Why?
• Satoshi changed his nonce LSB restrictions generally about a month after he had reduced hashrate.
• October 2009 Satoshi used the upper LSB range more than the lower 0 to 9 range, but then changed back in December. Why?

I apologise for the fact that this post simply raises more questions than it answers. I'm glad I found these interesting facts (after being given a huge head start by SDL), but I don't have the in depth knowledge of computers, software, coding or the original bitcoin client to know where to start. I hope I've inspired at least one of you to take up the challenge and figure out a few more puzzles.

organofcorti.blogspot.com is a reader supported blog:

1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG




Thank you to the coinometrics.com team for use of transaction and address data, and to Sergio Demian Lerner for doing research that allowed me to write this post.

Find a typo or spelling error? Email me with the details at organofcorti@organofcorti.org and if you're the first to email me I'll pay you 0.01 btc per ten errors.

Please refer to the most recent blog post for current rates or rule changes.

I'm terrible at proofreading, so some of these posts may be worth quite a bit to the keen reader.
Exceptions:

• Errors in text repeated across multiple posts: I will only pay for the most recent errors rather every single occurrence.
• Errors in chart texts: Since I can't fix the chart texts (since I don't keep the data that generated them) I can't pay for them. Still, they would be nice to know about!

I write in British English.