2

I understand that blk*.dat files save the blocks in the order it gets them from it's peers. Is the rev*.dat files in the same order as the blk*.dat files?

For example, would the 400th magicbyte in the blk00000.dat file be representative of the same block as the 400th magicbyte in the rev00000.dat file?

  • That question doesn't tell whether the blk*.dat file and the blk*.rev files have the same block ordering. For background info, blk*.dat doesn't store the blocks in order. If you read the blk*.dat file sequentially, it might go from block height 3000 then give you height 3130. – kcalvinalvin Dec 5 '19 at 9:55
  • you have right, sorry me! – vincenzopalazzo Dec 5 '19 at 10:31
  • 1
    Does this answer your question? File format -- rev*.dat – chytrik Dec 7 '19 at 23:19
3

No.

Block data is written (appended to) blk*.dat files whenever a block is received from the network (assuming things like PoW and a few other sanity checks pass). As blocks are received in parallel from multiple peers, their order on disk ends up being chaotic.

Undo data is written when a block gets fully validated. As full validation requires validation of all parent blocks first, the order of undo records tends to be much more monotonic. However, it is not guaranteed to be be perfectly continuous either, as reorganizations can cause discrepancies. If a received block never ends up being part of the active chain, it will never have an undo record, despite the block data being present.

The only guarantee is that block data and undo data is stored in matching files (e.g. a block which is stored in blk00473.dat will have its undo data in rev00473.dat).

|improve this answer|||||
  • Follow up question: so does that mean that rev*.dat files have no size limit? – kcalvinalvin Dec 6 '19 at 1:38
  • 1
    I guess there is a theoretical limit (a block can have at most 24387 inputs, and each could spend a with-miner-help-specially-crafted 10 kB UTXO, so around 240 MB). Beyond that, indeed not really. – Pieter Wuille Dec 6 '19 at 2:22
  • There is perhaps a more relevant constraint: the sum of sizes of all undo data up to block X cannot exceed the size of the blockchain up to block X, as the undo data contains spent UTXOs, which must have been created before at some point. – Pieter Wuille Dec 6 '19 at 2:25
  • One more question. If bitcoin-core were to reorg to block 601,000, does it ask leveldb where to find the relevant info from rev*.dat? – kcalvinalvin Dec 6 '19 at 5:56
  • The blocks/index database stores metadata about every block, includes where and in which file its block and undo is stored. That database is loaded into memory at startup though, so there isn't any need to query LevelDB itself at runtime. – Pieter Wuille Dec 6 '19 at 6:00

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.