Pages:
Author

Topic: New Mystery about Satoshi - page 5. (Read 16373 times)

legendary
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
September 03, 2013, 09:37:53 AM
#18
Quote
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
hero member
Activity: 531
Merit: 505
September 03, 2013, 09:36:47 AM
#17
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.
hero member
Activity: 531
Merit: 505
September 03, 2013, 09:28:21 AM
#16
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?
hero member
Activity: 555
Merit: 654
September 03, 2013, 09:21:21 AM
#15
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:


Quote
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.
sr. member
Activity: 399
Merit: 250
September 03, 2013, 09:14:05 AM
#14
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.
hero member
Activity: 531
Merit: 505
September 03, 2013, 09:05:56 AM
#13
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.

legendary
Activity: 1708
Merit: 1020
September 03, 2013, 08:45:14 AM
#12
Somebody (you?) speculated about Satoshi throwing away blocks that were found soon after the previous one. Would that fit into the picture?
hero member
Activity: 531
Merit: 505
September 03, 2013, 08:03:09 AM
#11
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.
kjj
legendary
Activity: 1302
Merit: 1026
September 03, 2013, 07:17:30 AM
#10
Possible option "E":  His next_nonce function was something other than ++.
legendary
Activity: 1246
Merit: 1011
September 03, 2013, 04:52:54 AM
#9
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?
staff
Activity: 4242
Merit: 8672
September 03, 2013, 04:30:50 AM
#8
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.
legendary
Activity: 1246
Merit: 1011
September 03, 2013, 04:17:52 AM
#7
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.
sr. member
Activity: 364
Merit: 250
September 03, 2013, 04:07:38 AM
#6
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
legendary
Activity: 1036
Merit: 1000
Nighty Night Don't Let The Trolls Bite Nom Nom Nom
September 03, 2013, 03:40:01 AM
#5
very interesting indeed, keep up the good work!
newbie
Activity: 43
Merit: 0
September 03, 2013, 03:37:22 AM
#4
I really like the research you do, and everytime you manage to stumble upon another mystery Wink 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.
legendary
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
September 03, 2013, 03:33:08 AM
#3
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?
sr. member
Activity: 282
Merit: 250
September 03, 2013, 03:06:21 AM
#2
nice findings...
hero member
Activity: 555
Merit: 654
September 03, 2013, 02:55:42 AM
#1
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.

Pages:
Jump to: