<blockquote>
<p>Firstly, why don't the CTxInUndo records contain any mention of the parent TXID of the outputs used? Won't this information be needed to insert these outputs back into the chainstate as UTXOs? How is the chainstate restored using only the information contained in these records?</p>
</blockquote>
<p>The block itself is also used in the undo operation. It lists the UTXOs (by txid and output index) which are being spent. The undo files contain the contents of those spent UTXOs in the same order.</p>
<blockquote>
<p>Secondy, what about the outputs created by the transactions of this block? Since they should be removed from chainstate after a re-org, why are there no records for them in the undo files?</p>
</blockquote>
<p>This information is also extracted from the block data, as it lists the transactions, so the txids of UTXOs that need to be removed in a rollback can be computed from that.</p>
<blockquote>
<p>Lastly, why is the height in the CTxInUndo record stored as 2*height (+1 if it was a coinbase output) and not just height? Is the shift by a bit used to store if the transaction was coinbase or not?</p>
</blockquote>
<p>UTXOs store the following information for each entry:</p>
<ul>
<li>The txid that created it</li>
<li>The output index in the tx that created it</li>
<li>The scriptPubKey</li>
<li>The amount</li>
<li>The height it was created at (to be able to enforce relative timelocks)</li>
<li>Whether or not the tx that created it was a coinbase transaction (because the special maturity rules that apply to spending coinbase outputs).</li>
</ul>
<p>These last two items need to be stored in the undo data, as they cannot be inferred from the spending transaction.</p>
<p>The encoding used is to store the height and coinbaseness as a single number (2*height + coinbase), so it only takes up minimal space in the database.</p>

CC BY-SA 4.0
2021-11-14T15:34:47.227Z
2021-11-14T17:32:02.690Z
2021-11-14T17:32:02.690Z
Pieter Wuille
<p>It is obvious that the undo files (rev*.dat files) are stored to restore the blockchain to a previous version when a re-org takes place. What is not clear to me is what are the exact uses of the contents of these files.</p>
<p>I am basing my questions off of <a href="https://bitcoin.stackexchange.com/a/57981/128730">this answer</a> explaining the contents of the undo files and <a href="https://bitcoin.stackexchange.com/a/29418/128730">this answer</a> explaining thoroughly the structure of the chainstate database.</p>
<p>Firstly, why don't the CTxInUndo records contain any mention of the parent TXID of the outputs used? Won't this information be needed to insert these outputs back into the chainstate as UTXOs? How is the chainstate restored using only the information contained in these records?</p>
<p>Secondy, what about the outputs created by the transactions of this block? Since they should be removed from chainstate after a re-org, why are there no records for them in the undo files?</p>
<p>Lastly, why is the height in the CTxInUndo record stored as <code>2*height (+1 if it was a coinbase output)</code> and not just <code>height</code>? Is the shift by a bit used to store if the transaction was coinbase or not?</p>

<storage><chain-reorganization>
How exactly are the undo files used when a re-org takes place?
FrozoWeb
# How exactly are the undo files used when a re-org takes place?

(Asked by: username_0 on 2021-11-14)

It is obvious that the undo files (rev\*.dat files) are stored to restore the blockchain to a previous version when a re-org takes place. What is not clear to me is what are the exact uses of the contents of these files.

I am basing my questions off of [this answer](https://bitcoin.stackexchange.com/a/57981/128730) explaining the contents of the undo files and [this answer](https://bitcoin.stackexchange.com/a/29418/128730) explaining thoroughly the structure of the chainstate database.

Firstly, why don't the CTxInUndo records contain any mention of the parent TXID of the outputs used? Won't this information be needed to insert these outputs back into the chainstate as UTXOs? How is the chainstate restored using only the information contained in these records?

Secondy, what about the outputs created by the transactions of this block? Since they should be removed from chainstate after a re-org, why are there no records for them in the undo files?

Lastly, why is the height in the CTxInUndo record stored as `2*height (+1 if it was a coinbase output)` and not just `height`? Is the shift by a bit used to store if the transaction was coinbase or not?

**Tags:** storage, chain-reorganization


---

## 1 answers

### Answer by username_1 on 2021-11-14. Score: 2 | Accepted answer

> Firstly, why don't the CTxInUndo records contain any mention of the parent TXID of the outputs used? Won't this information be needed to insert these outputs back into the chainstate as UTXOs? How is the chainstate restored using only the information contained in these records?

The block itself is also used in the undo operation. It lists the UTXOs (by txid and output index) which are being spent. The undo files contain the contents of those spent UTXOs in the same order.

> Secondy, what about the outputs created by the transactions of this block? Since they should be removed from chainstate after a re-org, why are there no records for them in the undo files?

This information is also extracted from the block data, as it lists the transactions, so the txids of UTXOs that need to be removed in a rollback can be computed from that.

> Lastly, why is the height in the CTxInUndo record stored as 2\*height (+1 if it was a coinbase output) and not just height? Is the shift by a bit used to store if the transaction was coinbase or not?

UTXOs store the following information for each entry:

* The txid that created it
* The output index in the tx that created it
* The scriptPubKey
* The amount
* The height it was created at (to be able to enforce relative timelocks)
* Whether or not the tx that created it was a coinbase transaction (because the special maturity rules that apply to spending coinbase outputs).

These last two items need to be stored in the undo data, as they cannot be inferred from the spending transaction.

The encoding used is to store the height and coinbaseness as a single number (2\*height + coinbase), so it only takes up minimal space in the database.


---

