August 16

I'd like to reduce the number of blocks displayed in the status bar by 1. When you first load the program, it'll display 0 blocks instead of 1: "0 connections 0 blocks 0 transactions" It's always been "nBestHeight + 1…

SVN rev 139 does a basic check of the block chain after loading. With this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork. There wasn't time to do a careful imple…

Quote from: satoshi on August 16, 2010, 03:25:54 PM It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should brea…

That's a difficult approach. We need to cause a reorg, which will disconnect the invalid chain. This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best. Here's what…

For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP? Then we can -addnode= them and make sure to connect to at least one 0.3.10 node.

I suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower. We need enough of us so that at least one node you connect to will be 0.3.10. The problem will start to go aw…

Done in SVN rev 137

Quote from: NewLibertyStandard on August 16, 2010, 10:42:28 PM How is the strength of the chain calculated? Total proof-of-work.

There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back…

Un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks. If an old ver…

It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower nodes have been responding with the current block number for some hours now. That means it's no longer necessary to delete blk*.dat befor…

On Windows, findstr /c:"version message" debug.log It looks like the bad chain was on block 74678 recently. Can't wait to overtake it. On the stats at http://nullvoid.org/bitcoin/statistix.php there's been 5 blocks pe…

The bad chain is also slowed down as more nodes upgrade. We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are alr…

Quote from: trebronics on August 16, 2010, 01:02:35 AM Most people running clients are not reading this message thread. So... Silly questions: 1) How will this continue to affect version 3.8.1 (pre-catastrophe) client…

Quote from: kosovito on August 16, 2010, 12:39:17 AM I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine? If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes. F…

Quote from: Ground Loop on August 16, 2010, 12:29:55 AM Question about fallout: I had a transaction that I submitted after the bad block, using the bad block chain. What is the status of that transaction? From what I…

Quote from: Vasiliev on August 16, 2010, 03:17:07 AM try -march=amdfam10 That works. That's strange... are we sure that's the same thing? tcatm, try amdfam10 and make sure you get the same speed measurement.

Quote from: tcatm on August 16, 2010, 12:43:39 AM I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer)…

I wrapped sha256.cpp in #ifdef FOURWAYSSE2 #endif // FOURWAYSSE2 try it now.

Quote from: jgarzik on August 16, 2010, 03:35:28 AM Code: cpu family : 6 model : 26 model name : Genuine Intel(R) CPU 000 @ 3.20GHz stepping : 4 cpu family 6 model 26 stepping 4 is an Intel Core i7. That's a 23% speed…