Do we need to maintain the ability to do a reorg over 100 blocks? 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.

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.

If I remember correctly, we've already done this by (sometimes?) making checkpoints in the Satoshi client at sufficiently large depths when new clients got compiled.

N = 4032 would ensure that two difficulty levels are spanned.
N = 100 would change the pain of a 100-block reorg from something barely tolerable to something impossible.

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.

EDIT: Why I asked: It would be nice to validate a UTXO database so that one didn't have to build it from (always increasing GBs of) downloaded block data.  We validate transactions before passing them on, but do we validate them when we download a(n old enough) block?  I think we trust that whatever (old enough) block we get from a peer contains good transactions, so we don't hunt all previous blocks to validate them.  If this trust is already being used, as I suspect, perhaps it is more useful than we know.  I asked a related question: Would a normalized, hashed, protected chainstate reduce miner storage costs?.  I'll have to explore the work on making a UTXO Merkle tree as that seems promising.
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.