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?


1 Answer 1



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).

  • Follow up question: so does that mean that rev*.dat files have no size limit? Commented Dec 6, 2019 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. Commented Dec 6, 2019 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. Commented Dec 6, 2019 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? Commented Dec 6, 2019 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. Commented Dec 6, 2019 at 6:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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