Undo files contain data needed to disconnect a block from the blockchain. It basically contains instances of CBlockUndo:

/** Undo information for a CBlock */
class CBlockUndo
    std::vector<CTxUndo> vtxundo; // for all but the coinbase

    SERIALIZE_METHODS(CBlockUndo, obj) { READWRITE(obj.vtxundo); }


/** Undo information for a CTransaction */
class CTxUndo
    // undo information for all txins
    std::vector<Coin> vprevout;

    SERIALIZE_METHODS(CTxUndo, obj) { READWRITE(Using<VectorFormatter<TxInUndoFormatter>>(obj.vprevout)); }

From my understanding, it's only a wrapper over the spent coins and it has no extra information regarding to the actual block. On the other hand, as far as I can see, undoing a block needs undoing all transactions the block contains. And to undo a transaction we need to perform two thing:

  • Removing the transaction outputs from the UTXO set
  • Restoring the inputs as UTXO (restoring the UTXOs that are spent in the transaction)

If I'm correct, I can't understand the need behind having undo files.

1 Answer 1


The problem is that a transaction input only identifies which TXO is spent per their outpoint, but does not repeat the details of the TXO. Therefore, the information in the block is insufficient to reinstate the UTXOs that got consumed by the transactions in the block—we’d have to go back and find each transaction that created UTXOs to rediscover the amount and output script of the UTXOs to be recreated, just so we can consume most of them moments later when we apply the transactions included in the new best chaintip. In the case of a pruned node, we might not even have those transactions anymore, but even for nodes with a full blockchain these lookups would be quite expensive (I assume it would require either scanning the whole blockchain for all of the transactions, or having a txindex to be able to look them up in the appropriate block files).

Either way, having a copy of the pertinent TXO data is way more efficient in the case of a reorg.

  • 1
    Also, in the case of a pruning node, the spent UTXO data may just not exist anymore, if the block that created the output was before the prune point, but the spending happened after. Apr 12 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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