How is an old block that forks the chain being validated in Bitcoin Core

[BusinessChain]

In the Bitcoin Core source code https://github.com/bitcoin/bitcoin/blob/21ee676dd6a7d9704367b6412bf8e1e443ec2b5b/src/chainparams.cpp#L139 I see that the latest checkpoint is at height 295000.
If I understand correctly, this means that today a miner could produce a block with height 295001. Although this block would not go into the main chain of course it still has to be validated by all nodes, and if valid, it would go into the secondary chain pool.
My question is, how is this block validated, since it is not known anymore what the state of the UTXO set was at height 295000. My guess is that in order to validate, the node has to temporarily reorganize the UTXO set to height 295000, check if block 295001 is valid, if yes store it, otherwise reject it, and then restore the current state of the UTXO.
 
Looks like a lot of work. Is that the way it works?

[1713984947]

1713984947

[1713984947]

1713984947

[1713984947]

1713984947

[1713984947]

1713984947

[darosior]

The proof-of-work is checked first, and in order to make a node validate a block that old, a miner would have to produce a chain of blocks with more total work than the one from 295000 to current height. If you are interested here is the work comparison function.

[gmaxwell]

What darosior said, plus it doesn't even fetch or store the block until it has headers that indicate it would be on the most-work chain assuming it at all its ancestors are valid.

[BusinessChain]

ok so let's assume there is a long valid fork that is stronger than mainchain. This might happen if a split network rejoins. How would the reorganization of the UTXO take place? Please describe the process.

[gmaxwell]

ok so let's assume there is a long valid fork that is stronger than mainchain. This might happen if a split network rejoins. How would the reorganization of the UTXO take place? Please describe the process.

If another branch gets more work it will fetch the blocks on it, undo the blocks on its current chain back to the point of the fork, then it applies the new blocks. If it encounters invalidity in the new blocks it marks the invalid block and any descendants as invalid which would make that branch no longer the longest, then it would undo back to the common ancestor and apply forward back up to the tip.

So your original thinking is close, except it doesn't even start fetching the data or storing it unless it would be the best chain by POW if it was also valid.