Block-Size Proposal: "Pruning Blocks"

I'm rethinking the need to include the actual UTXO list in the blockchain.

Similar functionality can be achieved by including just the hash of all UTXO's in the block header. The actual UTXO's would then be stored and published off-chain as desired by 3rd parties. This reduces the amount of storage needed on the blockchain, but still provides checks and balances for new nodes to get the head of the blockchain with the correct UTXO set.

Here would be a typical use case:

1) A new node downloads a UTXO list from a third party for a block that meets their desired safety standards (older block = more safety, newer block = more risk).
2) The blockchain is downloaded from that block on.
3) The UTXO list is hashed and compared to the UTXO hash of the block.
a) If the hash does not match, goto 1.
Note: This forces third parties to come up with a balance list that has the exact same hash as the actual UTXO set balance. Hash collisions allow for other potential fake balances to match at this point.
4) The remaining blocks are downloaded. For each block:
a) The UTXO list is updated for the new block, hashed, and compared against the UTXO hash of that block.
b) If the hashes do not match or the block is not valid, goto 1.
Note: This will virtually guarantee a true UTXO balance with an appropriately selected hashing method. They may be able to fake the first block's UTXO balance, but the odds of being able to apply the transactions on top of that and get the same UTXO hash as the actual UTXO list for the next block will be astronomically small, and astronomically smaller with each successive block.
5) Verify the head of the chain matches the head of the desired blockchain.
a) If not, goto 1.
6) The new node now has a dependable UTXO set and the desired blockchain.

My main concern with this is the affects on miners generating the hash of UTXO's for each block. For example, when a pool receives a new block, they must first validate the UTXO hash for that block before they accept it, and then create the UTXO hash for the next block before they can begin work on the next one. This means that the miner that successfully mined the last block will have a head start on everyone else (since they already validated their UTXO hash), and it will also mean downtime for pool miners while they wait for their pools to get the new UTXO hash and block for them to do work on. Also, when a transaction is added to a block, the UTXO hash must be re-generated causing further delays, which will decrease the incentive to include more transactions as they come.

I believe those concerns can be alleviated by choosing an appropriate UTXO hashing algorithm where additions and subtractions to the UTXO list will not require a full scan to create the new UTXO hash. Furthermore, because of step 4b above, the hashing algorithm must also be chosen such that two UTXO lists that share the same hash but have different contents should not (except for rare, unpredictable collisions) produce the same new hash after the same transaction list is applied to both UTXO lists.