What are the first 4 bytes in a block?

[Jet Cash]

I've read one description, and it says this -
Version    Block version number    You upgrade the software and it specifies a new version

Another one says this
Magic no    value always 0xD9B4BEF9    4 bytes

Obviously if it is a version number, there is scope for a rules description which specifies different block sizes for example 256k, 512k, 1Mb, 2Mb etc.

[1714856851]

1714856851

[1714856851]

1714856851

[1714856851]

1714856851

[1714856851]

1714856851

[1714856851]

1714856851

[CIYAM]

There is a version number but your point is?

(it seems you have very little understanding about Bitcoin but think that you should create posts recommending how it should be changed)

It is a bit like someone who doesn't even know what a "piston" is advising people how to "hot rod" their cars. There is plenty of online information about Bitcoin for you to research if you actually want to know how it works.

(but until you've gone through the effort to actually understand it please stop trying to offer your suggestions about how it should be changed)

[achow101]

The first four bytes are the version bytes.

The magic bytes are only for networking and they prepend every single message sent over the network. Those are just identifier bytes to identify that the message is for bitcoin.

You should consider reading all of the documentation on bitcoin.org.

[DannyHamilton]

The first four bytes are the version bytes.

The magic bytes are only for networking and they prepend every single message sent over the network. Those are just identifier bytes to identify that the message is for bitcoin.

Actually...

Code:

$ head -c 300 blk00000.dat |hexdump -C
00000000  f9 be b4 d9 1d 01 00 00  01 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 3b a3 ed fd  |............;...|
00000030  7a 7b 12 b2 7a c7 2c 3e  67 76 8f 61 7f c8 1b c3  |z{..z.,>gv.a....|
00000040  88 8a 51 32 3a 9f b8 aa  4b 1e 5e 4a 29 ab 5f 49  |..Q2:...K.^J)._I|
00000050  ff ff 00 1d 1d ac 2b 7c  01 01 00 00 00 01 00 00  |......+|........|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 ff ff  |................|
00000080  ff ff 4d 04 ff ff 00 1d  01 04 45 54 68 65 20 54  |..M.......EThe T|
00000090  69 6d 65 73 20 30 33 2f  4a 61 6e 2f 32 30 30 39  |imes 03/Jan/2009|
000000a0  20 43 68 61 6e 63 65 6c  6c 6f 72 20 6f 6e 20 62  | Chancellor on b|
000000b0  72 69 6e 6b 20 6f 66 20  73 65 63 6f 6e 64 20 62  |rink of second b|
000000c0  61 69 6c 6f 75 74 20 66  6f 72 20 62 61 6e 6b 73  |ailout for banks|
000000d0  ff ff ff ff 01 00 f2 05  2a 01 00 00 00 43 41 04  |........*....CA.|
000000e0  67 8a fd b0 fe 55 48 27  19 67 f1 a6 71 30 b7 10  |g....UH'.g..q0..|
000000f0  5c d6 a8 28 e0 39 09 a6  79 62 e0 ea 1f 61 de b6  |\..(.9..yb...a..|
00000100  49 f6 bc 3f 4c ef 38 c4  f3 55 04 e5 1e c1 12 de  |I..?L.8..U......|
00000110  5c 38 4d f7 ba 0b 8d 57  8a 4c 70 2b 6b f1 1d 5f  |\8M....W.Lp+k.._|
00000120  ac 00 00 00 00 f9 be b4  d9 d7 00 00              |............|
0000012c

Above, you'll see the very first block in the blockchain as well as the first 7 bytes of the second block.

You'll notice that both the magic number:

00000000  f9 be b4 d9 1d 01 00 00  01 00 00 00 00 00 00 00

and the size of the block:

00000000  f9 be b4 d9 1d 01 00 00  01 00 00 00 00 00 00 00

are stored on disk.

To some extent it's up to interpretation as to whether these two values are "part of the block" or just delimiters between blocks with meta information about the following block.  Note that neither of these two values have any influence on the portion of the block header that is hashed.

The first part of the block that is actually hashed is the version number:

00000000  f9 be b4 d9 1d 01 00 00  01 00 00 00 00 00 00 00

Obviously if it is a version number, there is scope for a rules description which specifies different block sizes for example 256k, 512k, 1Mb, 2Mb etc.

And how exactly would that work?  If the current version doesn't know anything about the future versions, then how will it know what to do when it sees a different block version number?  How will it know if the block size is valid or not?

[achow101]

-snip-

If we define a block as the payload of a block message, then that is not true. The payload of the serialized format of the blocks excludes the magic bytes and the size. Those extra meta data help to delimit the blocks in the local blk files. However the actual block sent in the payload of a block message does not include that data.

[DannyHamilton]

- snip -
If we define a block as the payload of a block message, then that is not true.  The payload of the serialized format of the blocks excludes the magic bytes and the size.

And if we define a block as the bytes that are added to the disk upon receiving and validating a proof-of-work, then the magic number and block size ARE part of the block.

Those extra meta data help to delimit the blocks in the local blk files.
- snip -

As I already said:

- snip -
To some extent it's up to interpretation as to whether these two values are "part of the block" or just delimiters between blocks with meta information about the following block.
- snip -

See here:

https://en.bitcoin.it/wiki/Block

Field	Description	Size
Magic no	value always 0xD9B4BEF9	4 bytes
Blocksize	number of bytes following up to end of block	4 bytes
Blockheader	consists of 6 items	80 bytes
Transaction counter	positive integer VI = VarInt	1 - 9 bytes
transactions	the (non empty) list of transactions	<Transaction counter>-many transactions

[achow101]

- snip -
If we define a block as the payload of a block message, then that is not true.  The payload of the serialized format of the blocks excludes the magic bytes and the size.

And if we define a block as the bytes that are added to the disk upon receiving and validating a proof-of-work, then the magic number and block size ARE part of the block.

Those extra meta data help to delimit the blocks in the local blk files.
- snip -

As I already said:

- snip -
To some extent it's up to interpretation as to whether these two values are "part of the block" or just delimiters between blocks with meta information about the following block.
- snip -

See here:

https://en.bitcoin.it/wiki/Block

Field	Description	Size
Magic no	value always 0xD9B4BEF9	4 bytes
Blocksize	number of bytes following up to end of block	4 bytes
Blockheader	consists of 6 items	80 bytes
Transaction counter	positive integer VI = VarInt	1 - 9 bytes
transactions	the (non empty) list of transactions	<Transaction counter>-many transactions

Sorry, I meant to say that the definition of a block according to network is the payload of the block message. The format in the disk is implementation specific, but the network messages are not, those are consensus network things. Therefore the definition of a block is the payload of the network wide message, not the implementation specific bytes written to the disk.

[Moloch]

The 'magic number' is just an identifier indicating the beginning of a new block...

For bitcoin, the number is: 0xD9B4BEF9 (3652501241)
For litecoin, it would be: 0xDBB6C0FB (3686187259)

Though, I'm unsure why it is reversed from the code:

Code:

        /** 
         * The message start string is designed to be unlikely to occur in normal data.
         * The characters are rarely used upper ASCII, not valid as UTF-8, and produce
         * a large 4-byte int at any alignment.
         */
        pchMessageStart[0] = 0xf9;
        pchMessageStart[1] = 0xbe;
        pchMessageStart[2] = 0xb4;
        pchMessageStart[3] = 0xd9;

[achow101]

The 'magic number' is just an identifier indicating the beginning of a new block...

For bitcoin, the number is: 0xD9B4BEF9 (3652501241)
For litecoin, it would be: 0xDBB6C0FB (3686187259)

No, not the beginning a new block, but the beginning of any network message. It identifies the coin that message that it is for. The magic bytes are not exclusively a part of the block, and are not part of the serialized block format.

[Moloch]

No, not the beginning a new block, but the beginning of any network message. It identifies the coin that message that it is for. The magic bytes are not exclusively a part of the block, and are not part of the serialized block format.

Except that when I open my blocks.dat file with a hex editor... it IS part of the block (as pictured a few posts above by DannyHamilton)

I suppose you are saying that it shouldn't be there, or that its not checked/verified as part of the block?  I'm not sure the technical details, but I've seen it in the blocks.dat file with my own eyes

[achow101]

No, not the beginning a new block, but the beginning of any network message. It identifies the coin that message that it is for. The magic bytes are not exclusively a part of the block, and are not part of the serialized block format.

Except that when I open my blocks.dat file with a hex editor... it IS part of the block (as pictured a few posts above by DannyHamilton)

It is not exclusively used by blocks and there is no consensus definition of a block which includes the magic bytes in the block. As I said earlier, they are implementation specific, so it cannot be used as the general definition of a block. The definition that is not implementation specific is the serialized block format described here: https://bitcoin.org/en/developer-reference#serialized-blocks. That format is what is sent in the payload of the block message, and that is the consensus definition of a block. When you submit a block to the network, you do not send the magic bytes, that is an invalid block. You send just the serialized block format starting with the block version.

[fbueller]

Versions can change over time, so they use something fixed (the magic bytes) to prefix the next block.