By 'currently valid' I'm assuming you mean unspent outputs.
Two problems I can see right now;
Firstly, the UTXO set is rather large. There are roughly ten million unspent transaction outputs. Would you store txid and output only, or the entire transaction? Even the former case could take up hundreds of megabytes.
Yes, unspent outputs, that's the term I should have used. My objective here was to make the blockchain being used smaller for devices such as smart phones etc rather than relying on a trusted node, e.g. many mobile wallet providers give a view of the blockchain to the wallet client from a central sever that stores an entire copy of the blockchain, from what I understand.
In this instance I'm suggesting storing the entire transaction I guess (not thought this one through fully) as if it is in a previous block then trust that that transaction is valid is implicit (based on its depth in the blockchain).
Secondly, how do you propose that a client verifies the UTXO set it receives is valid? Currently we achieve a UTXO set by cumulatively verifying from the genesis block.
What security does a smart phone wallet employ when it gets its view of the blockchain via its central server? This is a questions as I don't fully know the answer.
My thinking was that if you're using a keyframe block then at least you know all the nodes who've propagated it have checked its validity. Perhaps having it as a side chain may work better.
And an issue rather than a problem;
The reference client already stores a full UTXO database. There is no need for this to propagate over the network. After bootstrapping it would be technically possible for bitcoin-core to discard older blocks. It just doesn't do that at present.
This is an issue of convenience versus file size and bandwidth. Perhaps this idea is infeasible or there are better possible solutions but right now for me at least I know the current blockchain size is causing problems on some wallets.
When you say "discarding older blocks" are you talking about just storing the UTXOs in the database?