New Mystery about Satoshi

[Sergio_Demian_Lerner]

Please forgive me for posting a blog link, but the post has many images and it requires to do extra work to paste all here.

http://bitslog.wordpress.com/2013/09/03/new-mystery-about-satoshi/

The idea is that the LSB of of the 32-bit nonce value of all blocks supposedly mined by Satoshi have a very strange probability distribution.

Something is wrong.

Can anybody replicate my results?

Best regards,
 Sergio.

[1713268124]

1713268124

[18RATTT]

nice findings...

[jackjack]

Very nice work
B or D I guess
Or he coded his own mining software which had a bug/feature resulting in that distribution

Could you plot the satoshi LSB graph against block number?

[Muis]

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.

[elasticband]

very interesting indeed, keep up the good work!

[DyslexicZombei]

That's some incredible detective work there.

I'm guessing that the secret message will be fully decoded by the world's best supercomputers in the future. Unfortunately, I can already tell you that the answer is:

42

[teukon]

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.

[gmaxwell]

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.

Not sure if it explains the data there, but thats what I'd look for.

[teukon]

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?

[kjj]

Possible option "E":  His next_nonce function was something other than ++.

[Hawkix]

I guess Satoshi used LSB as message encoder (preselected) into some alphabet of roughly 50 differrent chars and then he cycled over all higher 3 bytes.

LSB of first 64 blocks (all of them found by Satoshi, I guess):

29,1,8,5,43,29,24,57,28,40,30,23,63,55,41,56,4,7,50,22,54,43,40,37,39,35,52,54,46,50,8,

                                              ^--- the only exception?

21,8,34,34,20,46,1,0,40,6,7,43,56,48,33,1,32,27,44,46,9,57,44,46,27,5,28,30,22,2,55,5,34

Edit:

So nonces use about 1/4 of possible LSB values, which corresponds to the observed extranonce incrementing by roughly 4 after each found block.

[phelix]

Somebody (you?) speculated about Satoshi throwing away blocks that were found soon after the previous one. Would that fit into the picture?

[Hawkix]

Somebody (you?) speculated about Satoshi throwing away blocks that were found soon after the previous one. Would that fit into the picture?

Yes! He could run normal ++nonce loop and discard blocks whose LSB, for some reason, he did not like. For both output chocking and some message hiding.

[razorfishsl]

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.

[Sergio_Demian_Lerner]

I like the explanation given by eyal0 here
http://de.reddit.com/r/Bitcoin/comments/1lmtny/maybe_satoshi_foresaw_the_advantage_of_fpgaasic/

I will copy-paste it here:

Here's a solution that actually makes sense:

"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.

current_nonce = machine_id
while True:
  result = hash(block, current_none)
  if result < target:
    break
  current_nonce += 256

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.

[Hawkix]

We should know whether Satoshi was generating blocks at difficulty 1 too slow (and needed multiple machines) or too fast (and needed to discard already found blocks). Does anyone know what kH/sec one could expect from 2009 CPU and C-style SHA256 implementation?

[Hawkix]

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.

[jackjack]

Here's a solution that actually makes sense:

"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.

current_nonce = machine_id
while True:
  result = hash(block, current_none)
  if result < target:
    break
  current_nonce += 256

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

[Sergio_Demian_Lerner]

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

They were not broken. They belonged to the next computer Lab in the faculty. But Satoshi couldn't get access to that lab when he wanted to start mining.

It was the Lab of the "Law and Regulation" class.

[jackjack]

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

They were not broken. They belonged to the next computer Lab in the faculty. But Satoshi couldn't get access to that lab when he wanted to start mining.

It was the Lab of the "Law and Regulation" class.

I'm ok with this!
Looks like there are 9-10 computers per lab