yes, sure, it's not important. I find out this problem when i read every blockhead into memory and sort by nTime.
I suppose it's a fast way to retrieve the chain. Yesterday, i find wrong time, just in few minutes.
But today, I find out the block# 301596, the nTime is wrong more than 3 hours.

I think we should resolve this later,  how about some miner give a nTime = 2030year  tomorrow.
ofcouse , It's doesn't matter, but just look a little bit ugly.

I do not agree that.
If bitcoin die off in 2018, it's doesn't matter what kind coin do you have ,  every coin will die.

I find out that more than 2% block Timestamp(nTime) is wrong.

for example:
Block#501251  Timestamp 2017-12-27 10:34:56
Block#501252  Timestamp 2017-12-27 10:34:39

I think more than 2% is too lot.
Should we design some protocol let every miner use correct time?

Thanks!

when i use 'b' + block hash as a key search the leveldb,  i can not figure out the struct of values.

for exmaple:
search 'b' + "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"       //  Block #0

value 88bytes:
889271000b010008010000000000000000000000000000000000000000000000000000000000000 0000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f 49ffff001d1dac2b7c

i know the last 80bytes is the block header,  but the first 8bytes , i do not known what it is?
"889271000b010008"

plz tell me the struct or tell me which .cpp contain the struct, thanks a lot!

bool CScriptCompressor::Decompress(unsigned int nSize, const std::vector<unsigned char> &in)
{
    switch(nSize) {
    case 0x00:
        script.resize(25);
        script[0] = OP_DUP;
        script[1] = OP_HASH160;
        script[2] = 20;
        memcpy(&script[3], in.data(), 20);
        script[23] = OP_EQUALVERIFY;
        script[24] = OP_CHECKSIG;
        return true;
    case 0x01:
        script.resize(23);
        script[0] = OP_HASH160;
        script[1] = 20;
        memcpy(&script[2], in.data(), 20);
        script[22] = OP_EQUAL;
        return true;
    case 0x02:
    case 0x03:
        script.resize(35);
        script[0] = 33;
        script[1] = nSize;
        memcpy(&script[2], in.data(), 32);
        script[34] = OP_CHECKSIG;
        return true;
    case 0x04:
    case 0x05:
        unsigned char vch[33] = {};
        vch[0] = nSize - 2;
        memcpy(&vch[1], in.data(), 32);
        CPubKey pubkey(&vch[0], &vch[33]);
        if (!pubkey.Decompress())
            return false;
        assert(pubkey.size() == 65);
        script.resize(67);
        script[0] = 65;
        memcpy(&script[1], pubkey.begin(), 65);
        script[66] = OP_CHECKSIG;
        return true;
    }
    return false;
}


I know a common TX is a UTXO,  in case 0x00:
push/out/op following in stack.
SIG, PUBkey, OP_DUP, OP_HASH160, ADDRESS,  OP_EQUALVERIFY, OP_CHECKSIG.
that meaning is
OP_DUP, copy PUBKEY
OP_HASH160, calculate this pubkey's address
OP_EQUALVERIFY, make sure this pubkey's address equal sender's address
OP_CHECKSIG, make sure SIG correct

but , i do not understand case 0x01:
I think there less a op_checksig?
is that meaning everyone can do spend another one's bitcoin, because do not need OP_CHECKSIG.

and aslo i do not understand case 0x02,03, 04,05 ??
what is it designed for ?

Thanks a lot!

Thank you

I am a new one studying bitcoin source. I think that maybe writing a blockchain parser is first step. I realize that every blk00000.dat is different.  I got 2 different blk00000.dat.  I compared the files as below.

You can see the Magic Number, Size, Version, and the PreHash are different.
I had read https://github.com/bitcoin/bitcoin/issues/6613, but I am still confused.
If there is a key to XOR to make difference, why the blocks before do not XOR? And obviously, Magic Number, Size, Version do not XOR, which field will be XOR?

Thanks a lot!!!!