I really like the research you do, and everytime you manage to stumble upon another mystery Besides the question why Satoshis nonces have a weird distribution, it would also be interesting to see if this 'fingerprint' can be used to look for other blocks or transactions done using that same PC, it could give us a clue to his identity.

At first I was thinking there may be some link between this and the fact that Bitcoin addresses are given in Base58. However, this doesn't explain the gap, the distribution, or the fact that a byte value of 58 itself appears frequently.

Curious indeed.

The idea of embedding a message seems plausible, particularly given the newspaper headline easter egg. I doubt there will be any plain-text messages as the distribution among the frequent bytes is too uniform. However, it might be worth seeing bytes 0 through 9 appear in adjacent block more than one would expect (clumps suggesting multi-digit numbers).

Edit:

On second thought, the lumps of 10, gap of 9, unusual bytes of 19 and 58, all suggest something unintentional to me. Given Satoshi's attention to detail when it comes to privacy it seems unlikely that he'd embed messages across essentially all of his blocks. A link to something about gray codes that would explain the gap would be appreciated.

The idea of looking at the nonce to determined endianness wouldn't have occurred to me when you consider how thoroughly little endian the reference Bitcoin software is, it doesn't even come close to running on a BE machine and never has...

As far as the distribution of the lowest byte goes: The counter starts at some value and gets reset when there is a new block or when you exhaust it. If you mine at some constant speed which isn't some large multiple of 2^32/600 hashes per second you would expect your found nonces to be highly non-uniform— not just (most obviously) in the MSB but in all of the bytes.

As far as the distribution of the lowest byte goes: The counter starts at some value and gets reset when there is a new block or when you exhaust it. If you mine at some constant speed which isn't some large multiple of 2^32/600 hashes per second you would expect your found nonces to be highly non-uniform— not just (most obviously) in the MSB but in all of the bytes.

I don't follow.

Why would the hashrate affect the distribution?

If the nonce is simply incremented until a block is found then why wouldn't the least significant bytes be uniformly distributed?

As far as the distribution of the lowest byte goes: The counter starts at some value and gets reset when there is a new block or when you exhaust it. If you mine at some constant speed which isn't some large multiple of 2^32/600 hashes per second you would expect your found nonces to be highly non-uniform— not just (most obviously) in the MSB but in all of the bytes.

I don't follow.

Why would the hashrate affect the distribution?

If the nonce is simply incremented until a block is found then why wouldn't the least significant bytes be uniformly distributed?

It is not, because of the difficulty you need to meet. Also you don't need to continually increment the nonce, and in some 'implementations' valid nonces get destroyed, what this does is skews any in-depth research.

Also FPGA's don't have an endian since they are implementations of pure logic, only the algorithm is endian specific.

"Satoshi" has 59 machines mining. To make sure that none of them accidentally repeated work, each one was given a different machine_id to put in the LSB: 0,1,2,3...58. Machines 10 through 18 broke down and he didn't bother to recycle the LSBs.

Ta-da! Solution. It makes sense that you'd put the machine_id in the LSB and not the MSB because it's easier to detect that you've wrapped around: Just check for current_nonce == machine_id. Otherwise you'd have to test for current_nonce >> 56 != machine_id, which is marginally slower.

This explanation could be disproved by checking the frequency of ExtraNonces going back in time. If too many computers are mining together (started at the same time) then one would expect one to be slightly faster than the other, so ExtraNonces are not synchronized. Then a machine with a lower ExtraNonce can solve a block just after a machine with a higher extranonce, and time seams to go back.

(I don't known the copyright status of reddit content, sorry about re-posting).

Note: Please, I encourage someone to check the research I did and post "yes it's true". I still have the felling that this is too awkward to be true, and I may have made a mistake somewhere.

Note: Please, I encourage someone to check the research I did and post "yes it's true". I still have the felling that this is too awkward to be true, and I may have made a mistake somewhere.

I hacked short script pulling out nonces from blockchain.info and the statistics (even on first 2k blocks) are similar to yours. Please, could you upload somewhere the block number, nonce and extranonce list for first 20k blocks?

The theory of 59 machines can be proven/discarded on independent statistical analysis on the expected hashrate of each such machine, they should be kinda consistent in time and independent on each other.

"Satoshi" has 59 machines mining. To make sure that none of them accidentally repeated work, each one was given a different machine_id to put in the LSB: 0,1,2,3...58. Machines 10 through 18 broke down and he didn't bother to recycle the LSBs.

Ta-da! Solution. It makes sense that you'd put the machine_id in the LSB and not the MSB because it's easier to detect that you've wrapped around: Just check for current_nonce == machine_id. Otherwise you'd have to test for current_nonce >> 56 != machine_id, which is marginally slower.

The probability of 10/59 machines being broken and having consecutive numbers is 1.6*10^-10