I can answer for Bitcoin Core, but know there exists software that works very differently.
I can imagine that in the situation the new chain is clearly longer, the node would have to revert its UTXO set to the point at which the chains diverged, add back mempool transactions that were used since the chains diverged, and then re validate all blocks in the new chain.
Exactly.
How is the UTXO set reverted? Do nodes maintain a history of UTXO set diffs?
Yes. For every block that is part of the active main chain, “undo” data is maintained, which contains all the UTXOs spent by the block. If you see the UTXO set as a database, and blocks as “patches” of modifications applied to it (together with signatures to authorize the changes), then the undo data consists of the reverse patches (without signatures). The undo data is stored in the blocks/rev?????.dat files in the data directory.
In the case where the length of the chains are not significantly different, I can imagine that a node might want to maintain both chains concurrently until it becomes clear one will be longer. Are nodes programmed to do this?
No, there is always exactly one active chain, and Bitcoin Core only maintains a UTXO set for the tip block of that chain. The rule is:
- Consider all blocks which are not invalid and have no invalid ancestors.
- Consider only those among that set whose accumulated chain work is maximal.
- If there are multiple, pick the one for which the tip was received first.
What is the longest reorg a node can handle without revalidating the entire chain from the genesis block?
Any depth reorg should be handled correctly, down to the last checkpoint that has been passed. But those may be removed soon.
If a reorg is sufficiently deep (I believe 10 blocks or more), re-adding transactions back to the mempool is not performed (just keeping track of those transactions during the reorg can use unbounded much memory otherwise).
