A mistery hidden in the Genesis Block

[zakoliverz]

Just cross your fingers ,  maybe it will bring good luck.

[1714078812]

1714078812

[phatsphere]

I think everyone can safely assume that he had access to a larger multiprocessor machine. His rationale might have been that the first block should be a bit "harder" than the consecutive ones. That's all.

[Bitobsessed]

Sergio, if you are still around, have you investigated this anymore and if so what are your findings?

[lavalampoon]

Code is not created all at once. He would have been determining the best rules to use by testing them. He likely had a computer crunching away for months to prove the difficulty that he later decided was best. His computer would have kept the lowest hash, and that was the best one to use for the genesis block.

[Sergio_Demian_Lerner]

Sergio, if you are still around, have you investigated this anymore and if so what are your findings?

Yes, and all the mystery regarding Satoshi computing power has been solved.

Satoshi did one more joke on us before fading away. Tomorrow, I will tell.
 
 

[maaku]

Code is not created all at once. He would have been determining the best rules to use by testing them. He likely had a computer crunching away for months to prove the difficulty that he later decided was best. His computer would have kept the lowest hash, and that was the best one to use for the genesis block.

I suppose he then planted the 1/3 article in The Times?

[Micky25]

Hi,

do you guys have an explanation for these transactions?

That genesis block address has received 848 transactions!

Is this a deliberate "feature" in the standard bitcoin client which has the first used address as a default somewhere and therefore collecting loads of smallish payments?

All these 0.000055 BTC transactions are really strange. Satoshis pension payments, built into the protocol? 

https://bitcointalk.org/index.php?topic=286847.msg3070309#msg3070309

[jackjack]

Hi,

do you guys have an explanation for these transactions?

That genesis block address has received 848 transactions!

Is this a deliberate "feature" in the standard bitcoin client which has the first used address as a default somewhere and therefore collecting loads of smallish payments?

All these 0.000055 BTC transactions are really strange. Satoshis pension payments, built into the protocol? 

https://bitcointalk.org/index.php?topic=286847.msg3070309#msg3070309

Maybe it's people sending 5500 satoshis to Satoshi?

[Micky25]

you mean like a kind of sacrificial offering? 

[Stephen Gornick]

Satoshi did one more joke on us before fading away. Tomorrow, I will tell.

A new mystery about Satoshi hidden in the Bitcoin block-chain
 - http://bitslog.wordpress.com/2013/09/03/new-mystery-about-satoshi/

by Sergio Demian Lerner,  ‏@SDLerner on Twitter.

[garlonicon]

Genesis block header hash is this (hex):
 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
 
Note that it starts with 43 zero bits. Why? The block target difficulty was much lower (around 32 bits), so we can assume Satoshi did this on purpose.

There is more: if you use a different extraNonce value of 1, 2, 3 and 4, you will notice that there are more headers starting with 40 zero bits or more:

Code:

extraNonce: 0x01, time: 0x495fab1d, offset: 0x0c, nonce: 0x3429da6f, hash: 00000000 00052ab4 78b6f8a2 dcaba26a 189361c9 030b5d56 c524cb7b ddf00d0c
extraNonce: 0x02, time: 0x495fab20, offset: 0x09, nonce: 0x6f42bb66, hash: 00000000 00381808 e3b876ad 01e1262e 3a4ca528 72b1cc25 ca072fbd bc29d41f
extraNonce: 0x03, time: 0x495fab1f, offset: 0x0a, nonce: 0xe3d4f1f1, hash: 00000000 00792af0 bf962bc1 d3622071 92709091 65ae7c7b f8589911 d8277fa5
extraNonce: 0x04, time: 0x495fab29, offset: 0x00, nonce: 0x7c2bac1d, hash: 00000000 0019d668 9c085ae1 65831e93 4ff763ae 46a2a6c1 72b3f1b6 0a8ce26f

If you try to find just another 40-bit block hash with the same extraNonce, it will be more than 300 seconds away. Here, the offset of time is so close that it seems to be done on purpose.

[mynonce]

Genesis block header hash is this (hex):
 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
 
Note that it starts with 43 zero bits. Why? The block target difficulty was much lower (around 32 bits), so we can assume Satoshi did this on purpose.

There is more: if you use a different extraNonce value of 1, 2, 3 and 4, you will notice that there are more headers starting with 40 zero bits or more:

Code:

extraNonce: 0x01, time: 0x495fab1d, offset: 0x0c, nonce: 0x3429da6f, hash: 00000000 00052ab4 78b6f8a2 dcaba26a 189361c9 030b5d56 c524cb7b ddf00d0c
extraNonce: 0x02, time: 0x495fab20, offset: 0x09, nonce: 0x6f42bb66, hash: 00000000 00381808 e3b876ad 01e1262e 3a4ca528 72b1cc25 ca072fbd bc29d41f
extraNonce: 0x03, time: 0x495fab1f, offset: 0x0a, nonce: 0xe3d4f1f1, hash: 00000000 00792af0 bf962bc1 d3622071 92709091 65ae7c7b f8589911 d8277fa5
extraNonce: 0x04, time: 0x495fab29, offset: 0x00, nonce: 0x7c2bac1d, hash: 00000000 0019d668 9c085ae1 65831e93 4ff763ae 46a2a6c1 72b3f1b6 0a8ce26f

If you try to find just another 40-bit block hash with the same extraNonce, it will be more than 300 seconds away. Here, the offset of time is so close that it seems to be done on purpose.

Can you explain the purpose?

Satoshi wanted exactly this ExtraNonce?

[garlonicon]

Can you explain the purpose?

Satoshi wanted exactly this ExtraNonce?

I don't know. I just noticed it is quite unlikely to get something like this randomly. You can try producing some 40-bit block hashes and then check how far from that you will get blocks with other extraNonces. Some people thought Satoshi was just very lucky. But why he used a block with more than 40 leading zero bits, where there were a lot of blocks with 32 leading zero bits? And why there are other hashes with more than 40 leading zero bits, that are so close to the block he included in the current chain? You can try for example using extraNonce equal to four and find another 40-bit block with some earlier timestamp: you will find the nearest block 537 seconds before. And here you have four nonces, where each timestamp exist just a few seconds before!

TLDR: I just found a pattern. I don't know yet, what is the meaning of this, we can only write some code and guess what happened, how the Genesis Block was mined and why it was mined in that way.

[mynonce]

...

That could be interesting ...

... but on the other hand, they just need to move on and forget about it cause it's part of the game where some will win and some will lose.

We don't know Satoshi's game and the plan for the lost coins, but this is also possible:

https://news.bitcoin.com/online-sleuths-believe-satoshi-nakamotos-bitcoin-stash-is-a-blockchain-treasure-hunt-meant-to-be-found/

'Lastly, the online detectives also discussed Satoshi’s famous lost coins quote: “Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone.” Maybe, Satoshi wasn’t talking about coins lost over time, but the creator’s stash hidden inside the blockchain via text or a myriad of messages.

“Whoever is able to solve it, is the chosen person that Satoshi expects to succeed,” an individual wrote in the bitcointalk.org conversation. “It’s like a place to determine Satoshi’s legacy for us in the future. Is this a contest? A pirate treasure?” he asked.'

Maybe you discovered something ... (read the link)

[BlackHatCoiner]

And here you have four nonces, where each timestamp exist just a few seconds before!

Which means... what? The only thing I can conclude is that Satoshi had a lot more computational power than imagined, and was searching for a block with these specific details you've covered for a reason.

[pooya87]

There is more: if you use a different extraNonce value of 1, 2, 3 and 4, you will notice that there are more headers starting with 40 zero bits or more:

Code:

extraNonce: 0x01, time: 0x495fab1d, offset: 0x0c, nonce: 0x3429da6f, hash: 00000000 00052ab4 78b6f8a2 dcaba26a 189361c9 030b5d56 c524cb7b ddf00d0c
extraNonce: 0x02, time: 0x495fab20, offset: 0x09, nonce: 0x6f42bb66, hash: 00000000 00381808 e3b876ad 01e1262e 3a4ca528 72b1cc25 ca072fbd bc29d41f
extraNonce: 0x03, time: 0x495fab1f, offset: 0x0a, nonce: 0xe3d4f1f1, hash: 00000000 00792af0 bf962bc1 d3622071 92709091 65ae7c7b f8589911 d8277fa5
extraNonce: 0x04, time: 0x495fab29, offset: 0x00, nonce: 0x7c2bac1d, hash: 00000000 0019d668 9c085ae1 65831e93 4ff763ae 46a2a6c1 72b3f1b6 0a8ce26f

Isn't what you did here true about any other block with difficulty = 1?
You are computing the hash 4 billion times then increment the time then compute it another 4 billion times, and repeat this multiple times. That is more than enough to find a hash for block with difficulty = 1 almost all the time.
In other words you can do what you did to any of the subsequent early blocks.

[garlonicon]

Isn't what you did here true about any other block with difficulty = 1?

I am not looking for difficulty=1. That would be 32 leading zero bits (to be precise, lower than 00000000ffff0000...00). Here you have 40 leading zero bits, so something like difficulty=256 (or even higher difficulty). Of course it also meets difficulty=1, but it is always true that if a block meets some difficulty, then that block also meets all lower difficulties.

You are computing the hash 4 billion times then increment the time then compute it another 4 billion times, and repeat this multiple times. That is more than enough to find a hash for block with difficulty = 1 almost all the time.

There are a lot of blocks with difficulty=1 (leading 32 zero bits). But if you want to get any block with difficulty>=256 (leading 40 zero bits), then you can for example use extraNonce=4 and you will find it with 537 seconds earlier timestamp. For extraNonce=3 it will be 696 seconds earlier. On average, you have to check 256 seconds to reach 40-bit blocks. Here you have four such blocks, where each has a difference of a few seconds, when compared to the block in the chain.

[pooya87]

Isn't what you did here true about any other block with difficulty = 1?

I am not looking for difficulty=1. That would be 32 leading zero bits (to be precise, lower than 00000000ffff0000...00). Here you have 40 leading zero bits, so something like difficulty=256 (or even higher difficulty). Of course it also meets difficulty=1, but it is always true that if a block meets some difficulty, then that block also meets all lower difficulties.

You are computing the hash 4 billion times then increment the time then compute it another 4 billion times, and repeat this multiple times. That is more than enough to find a hash for block with difficulty = 1 almost all the time.

There are a lot of blocks with difficulty=1 (leading 32 zero bits). But if you want to get any block with difficulty>=256 (leading 40 zero bits), then you can for example use extraNonce=4 and you will find it with 537 seconds earlier timestamp. For extraNonce=3 it will be 696 seconds earlier. On average, you have to check 256 seconds to reach 40-bit blocks. Here you have four such blocks, where each has a difference of a few seconds, when compared to the block in the chain.

There is nothing special about having more leading zeros than needed (or being more smaller than the target than needed). So lets take a look at some blocks and see how common it is.
I checked the first 32256 block headers meaning from block 0 until first time difficulty changes and here are some blocks that had more than 40 zero bits. 40 was chosen since that is the number of zero bits in genesis block otherwise block #22 has 36 leading zero bits.
The following are the list of block hashes and their respective heights on mainnet, the first 6 have "smaller difficulty" that Genesis block:

Code:

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f  block#0

000000000009606d829b157912edb060c406b519fb2bfcc1078c196b69c67e49  1430
00000000000243ab3dd422f82638c9651cfc401ac763b2228f00f6abae334f48  11686
00000000000816633b61ddf4d411169935a03ffc02495a6448d2d029590c3df2  18703
00000000000bcae6934ca8f914b1724141ba708c6882657f6cba330965681e38  19834
000000000003ce28ff7f9998c2f2a1fbd03fffcb4c13f65b6b82b40d4a272292  23411
000000000006f331e9d9d8736bb012fee2193cb978f621fe9bd7e181a1a5df95  26561
0000000000d16752cf56ebae77a37a8fa1ac8e234336a41622c3b7924a07a644  598
000000000033b4ee1cc40f05145b1a3987cca2473589e7e23082996e2fe7c899  722
000000000057d77971fb0bf24812e155f9eb7c4eea682b62defd627b7d42c2eb  801
000000000037504b6bdd57439970d748eac0f091945f8b12373e83c1bbc46c79  1067
0000000000a4d1bff90f29495e4c45d96609dcdc278264511d90e5f1602034d5  1481
0000000000d4325fa7c9e97ac69cdf22a6803e925c5297d925fab14fd53e86a6  1910
0000000000243dfaef0a3b85c3b9c13c958ce6bed9fd4cb154c1df109c1ef884  1986
00000000005c71ed36bf631dd20841b2745cccb29d620b75f929738dba5d3e96  2334
0000000000d3f53438446e9b4d4d1856f563667fb1e17730b7c1e4b9dcc00b30  2790
0000000000f2a226a43a012b50da8cad09c1cec43834d14681efa9974e623b85  3087
000000000035f4cce8ac52847b6618f8bd3f53d501dc6a006839a0963a8f6f6e  3330
00000000005ae5d168d58fb301e897215230ee22b8a5ea522a1cd5cd3fb655e8  3920
0000000000586980359c4c669ce5247c4d084a03923f48f7f964857d4aba21b7  4132
0000000000a9b124abca780e299cbc6be88596ac86458f22ccb0bc2d5257b6f6  4291
0000000000b54b5510fbf287ad4c31ced608521b2ccef6c7ed8ef033060e3eb4  4300
0000000000e01d798e318d3677cbb4d6f642833da65162472a6513c5a9cae5b2  4436
000000000099fc7a4e340d4203deb248ea83f7e0a1864b8a907d6af8a2ddb04f  5038
00000000005cdd0f359287d4c5c9e3611c2cc53bc45010c1139bfc1660794ef3  5719
00000000009b4b024ee5b5a011fa3a8c1d6d2155eb1822d2d3673f28160c943d  5985
00000000008cd551822768cf78bfd9ffdc68471338636ce7cfb5b22822f0aa74  5993
000000000073c2eb2cb4bc5d9d66bbd99353ed34f10576c7b5afc507c91064ef  6148
00000000004eda0d6c9fd39ad61fa535efb4bb1a33f656185536c256c31a3d8d  6176
000000000049d528e1ff957e93e089491752d69a924e4de2b5a6ad2f2c05f446  6238
00000000004b166c36d656f176b051ebe712ae69cfa624c5ab74719fbc6c7a56  6301
00000000006c56e2d190e509e63bd9fe6e8789d9ad33727d31754aa76f1f97f7  6328
000000000010b24a122163f2037132d767e6c5bd4c0642d9669fd94845e93289  6476
00000000004da06c86b8417e8ab7d29ca55ffb85cfe399e41dc0adfcf5f3d330  6572
00000000004b536fdc5171605e51357a91b53f1cbdffa59448fa07c5ef07be47  6588
0000000000f4560350f9ca6adfe15b05fd4d06389f32b7a3b7ec2fcc85fae341  7651
000000000031e03f8f396ba4d1ae91489983fc878e3f4295e15052edf33858a5  8454
00000000005ba4f850d0c3bc74a4bcdfa33f72f6becf62276b3a61f1e7ae9207  8864
00000000007adb697bf21410b4353bcaea2d15fe61b15ab47bd521b70825cb1d  9367
00000000007772bc65a8a3c3e9a83bec0729967cea649a6e99c7a4221872a292  9553
000000000069d1e345d08377d2b7ac27b9cfb87176e5ba2f106bec1c38474e1b  9665
0000000000da30f96e392bc421c7e25bd8cf67013a0f5d740ace7206f2e144c6  9898
00000000004afd117272c0de5b1902b469d8375454cb52ec5b63fef4bf8ec20f  9912
0000000000360b078b37111a567b25ad2fa96905140604870d61a3e7aab18f4e  9994
0000000000fe085acdebc039385954c0c3f96a053749a09781b3c9460fcfbae7  10117
0000000000bb9cdd5874295154cd7f4703ea05413b7499847df33b1911e5a58e  10854
0000000000783922fa5a57b49e704c509631aa57a6d7d505cdd48f60983e6735  11267
00000000006e4969c22a20d6b8f0e0701f7809cb7e64c03e646890436b641db6  12226
0000000000a597aaf0ec5713f67aed907c33a95ba8a5878c95a636a789f9467b  12237
0000000000bba4619c3a7f1df0c3e3a3d704e18b0f2451274472f58e4e091a33  12348
00000000009fb935a11d14ffff995a1055a60b2f5335aa9dc97818d45fd0c78e  12385
000000000095d7ddac813354b03aa9f630a1a26f703206db2a20de746c03ac82  12414
0000000000fa36711d93111a33d004d77a8ff4e8b07670188deeba1d4715214b  12659
0000000000a84bea6322db25d3b9298aa47062c03549c70a9099fd1836bb86de  12668
00000000002a89927e7cf8aa627748d6ebeff66a28871cab35f932696246d2b4  12870
00000000009273a65a059d705ce5f4c5e9769cd974ab4ff8cf91286d5afe7420  13266
0000000000cee7c7224db4a850e16882b8be8a6151782bff52b424e7b3658d0f  13336
000000000018c6d781e2900dfbde519fd28b4b8408ac031e2ce8f573c604fcbd  13768
00000000009c89d7dcb337dcea7f3f19d32a26cf5b0d01f88ea62fe0d7c34e1c  14524
000000000027b7fae0e5526346d9e95563ee65b26856a547e4829555e48a2d93  14572
000000000016a94f5c52ee9cf61f09062ca2f7b996a9ddab33c92e59f26e4ac3  14770
0000000000f00a60b508f16dd1cb515a50e5f2cabf283306a9b1016c5e1ac317  14867
0000000000481708c7fd64fdde3109a278a75313ed8ee49f82116aa13dbffcc4  15514
000000000047ee247328573b7944e06b8c507ae71befb1ddb0f1ad44bd480d73  16126
0000000000ef3ce0e17cbf3045c6dfb87cfa0933e3ce7ecaab82290c809c25c3  16911
00000000005d747d91b5eac43896f6813d4955c6de97ab7b047d8fc093579dd1  17344
0000000000c72a9fae1fb342344ab5c05d59b593e6945d32ab9d0d59b39e9ee8  17684
0000000000d01ba927753bca734e2698f32cd47f3b2103a485c580df718be1f5  17838
000000000062ba735bb273a6dac7c709f031c5ef756933bf4440b9498f6f8713  17892
0000000000121c6983323c4a1434965cddd228ec2d1b6c79e9305e3624934b23  18319
0000000000d11330bd5f2aa30f77be8be91842886099fc13c116af0f8c9d1553  18568
00000000005c69babf8d42f2417b859e361b05d8ddae0092cb0a1f0216057f36  18665
00000000009a73bea4f8761a54a781ad220bec5ac501a8ba798a51e82364b4ca  18770
0000000000d2690bb4b713686d5a74109a5f8002ae76e8649465fd04ad63a572  18990
0000000000ead9ab412155b454cbcd7b3a7ad6ece2d8380a0f6cdfba78108aa3  19079
00000000002e72ac8e25bdb9250c9b8e53b3bfe9e95c4d78240a1dad3e8ad1b9  19409
00000000007eeaae4496f0c062e9e3e08c543e5c28ee94210c3c3a154cfcd1df  19457
00000000003e45f91f985e6a1a9c2428ac5f44ee086c1e5ef9a258e7d3bd048b  19876
000000000056ab0eb870f7044bc1305912e4399c440b85bc258424cec7e9a9ee  20074
0000000000cf3ca869496a575b58acf1e02041d062d9b9344fe610670a2db610  20169
00000000005209af0dfb5d3430c3e2f343cad75b0522c00d2c3a5d4d62bcb829  20242
0000000000e0ad3d241b04e6d1149255aa54b360724a07bfbc81589ae10ebfc2  20501
000000000083006625942b0b6ce2e5a5aa90eacf45962a5fc03e401fbe874907  20719
0000000000a99651a72ff286ccaf1c3066838295a532ada34475096aa9a17669  20820
00000000001b3783ab66c48133632b90a9afea63354dbca73b6cb660d57b6194  22018
0000000000ce19b0daaeb264e06f487b676867823c1e527b3747661b0c1fd9b0  22214
0000000000a4a70a671bf21caa34d22593dc35cb4e01ed32e142b5560ca29bc8  22253
000000000040c67b4b85522641cf9f7f7c3d3997a7d8af28e692c1797f2f76e1  22603
0000000000be9c8806afa5d94d7c005804270a1f74d6848e36b26b420666860f  22700
0000000000fa28992e47ba1422ae7983ea6404575320903a07aae8b13e847b7c  22938
00000000004b47b387df7cf34a54fa2e154c6b458ed84f500e2b3bca1d8f2861  23202
0000000000848e1cd6d19f23e0ef26c462403bb765a5d13c1b848ad115de60f0  23566
00000000006394cae953b3073fc38469749e4fb434204e1ed8ff08eed103ddc3  23817
0000000000b4f2f6b79332d77a53ada64f29a2b882cceaf4d306fe309068ee3f  23840
0000000000b95a3f662cfd9584ed6a5b1ac4ef162a5c23d3d2058e71251e5c0d  23884
0000000000d785b49355ea0e53cff2b183ccce43f786f351a9ef6cb848873848  23931
000000000043da641f2d4167379b5445eb8f951f111688e9733165d9bf379d4d  24456
000000000053e76a6997b34929141d55a5cea39c5eb564c83ef7a56f3e05f98b  24686
00000000005626a763b1828bd08732574c21333e70ee0a10ff4620cd8d76847a  24930
0000000000f6e84b3d057bc8b837602f122133feacf3940454a861d99ad5b17a  24968
00000000004ef0d9510c38c4330e21ba44cce663cd9b9c40dbe0dcbdf892dd5b  25478
00000000008630ca9f58abbd25977a6099a587baa9c2e31953bd68b8f5ad4753  25626
00000000002577d97ded2ad82323c49cce3fb6088949bc2b9e873137d4561ca3  26086
0000000000e8ce315b3134555f832d33fdf027f47863de2284127ed9b4bc1639  26134
0000000000640d8bad2d9525e3d8009aa09e9a00c48e9106a77be14a9acf7740  26171
00000000007b5ed4767dd94d436ab4c98424a253e1bac7e3980af482721ee9ef  27245
00000000005799de7da8facf11bb8a0bb67e39ee5350b6bffa98936952cca087  27412
0000000000ca28e688d6cf1a28b1e7272e748eb7313348ef93c635eda182ff5d  27894
0000000000f53a2654425ec97bc36751f2a706601dceda49d79e1fc45b906339  27916
000000000047358d0fde5d7dbd3e76e02ced8820144c5cda86c4500c07034b26  28176
000000000057340811246bd68a91f5f2cfcd93f2b7bcb3b0ea86a0d82a301b56  28521
0000000000a79d9d2bbaf9c1e4829e736b2cad25c53dfa072b79049e588e14e0  28629
0000000000ce0117af4bb40f089458c0da61cc679462623a95c5b1eefe268af5  28854
000000000035c250e9e60b4677e78a94363acc95753d51265fd8631d17b36888  28869
0000000000c62500f71b0ce7544d40793715e9d180e8d4c3af006afc6d626082  29126
00000000005a615b521c5d9b1e553a5f0ce7def6e8692e9b0f7b9c2aa3630347  29492
000000000085f317500612a407d2433e30a51146476b85f83f640e52586344b3  29757
0000000000167a0ac1681ac3ad6d085ac5e6c1450a5420f59bb6d3843a5322d2  29919
00000000002d43211ae9f9552eec105ad10e368c96b6cccdaed237baebb80541  30775
000000000097727bbcf5a5c18385e5d5ce2bddbf5ea400eb1e7d5f7a5f40ba72  30806
0000000000b4d3bac73c2f78a60cf11084c850a4aecee4c871d56ccb0e19a0b2  31199
000000000088ff95790986e623fa687e317a4e7f0cc51cc815ba31850440940a  31327
000000000016294d1162587f28a32b84df6644c71c1bbbef343830b3bb31e4df  32044
00000000003e1423e5539f6ae106e82aa821e47db25a522a694ebb6d66052fea  32197
0000000000e6acf3219c03344d06a79a601b3462d6eea5e382fde15ac77d22c4  32219

[garlonicon]

There is nothing special about having more leading zeros than needed (or being more smaller than the target than needed).

I checked the first 32256 block headers

So on average you could expect something like 32256/256=126 block headers with leading 40 bits. And you have 124 blocks (except the Genesis Block), so nothing special here. But if you try to re-mine those blocks with similar extraNonce values and with similar time, usually you won't get four 40-bit headers around those blocks. For example you can take block 1430, it has 0x70 extraNonce, you can take 0x6f, 0x6e and 0x6d, then try to find another 40-bit block with such nonce and an earlier timestamp. I guess for a typical block you will get them 200, 300 or maybe 400 seconds before (or even more, but on average it will be something around 256 seconds before).

[mynonce]

... it seems to be done on purpose.

@garlonicon, maybe you have an answer for this:

Satoshi did one more joke on us before fading away. Tomorrow, I will tell.

A new mystery about Satoshi hidden in the Bitcoin block-chain
 - http://bitslog.wordpress.com/2013/09/03/new-mystery-about-satoshi/

by Sergio Demian Lerner,  ‏@SDLerner on Twitter.

They couldn't solve that. It's about the nonce values (not extraNonce). The largest miner back in 2009 (my opinion: it is Satoshi) has certain values [0 - 9] and [19 - 58] as nonces in the mined blocks what is unusual. Maybe it has something to do with your findings in block 0?