Would a normalized, hashed, protected chainstate reduce miner storage costs? Spending freshly generated coins is prohibited by the protocol until there are at least 100 blocks on top of the block from which they came.  This is because the chances of a 100-block reorg is virtually zero.

The chances of a reorg of 1,000 or 10,000 blocks is even lower.  If the chainstate data is normalized, then its hash can be included in each block so that messing with it is as impossible as messing with the blockchain itself.  Would we then be able to prune off all but the last 10,000 blocks?

I know the transaction history is valuable, but under the assumption that we will never see a reorg larger than a particular number of blocks, I suspect it isn't necessary for mining once the chainstate is protected as well as the entire blockchain has been.

It seems to me that normalizing the chainstate so that it can be hashed and protected (like block headers are) would allow validation and mining without having to save the entire blockchain.  That way, only those who really want the history would need to save it.

Am I missing something?
You don't actually need to commit to the chainstate in blocks - just compute it the normal way, but throw away the block data after validation.

In fact, that's exactly what the pruned mode in Bitcoin Core 0.11 does, and it supports mining.

Storing the hash of the chainstate into blocks does have other advantages, like being able to skip processing historical blocks entirely if you're willing to trust a miner majority to commit to a correct one. However, it comes at a very significant cost for validation, as this hash would have to be recomputed and verified with the entry inside every block.