In my proposal, only the (pruned) UTXO set, and 32 bytes per archived block, are required for mining. But it is probably more difficult for people to spend an archived output. They need to know the status of other archived outputs from the same block. A full re-scan of the blockchain may be needed to generate the proof but this could be done by a third party archival node.

## Implementation

Our proposed high-performance/low-latency delayed commitment full-node
implementation needs to store the following data:

1) UTXO set

   Low-latency K:V map of txouts definitely known to be unspent. Similar to
   existing UTXO implementation, but with the key difference that old,
   unspent, outputs may be pruned from the UTXO set.

2) STXO set

   Low-latency set of transaction outputs known to have been spent by
   transactions after the most recent TXO commitment, but created prior to the
   TXO commitment.

3) TXO journal

   FIFO of outputs that need to be marked as spent in the TXO MMR. Appends
   must be low-latency; removals can be high-latency.

4) TXO MMR list

   Prunable, ordered list of TXO MMR's, mainly the highest pending commitment,
   backed by a reference counted, cryptographically hashed object store
   indexed by digest (similar to how git repos work). High-latency ok. We'll
   cover this in more in detail later.