What's raw undo data for?

Question

I see block chain is stored basically four pieces 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?

Answer 1

I found a similar question here:

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.