Would be interesting to try it out on older AMD64. There's been a change that would explain it there:
http://developer.amd.com/documentation/articles/pages/682007171.aspx

Maybe Intel did something similiar without announcing it?

You could parse https://mtgox.com/code/getDepth.php

Do you still have the wallet.dat that once "contained" the 9000 BTC? I might be able to help you.

The hashtarget is wrong. Also, the font is quite hard to read. letter-spacing: 2px might make it more readable.

I'm still running an old node without SSE2 @600khash/s. The algorithm works so I don't see why we should make SSE2 a requirement.

I don't really know what it changes. I wonder why the define was made in the first place. The code should be able to determine whether it's running on a SSE2 CPU or not. I discovered it while comparing my 4xSSE2 hash function to the original one in 0.3.6 so it really means, that no 64bit build since 0.3.6 was able to generate any coins. Maybe satoshi can tell us why he put the define in the makefile.

Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.

It seems to be like this: everything before Core2 will be slower, everything starting with Core2 is faster. Can anyone test the code on an older AMD64? I know there was a change in the way SSE2 instructions are executed in recent architectures.

The merkle tree (containing the transactions, including the 50BTC) is hashed and included in the block. The hash will change (newer timestamps, and other stuff) so even two threads on the same host starting the the same time will work on a completely different block. There a blocks without a solution so sometimes a new block with a different merkle tree hash is tried. The latter is more common now at current difficulty.

That's nice to hear. Thanks for the donation and thanks to everyone else who donated!

Tilka: That's already the case with the mesh concept. Instead of one "supernode" sending the transaction to every other node you have many nodes sending the transaction to many other nodes which is much faster.

The client only connects to some of the other nodes. There's no need for more, because it's a mesh network. More connections would be a waste of ressources as your gateway has to track all of them. Bandwidth would also increase as supernodes would send a lot of unicasts. In a mesh it's more like a broadcast as information is relayed and distributed from node to node.

It doesn't affect your hashrate at all.

Thanks! That got probably mixed up when I patched the file with an older diff. I fixed the git: http://github.com/tcatm/bitcoin-cruncher

Oh, that's a part in the code my patch doesn't touch. You could try to remove line 2741 (CRITICAL_BLOCK(cs_main)).

Yes, test is single threaded. Is there any output on stderr? From the coredumps I can tell that there must be some output.

The problem seems to be hard to debug, though. Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.

Just an idea... you could remove the message that tells the user he already got coins and always pretend to have sent coins when in reality you didn't. Maybe with a nice "If it doesn't work contact me at ..." message. Hopefully they'll just assume it's broken and don't bother trying to get coins from it anymore.

That's not a real crash this time. It's an assert that fails in the miner. Most likely assert(hash == pblock->GetHash());. Can you run the test programm (explained in http://bitcointalk.org/index.php?topic=648.msg7096#msg7096)? If it fails, can you change -march=amdfam10 back to -march=native in makefile.unix, rm cryptopp/obj/*.o and recompile everything? What cpu are you running it on?

Oh thats easy: Get two nodes on a seperate network and connect them using -connect=other_nodes_ip and a seperate/empty datadir.

GDB can also generate coredumps with the command generate-core-file. It might be useful to reconstruct the cause for the segfault. Please note, that the coredump might include your wallet so it's probably a good idea to run bitcoind on a seperate datadir.

I also made an SVG version. It's not as shiny as the original logo, though.