0

This is the source code snippet that is used for the serialization of block indexes (found in leveldb).

Block 478573 index is (as of my node's leveldb) 89af109c996d020000000020774f568005a00bf4ffed76b52e3a7e5e5140a5371834a00000000000000000009f5db27969fecc0ef71503279069b2df981ba545592a7b425f353b5060e77f3e7e13825935470118da70378e

Isn't NFile undefined (i.e. 0) in this case? (and NDataPos and NUndoPos too).

Whereas for block 478574 it is :

89af109c996e1d801886399fbf8017828daf5502000020dcc139c241e6315463dd82c89fc288de35f004c87816430000000000000000000f7f9503fc2daab46c4103516c386b1c5b2390e082af76ba8c49fb522d5e5b148b96805935470118ae6ba061

Which yields NFile = 953 and is correct.

Why block 478573 is not defined? And how to retrieve NFile and NDataPos in that case? I understand that the index is different for every node because it depends on the order the blocks were downloaded.

  • What do you mean by undefined? Zero? – Pieter Wuille Jun 28 at 15:58
  • Yes I meant zero – Kevin P Jun 28 at 17:14
0

This is likely the case because you don't have the block.

Blocks are downloaded out of order, and the block index contains entries for blocks that are not in the main chain ("orphan blocks"). Many of those are clearly not in the best chain before they're even downloaded, in which case Bitcoin Core will not download them at all.

  • Very clear, thanks! I thought the block index contained only the main chain. – Kevin P Jun 28 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.