unsigned char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };

[Dunster]

in main.cpp around line 2,411 in v0.7 we have:

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.
unsigned char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };

What would happen to the blockchain if this was programmed in especially to confuse things? Would it cause a sync problem in the stream?

Just wondering.

Thanks,

Dunster

[kjj]

I don't understand your question.

This is a magic number used to identify the network.

[Dunster]

If you look at the block chain with a hex editor it appears at the start of every block I believe. I'm looking at bool LoadExternalBlockFile(FILE* fileIn) and bool ProcessMessages(CNode* pfrom) in main.cpp to see if an unexpected instance of the pchMessageStart could cause an issue.

[kjj]

If you look at the block chain with a hex editor it appears at the start of every block I believe. I'm looking at bool LoadExternalBlockFile(FILE* fileIn) and bool ProcessMessages(CNode* pfrom) in main.cpp to see if an unexpected instance of the pchMessageStart could cause an issue.

Doesn't look like it, no.

In LoadExternalBlockFile, the most obvious way to mess it up is covered by the code already.  And that way to mess it up is to try to get the parser to skip a valid block by putting in a fake magic number and a size value that would make it miss the start of the real block following.  But the code is already smart enough to avoid that problem by only advancing nPos if it finds a valid block.  If it doesn't find a valid block, it only skips past the few bytes of the fake magic number.

This is only meaningful when the parser is in the "looking for the start of the next block" state.  The magic number has no special meaning inside a block, and since it is only 32 bits, I think there are good odds that some number of blocks include that sequence by random chance already.

Note also that loading external block files is not a common thing.  People should not be loading block files from untrusted sources in the first place.  If someone has the ability to change your block file, you probably have much bigger problems already.

In ProcessMessage, the context is a message, rather than a stream, so the parser doesn't need to be as clever.  It will still mark peers sending bogus block messages as misbehaving and eventually disconnect and ban them.

[Dunster]

Its a very clever piece of software indeed to account for all the naughty vectors.

[jgarzik]

in main.cpp around line 2,411 in v0.7 we have:

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.
unsigned char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };

What would happen to the blockchain if this was programmed in especially to confuse things? Would it cause a sync problem in the stream?

This is known as a magic number.

In bitcoin it performs two primary functions:

1) Guarantee two network nodes belong to the same network.

2) Guarantee blockchain file format matches the active network.

It performs the secondary function of guaranteeing that we are always sync'd on message boundaries in the TCP stream.

[Kinnardian]

How does it do all this?

[TierNolan]

How does it do all this?

All messages start with that sequence.

If you lose "lock" on the stream, it skips until it matches that sequence.

It then reads the standard message from the stream.

int32 magic (already read)
char[12] command
int32 length
int32 checksum
char[length] data

It then runs a sha hash on the data and makes sure it matches the checksum.

This gives a one in 4 billion chance that random data would be detected as a message.

Your data would need to have the magic pattern and then the checksum would match (so actually 4 billion * 4 billion).

Creating a message would be easier though.  However, it only matters if the TCP connection loses lock.  This should only happen for bugged (and some old) clients.

All new clients have that structure for all their packets.

[FPoBA]

Is it possible then to seperate two different chains that share similar Genesis blocks and checkpoints up to a given block?