<p>No.</p>

<p>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.</p>

<p>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.</p>

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

CC BY-SA 4.0
2019-12-06T01:38:26.790Z
Follow up question: so does that mean that rev*.dat files have no size limit?
kcalvinalvin
CC BY-SA 4.0
2019-12-06T02:22:47.740Z
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
CC BY-SA 4.0
2019-12-06T02:25:54.157Z
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
CC BY-SA 4.0
2019-12-06T05:56:25.563Z
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
CC BY-SA 4.0
2019-12-06T06:00:26.900Z
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
CC BY-SA 4.0
2019-12-06T00:59:21.937Z
2019-12-06T00:59:21.937Z
Pieter Wuille
<p>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?</p>

<p>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?</p>

CC BY-SA 4.0
2019-12-07T23:19:42.180Z
Does this answer your question? [File format -- rev\*.dat](https://bitcoin.stackexchange.com/questions/57978/file-format-rev-dat)
chytrik
<bitcoin-core><blockchain><block><undofiles>
Is the ordering of blocks in the rev*.dat files same as the blk*.dat files?
kcalvinalvin
# Is the ordering of blocks in the rev*.dat files same as the blk*.dat files?

(Asked by: username_0 on 2019-12-05)

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?

**Tags:** bitcoin-core, blockchain, block, undofiles

> **Comments:**
> **username_1**: Does this answer your question? [File format -- rev\*.dat](https://bitcoin.stackexchange.com/questions/57978/file-format-rev-dat)  

---

## 1 answers

### Answer by username_2 on 2019-12-06. Score: 4 | Accepted answer

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

> **Comments:**
> **username_0**: Follow up question: so does that mean that rev*.dat files have no size limit?  
> **username_2**: 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.  
> **username_2**: 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.  
> **username_0**: 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?  
> **username_2**: 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.  

---

