Bitcoin Forum
October 22, 2017, 06:28:31 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5 »  All
  Print  
Author Topic: New Mystery about Satoshi  (Read 15756 times)
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 537


View Profile WWW
September 03, 2013, 06: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.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508653711
Hero Member
*
Offline Offline

Posts: 1508653711

View Profile Personal Message (Offline)

Ignore
1508653711
Reply with quote  #2

1508653711
Report to moderator
18RATTT
Sr. Member
****
Offline Offline

Activity: 282



View Profile
September 03, 2013, 07:06:21 AM
 #2

nice findings...

jackjack
Legendary
*
Offline Offline

Activity: 1120


May Bitcoin be touched by his Noodly Appendage


View Profile
September 03, 2013, 07: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?

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
Muis
Jr. Member
*
Offline Offline

Activity: 43



View Profile
September 03, 2013, 07: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.
elasticband
Legendary
*
Offline Offline

Activity: 1036


Nighty Night Don't Let The Trolls Bite Nom Nom Nom


View Profile
September 03, 2013, 07:40:01 AM
 #5

very interesting indeed, keep up the good work!
DyslexicZombei
Sr. Member
****
Offline Offline

Activity: 350



View Profile
September 03, 2013, 08: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
teukon
Legendary
*
Offline Offline

Activity: 1246



View Profile
September 03, 2013, 08: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.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
September 03, 2013, 08: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.

Bitcoin will not be compromised
teukon
Legendary
*
Offline Offline

Activity: 1246



View Profile
September 03, 2013, 08: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?
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
September 03, 2013, 11:17:30 AM
 #10

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

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Hawkix
Hero Member
*****
Offline Offline

Activity: 522



View Profile WWW
September 03, 2013, 12:03:09 PM
 #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.

Donations: 1Hawkix7GHym6SM98ii5vSHHShA3FUgpV6
http://btcportal.net/ - All about Bitcoin - coming soon!
phelix
Legendary
*
Offline Offline

Activity: 1694


nmc:id/phelix


View Profile
September 03, 2013, 12:45:14 PM
 #12

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

blockchained.com ■ bitcointalk top posts
Hawkix
Hero Member
*****
Offline Offline

Activity: 522



View Profile WWW
September 03, 2013, 01:05:56 PM
 #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.


Donations: 1Hawkix7GHym6SM98ii5vSHHShA3FUgpV6
http://btcportal.net/ - All about Bitcoin - coming soon!
razorfishsl
Sr. Member
****
Offline Offline

Activity: 406


View Profile WWW
September 03, 2013, 01:14:05 PM
 #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.

High Quality USB Hubs for Bitcoin miners
https://bitcointalk.org/index.php?topic=560003
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 537


View Profile WWW
September 03, 2013, 01:21:21 PM
 #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.
Hawkix
Hero Member
*****
Offline Offline

Activity: 522



View Profile WWW
September 03, 2013, 01:28:21 PM
 #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?

Donations: 1Hawkix7GHym6SM98ii5vSHHShA3FUgpV6
http://btcportal.net/ - All about Bitcoin - coming soon!
Hawkix
Hero Member
*****
Offline Offline

Activity: 522



View Profile WWW
September 03, 2013, 01:36:47 PM
 #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.

Donations: 1Hawkix7GHym6SM98ii5vSHHShA3FUgpV6
http://btcportal.net/ - All about Bitcoin - coming soon!
jackjack
Legendary
*
Offline Offline

Activity: 1120


May Bitcoin be touched by his Noodly Appendage


View Profile
September 03, 2013, 01:37:53 PM
 #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

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 537


View Profile WWW
September 03, 2013, 01:47:46 PM
 #19



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. Smiley
jackjack
Legendary
*
Offline Offline

Activity: 1120


May Bitcoin be touched by his Noodly Appendage


View Profile
September 03, 2013, 01:48:31 PM
 #20



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. Smiley
I'm ok with this!
Looks like there are 9-10 computers per lab

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
Pages: [1] 2 3 4 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!