<p>I found a similar question <a href="https://bitcoin.stackexchange.com/questions/57978/file-format-rev-dat">here</a>:</p>

<p>so I just Reprinted:</p>

<p>The rev*.dat files (the "undo files"), contain all UTXOs spent by the inputs of a block. It was introduced in Bitcoin Core 0.8, and contains a concatenation of records, one for each block. This mimicks the structure of the blk*.dat files which contain blocks.</p>

<p>Each block record consists of:</p>

<ul>
<li>bytes: network magic (0xf9,0xbe,0xb4,0xd9)</li>
<li>4 bytes: size of the CBlockUndo record (LE32)</li>
<li>data_size bytes: CBlockUndo record</li>
<li>32 bytes: double-SHA256 of the serialized CBlockUndo record</li>
</ul>

<p>A CBlockUndo record consists of a serialized vector of CTxUndo records, one for each transaction in the block excluding the coinbase transaction. Vector serialization first writes a CompactSize-encoded length of the number of records (the transaction count - 1, in this case), and then serialized all the records themselves sequentially.</p>

<p>A CTxUndo record consists of a serialized vector of CTxInUndo records, one for each input in the transaction.</p>

<p>A CTxInUndo record consists of:</p>

<ul>
<li>varint: 2*height (+1 if it was a coinbase output): the height of the block that created the spent UTXO</li>
<li>varint: creating transaction's version [only when height > 0]</li>
<li>CompressedScript: spent UTXO's scriptPubKey</li>
<li>CompressedAmount: spent UTXO's nValue</li>
</ul>

<p>Until Bitcoin Core 0.14.x, the height is zero for all but the last output of a given transaction being spent. In Bitcoin Core 0.15 (to be released soon), it will be present for every spend.</p>

CC BY-SA 3.0
2018-02-18T09:07:55.683Z
Welcome to Bitcoin.SE! You can help the site by marking your answer as accepted so that the question does not remain as "unanswered". Note that the release version information in your answer is outdated, it is v0.16 that is to be released soon.
Willtech
CC BY-SA 3.0
2018-02-18T08:54:27.390Z
2018-02-18T08:54:27.390Z
memorybox
<p>I see block chain is stored basically <a href="https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage" rel="nofollow noreferrer">four pieces</a> of data that are maintained:</p>

<ul>
<li>blocks/blk*.dat:</li>
</ul>

<p>the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.</p>

<ul>
<li>blocks/index/*: </li>
</ul>

<p>this is a LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.</p>

<ul>
<li>chainstate/*: </li>
</ul>

<p>this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. </p>

<ul>
<li>blocks/rev*.dat:</li>
</ul>

<p>these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations. </p>

<p>But I still don't understand how <strong>rev*.dat</strong> work. Can somebody explain in detail how to use them?</p>

CC BY-SA 4.0
2023-04-12T14:26:19.980Z
Does this answer your question? [File format -- rev\*.dat](https://bitcoin.stackexchange.com/questions/57978/file-format-rev-dat)
Amir reza Riahi
<blockchain><database>
What's raw undo data for?
memorybox
# What's raw undo data for?

(Asked by: username_0 on 2018-02-17)

I see block chain is stored basically [four pieces](https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage) of data that are maintained:

* blocks/blk\*.dat:

the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.

* blocks/index/\*:

this is a LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.

* chainstate/\*:

this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from.

* blocks/rev\*.dat:

these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations.

But I still don't understand how **rev\*.dat** work. Can somebody explain in detail how to use them?

**Tags:** blockchain, database

> **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_0 on 2018-02-18. Score: 2 | Accepted answer

I found a similar question [here](https://bitcoin.stackexchange.com/questions/57978/file-format-rev-dat):

so I just Reprinted:

The rev\*.dat files (the "undo files"), contain all UTXOs spent by the inputs of a block. It was introduced in Bitcoin Core 0.8, and contains a concatenation of records, one for each block. This mimicks the structure of the blk\*.dat files which contain blocks.

Each block record consists of:

* bytes: network magic (0xf9,0xbe,0xb4,0xd9)
* 4 bytes: size of the CBlockUndo record (LE32)
* data\_size bytes: CBlockUndo record
* 32 bytes: double-SHA256 of the serialized CBlockUndo record

A CBlockUndo record consists of a serialized vector of CTxUndo records, one for each transaction in the block excluding the coinbase transaction. Vector serialization first writes a CompactSize-encoded length of the number of records (the transaction count - 1, in this case), and then serialized all the records themselves sequentially.

A CTxUndo record consists of a serialized vector of CTxInUndo records, one for each input in the transaction.

A CTxInUndo record consists of:

* varint: 2\*height (+1 if it was a coinbase output): the height of the block that created the spent UTXO
* varint: creating transaction's version [only when height > 0]
* CompressedScript: spent UTXO's scriptPubKey
* CompressedAmount: spent UTXO's nValue

Until Bitcoin Core 0.14.x, the height is zero for all but the last output of a given transaction being spent. In Bitcoin Core 0.15 (to be released soon), it will be present for every spend.

> **Comments:**
> **username_2**: Welcome to Bitcoin.SE! You can help the site by marking your answer as accepted so that the question does not remain as "unanswered". Note that the release version information in your answer is outdated, it is v0.16 that is to be released soon.  

---

