1

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?

0

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.

  • 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 Feb 18 '18 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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