Quote from: laszlo on August 16, 2010, 22:13:00 So at this point, would a client that has not upgraded also have the correct chain? Yes. The only exception would be if an unpatched client made another fake transaction and managed to verify it. They would be able to spread that […]
Read moreRe: checkpointing the block chain
What is a bad chain? Could you elaborate more on why checkpoints are bad? 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 […]
Read moreChecking the block chain on load
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 implementation of this at the time. It might take longer […]
Read moreRe: [PATCH] Automatic block validation
Quote from: satoshi on August 16, 2010, 15:25:54 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 break out part of AddToBlockIndex that sets the new best block. I’ll probably end up doing […]
Read moreRe: blocks minus 1
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” because it’s counting the genesis block. Technically, yes, […]
Read moreblocks minus 1
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” because it’s counting the genesis block. Technically, yes, […]
Read moreRe: [PATCH] Automatic block validation
I’ve written a patch to help automatically validate cached blocks after validation fixes such as the one that was pushed out today. You can find it at http://fushizen.net/~bd/blockverify.patch or http://github.com/bdonlan/bitcoin/commit/b205251959448ca99123f2bc95b088bf06d4ef3b Upon first run with this patch, all blocks will be verified, and any invalid blocks, as well as blocks orphaned […]
Read moreRe: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10
On a Core 2 Duo T7200, the default code gives about 1.8 Mhash/s, and 4way is slower at 1.0 Mhash/s. It has 4 MB of L2 cache, so it is probably not a question of cache size, as suggested at some point. Unfortunately, the code (from svn) no longer compiles […]
Read moreRe: overflow bug SERIOUS
Interesting.. fascinating to watch this work its way through the bowels of the system. It was block 73746 that I generated. CTxOut(nValue=50.00000000, scriptPubKey=0x8DDD5C7DADB2D43AC5F186) 08/12/10 02:35 generated 50.00 And I sent 49.00 of it to 19Nzg21hQQDAY5GTdTTuUVPA4MaE7AusXz (using the broken chain) Now I’m waiting for that node to figure out it was […]
Read moreRe: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Quote from: jgarzik on August 16, 2010, 03:35:28 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% speedup with -4way, 63% total speedup with […]
Read more