difference between blocksize and inconsistent hash record.

[coldguy]

Hi,

I checked my local version of all the block chain information, and I found there is some difference between my block chain and the info displayed on blockchain.info website. Initially the difference is about block size information. After some block height (sorry I don't check exact height number), there is around 2 or 3 bytes difference of the block size. Also the prevhash and merkel root is consistent.

But I also found there is difference between the hash record field after some block height. I know there is a fork between 0.7 and 0.8 version of bitcoin client and then I checked my local block chain very carefully and found that the fork happed somewhere in the file blk00049.dat some time between that famous incident.

I am using v0.8.1-beta bitcoin-qt client. I thought this version should be the right version but this strange thing happened here. Please someone help me with this and tell me I am making some stupid mistake here... Otherwise...... Is my client fooled by some other network?

[coldguy]

I found the problem, it seems the blk000xx.dat file also has orphaned blocks in it, because I have located the fork and noticed there is only one branch alive.

It seems not a good idea to make orphaned blocks in the main chain, or there is other usage of them so they are still stored there after some other longer branch has been found?

[TierNolan]

It seems not a good idea to make orphaned blocks in the main chain, or there is other usage of them so they are still stored there after some other longer branch has been found?

I think the point is that the chain is really a tree due to the orphans.  Once a block is verified, it can be added to the file.  Since most verified blocks are not orphans, adding them to the file doesn't use up much space.  It means that you don't need to handle file fragmentation.

[coldguy]

The fork in my local block chain happend quite recently, definitely happened this year. I am not sure when the first orphaned block found in the main block chain, but may not be this year.

Is it the case that the newly syncronized client will not get the orphaned block but if your client is online during the broadcast of the orphaned block you may get the block and stored them on the local database? I am sorry i am not reading the source code of the client but anyone who is farmilar with it thank you for the reply.

BR

[CIYAM]

Orphan blocks happen fairly regularly (generally only to a depth of 1 and apart from the well known fork problem am not sure if there have been other orphans of greater depth than 1 but it is of course entirely possible).

If your client receives a block that is later orphaned then it will be stored (and AFAIA will not be removed), however, it doesn't cause any problems as these blocks will effectively be ignored once a longer chain has been accepted.

[coldguy]

Orphan blocks happen fairly regularly (generally only to a depth of 1 and apart from the well known fork problem am not sure if there have been other orphans of greater depth than 1 but it is of course entirely possible).

If your client receives a block that is later orphaned then it will be stored (and AFAIA will not be removed), however, it doesn't cause any problems as these blocks will effectively be ignored once a longer chain has been accepted.

Thanks!

I think I have to modify my program to verify if the chain is in order and manually remove the orphaned block. A nice programming pratice anyway.