<p>The <code>rev*.dat</code> 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 <code>blk*.dat</code> files which contain blocks.</p>

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

<ul>
<li>4 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>

<p>For more information about the detailed encodings, see the comments in the Bitcoin Core source code: <a href="https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/serialize.h#L202" rel="noreferrer">CompactSize</a>, <a href="https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/serialize.h#L277" rel="noreferrer">VarInt</a>, <a href="https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/compressor.h#L17" rel="noreferrer">CompressedScript</a>, and <a href="https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/compressor.cpp#L133" rel="noreferrer">CompressedAmount</a>.</p>

CC BY-SA 3.0
2017-08-13T10:47:51.433Z
`A CBlockUndo record consists of a serialized vector of CTxUndo records` what does it mean? For example when size of `CBlockUndo` record = 1 and the record is `00`. In this case dsha256 present in data and not equal to zero. It seems strange
Denis Leonov
CC BY-SA 3.0
2017-08-13T17:09:44.760Z
Read the next sentence.
Pieter Wuille
CC BY-SA 4.0
2023-04-30T02:23:24.060Z
Doesn't CompressedAmount come before CompressedScript?
Vojtěch Strnad
CC BY-SA 3.0
2017-08-12T19:00:57.277Z
2017-08-12T20:42:54.833Z
2017-08-12T20:42:54.833Z
Pieter Wuille
<p>Can anyone help me to find out the format of <code>rev*.dat</code> file?</p>

<p>There is an array with [<code>F9BEB4D9</code> + <code>32byte number</code> + <code>variable raw data</code>] for each element.</p>

<p>What is that 32b number? And may be how to understand what is the other variable data?</p>

<bitcoin-core><blockchain><undofiles>
File format -- rev*.dat
Denis Leonov
# File format -- rev*.dat

(Asked by: username_0 on 2017-08-12)

Can anyone help me to find out the format of `rev*.dat` file?

There is an array with [`F9BEB4D9` + `32byte number` + `variable raw data`] for each element.

What is that 32b number? And may be how to understand what is the other variable data?

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


---

## 1 answers

### Answer by username_1 on 2017-08-12. Score: 12 | Accepted answer

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:

* 4 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.

For more information about the detailed encodings, see the comments in the Bitcoin Core source code: [CompactSize](https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/serialize.h#L202), [VarInt](https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/serialize.h#L277), [CompressedScript](https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/compressor.h#L17), and [CompressedAmount](https://github.com/bitcoin/bitcoin/blob/v0.14.2/src/compressor.cpp#L133).

> **Comments:**
> **username_0**: `A CBlockUndo record consists of a serialized vector of CTxUndo records` what does it mean? For example when size of `CBlockUndo` record = 1 and the record is `00`. In this case dsha256 present in data and not equal to zero. It seems strange  
> **username_1**: Read the next sentence.  
> **username_2**: Doesn't CompressedAmount come before CompressedScript?  

---

