<p>Each node considers the <em>valid</em> chaintip with the <em>most-work</em> that it knows about the canonical state of the network. Only this &quot;best chain&quot; matters to establish the state of the UTXO set. If another chaintip overtakes the prior best chain, the node reverts blocks until it arrives at the highest common previous block and then applies the new chain.</p>
<p>The nodes only need to assess the header of the block. Each block mentions its predecessor in the header, so the node can see where a block attaches to the blockchain. If a new block header is not leading to a better chaintip, nodes will not even retrieve the block. Pieter recently wrote a <a href="https://bitcoin.stackexchange.com/a/121293/5406">detailed description of how block synchronization works today</a>, if you want to understand the process in more depth.</p>
<p>Of course a miner could extend whatever chaintip they want, however not only are stale chaintips easy to identify, the miners will also lose money on doing so:<br />
The best chain is a single-file connection between Genesis block and the best chaintip. Every block has exactly one predecessor and you can only spend coinbase transaction outputs (i.e. the mining reward) when they have 100 confirmations. Stale chaintips are not part of that best chain, and therefore the block rewards are paid to outputs that don’t exist in the best chain. Mining on top of invalid blocks costs you the same effort, but nets you zero revenue.</p>

CC BY-SA 4.0
2024-01-22T20:03:15.547Z
Ah right, thanks, that makes sense. But wouldn't that mean blocks can't be published with previous blocks on invalid chaintips? Does that restrict miners to only publishing blocks on the chain that the node considers the longest?
Shay
CC BY-SA 4.0
2024-01-22T20:25:59.777Z
Any miner can extend whatever chaintip they want, it’s just that if their block isn’t part of the best chain in the long run, they’ll find it hard to sell their mining reward, because the output doesn’t exist in the best chain. The best chain is single-file, every block has exactly one predecessor and you can only spend coinbase transaction outputs when they have 100 confirmations. Mining on top of invalid blocks costs you the same effort, but nets you zero.
Murch
CC BY-SA 4.0
2024-01-22T22:45:57.463Z
So if miners extend a shorter length chain, would I have to search UTXOs on that "branch" to see if their block is valid instead of using the UTXO set? Since surely the UTXO set the node has stored would just be valid for the longest chain.
Shay
CC BY-SA 4.0
2024-01-23T00:38:48.453Z
@Shay Your node will only download the headers of this new branch unless it actually is a (candidate) best block. Once the branch is extended long enough to potentially overtake (or at least tie with) the current best block in terms of work, it is downloaded and partially validated. The actual *full* validation that involves the UTXO set is only performed if it would actually be the best chain. See my answer here for more depth: https://bitcoin.stackexchange.com/a/121293/208
Pieter Wuille
CC BY-SA 4.0
2024-01-22T18:49:59.217Z
2024-01-27T13:18:35.070Z
2024-01-27T13:18:35.070Z
Murch
<p>If there are &quot;fork&quot; chains coming off a block, how do we keep track of the UTXOs of different public keys?</p>
<p>Would I just store UTXOs derived from the longest chain and recalculate if another &quot;branch&quot; becomes longer than this chain?</p>

<block><blockchain-fork><utxo><utxo-set>
When chains branch, are there multiple UTXO sets?
Shay
# When chains branch, are there multiple UTXO sets?

(Asked by: username_0 on 2024-01-22)

If there are "fork" chains coming off a block, how do we keep track of the UTXOs of different public keys?

Would I just store UTXOs derived from the longest chain and recalculate if another "branch" becomes longer than this chain?

**Tags:** block, blockchain-fork, utxo, utxo-set


---

## 1 answers

### Answer by username_1 on 2024-01-22. Score: 2 | Accepted answer

Each node considers the *valid* chaintip with the *most-work* that it knows about the canonical state of the network. Only this "best chain" matters to establish the state of the UTXO set. If another chaintip overtakes the prior best chain, the node reverts blocks until it arrives at the highest common previous block and then applies the new chain.

The nodes only need to assess the header of the block. Each block mentions its predecessor in the header, so the node can see where a block attaches to the blockchain. If a new block header is not leading to a better chaintip, nodes will not even retrieve the block. username_2 recently wrote a [detailed description of how block synchronization works today](https://bitcoin.stackexchange.com/a/121293/5406), if you want to understand the process in more depth.

Of course a miner could extend whatever chaintip they want, however not only are stale chaintips easy to identify, the miners will also lose money on doing so:  
The best chain is a single-file connection between Genesis block and the best chaintip. Every block has exactly one predecessor and you can only spend coinbase transaction outputs (i.e. the mining reward) when they have 100 confirmations. Stale chaintips are not part of that best chain, and therefore the block rewards are paid to outputs that don’t exist in the best chain. Mining on top of invalid blocks costs you the same effort, but nets you zero revenue.

> **Comments:**
> **username_0**: Ah right, thanks, that makes sense. But wouldn't that mean blocks can't be published with previous blocks on invalid chaintips? Does that restrict miners to only publishing blocks on the chain that the node considers the longest?  
> **username_1**: Any miner can extend whatever chaintip they want, it’s just that if their block isn’t part of the best chain in the long run, they’ll find it hard to sell their mining reward, because the output doesn’t exist in the best chain. The best chain is single-file, every block has exactly one predecessor and you can only spend coinbase transaction outputs when they have 100 confirmations. Mining on top of invalid blocks costs you the same effort, but nets you zero.  
> **username_0**: So if miners extend a shorter length chain, would I have to search UTXOs on that "branch" to see if their block is valid instead of using the UTXO set? Since surely the UTXO set the node has stored would just be valid for the longest chain.  
> **username_2**: @username_0 Your node will only download the headers of this new branch unless it actually is a (candidate) best block. Once the branch is extended long enough to potentially overtake (or at least tie with) the current best block in terms of work, it is downloaded and partially validated. The actual *full* validation that involves the UTXO set is only performed if it would actually be the best chain. See my answer here for more depth: https://bitcoin.stackexchange.com/a/121293/208  

---

