Do we need to maintain the ability to do a reorg over 100 blocks?
If the protocol were changed to use this, then a UTXO database based on the results of the blockchain up to the checkpoint block could replace the gigabytes of blockchain that we currently use for validation.


You can already do something similar to this by turning on -prune. That can cause your node to stop working if the reorg is more than 288 blocks, though as you noted, that doesn't happen often.

That still requires you to download the entire blockchain in the first place, of course.


  If we decide that "the chain with the most difficulty" means "the chain with the most difficulty over the last N blocks" and pick a good N, it could make some things simpler AND make transactions at a depth of at least N immune to a 51% attack. Thus, it limits the value of cornering the market in hashing power. Such "cornering" could happen without being noticed, so it has begun to worry me.


Suppose a node joins later, after the new chain has been published. From its perspective, the two chains were created at the same time. Because of that, it would naturally choose the one with more work attached to it.

So how do we avoid that? This is a problem that's a lot more complicated than it looks.


  The protocol requires that freshly generated coins wait 100 blocks before they can be spent in order to avoid polluting bitcoin addresses with bitcoins that are "uncreated" by a reorg that invalidates the block that created them.


Sure, but we're talking about two levels of consequences. In one circumstance, one person on the network loses money. In the other, the blockchain is forked forever.