On Sun, Dec 13, 2015 at 6:11 PM, jl2012--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Back to the topic, I would like to further elaborate my proposal.

We have 3 types of full nodes:

Archive nodes: full nodes that store the whole blockchain
Full UTXO nodes: full nodes that fully store the latest UTXO state, but not the raw blockchain
Lite UTXO nodes: full nodes that store only UTXO created in that past 420000 blocks

There is a risk that miners would eventually react by just refusing to accept blocks that spend dormant outputs.  This is a risk even without the protocol, but I think if there are already lots of UTXO-lite nodes deployed, it would be much easier to just define them as the new (soft-forked) consensus rule.

There is a precedent for things to be disabled rather than fixed when security problems arise.

Imagine a crisis caused by a security related bug with the revival proofs.  Disabling them is much lower risk than trying to find/fix the bug and then deploy the fix.  The longer it takes, the longer the security problem remains.
 

What extra information is needed?

(1) If your UTXO was generated in block Y, you first need to know the TXO state (spent / unspent) of all outputs in block Y at block (Y + 420000). Only UTXOs at that time are relevant.

(2) You also need to know if there was any spending of any block Y UTXOs after block (Y + 420000).

Is this how it works?

Source transaction is included in block Y.

If the output is spent before Y + 420,000, then no further action is taken.

The miner for block Y + 420,000 will include a commitment to merkle_hash(Block Y's unspent outputs).

It is possible for someone to prove that they didn't spend their transaction before Y + 420,000.

I think the miners have to remember the "live" UTXO merkle root for every block?

With the path to the UTXO and the miner can recalculate the root for that block.

If there were 20 dormant outputs being spent, then the miner would have to commit to 20 updates.