<p>The problem is that a transaction input only identifies which TXO is spent per their <em>outpoint</em>, 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 <em>amount</em> and <em>output script</em> 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 <code>txindex</code> to be able to look them up in the appropriate block files).</p>
<p>Either way, having a copy of the pertinent TXO data is way more efficient in the case of a reorg.</p>

CC BY-SA 4.0
2023-04-12T23:31:48.913Z
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.
Pieter Wuille
CC BY-SA 4.0
2023-04-12T19:58:48.103Z
2023-10-12T15:58:27.173Z
2023-10-12T15:58:27.173Z
Murch
<p>Undo files contain data needed to disconnect a block from the blockchain. It basically contains instances of <a href="https://github.com/bitcoin/bitcoin/blob/fa488f131fd4f5bab0d01376c5a5013306f1abcd/src/undo.h#L63" rel="nofollow noreferrer"><code>CBlockUndo</code></a>:</p>
<pre><code>/** Undo information for a CBlock */
class CBlockUndo
{
public:
    std::vector&lt;CTxUndo&gt; vtxundo; // for all but the coinbase

    SERIALIZE_METHODS(CBlockUndo, obj) { READWRITE(obj.vtxundo); }
};
</code></pre>
<p><a href="https://github.com/bitcoin/bitcoin/blob/fa488f131fd4f5bab0d01376c5a5013306f1abcd/src/undo.h#L53" rel="nofollow noreferrer"><code>CTxUndo</code></a>:</p>
<pre><code>/** Undo information for a CTransaction */
class CTxUndo
{
public:
    // undo information for all txins
    std::vector&lt;Coin&gt; vprevout;

    SERIALIZE_METHODS(CTxUndo, obj) { READWRITE(Using&lt;VectorFormatter&lt;TxInUndoFormatter&gt;&gt;(obj.vprevout)); }
};
</code></pre>
<p>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:</p>
<ul>
<li>Removing the transaction outputs from the UTXO set</li>
<li>Restoring the inputs as UTXO (restoring the UTXOs that are spent in the transaction)</li>
</ul>
<p>If I'm correct, I can't understand the need behind having undo files.</p>

<bitcoin-core-development><undofiles>
Why are undo files needed in Bitcoin Core?
Amir reza Riahi
# Why are undo files needed in Bitcoin Core?

(Asked by: username_0 on 2023-04-12)

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
{
public:
    std::vector vtxundo; // for all but the coinbase

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

CTxUndo:
/** Undo information for a CTransaction */
class CTxUndo
{
public:
    // undo information for all txins
    std::vector vprevout;

    SERIALIZE_METHODS(CTxUndo, obj) { READWRITE(Using>(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.

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


---

## 1 answers

### Answer by username_1 on 2023-04-12. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_2**: 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.  

---

