<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">How is this compared to my earlier proposal:&nbsp;<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html" class="">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html</a>&nbsp;?<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class=""><br class=""></div><div class=""><div class=""><br class=""><br class="">## Implementation<br class=""><br class="">Our proposed high-performance/low-latency delayed commitment full-node<br class="">implementation needs to store the following data:<br class=""><br class="">1) UTXO set<br class=""><br class=""> &nbsp;&nbsp;&nbsp;Low-latency K:V map of txouts definitely known to be unspent. Similar to<br class=""> &nbsp;&nbsp;&nbsp;existing UTXO implementation, but with the key difference that old,<br class=""> &nbsp;&nbsp;&nbsp;unspent, outputs may be pruned from the UTXO set.<br class=""><br class=""><br class="">2) STXO set<br class=""><br class=""> &nbsp;&nbsp;&nbsp;Low-latency set of transaction outputs known to have been spent by<br class=""> &nbsp;&nbsp;&nbsp;transactions after the most recent TXO commitment, but created prior to the<br class=""> &nbsp;&nbsp;&nbsp;TXO commitment.<br class=""><br class=""><br class="">3) TXO journal<br class=""><br class=""> &nbsp;&nbsp;&nbsp;FIFO of outputs that need to be marked as spent in the TXO MMR. Appends<br class=""> &nbsp;&nbsp;&nbsp;must be low-latency; removals can be high-latency.<br class=""><br class=""><br class="">4) TXO MMR list<br class=""><br class=""> &nbsp;&nbsp;&nbsp;Prunable, ordered list of TXO MMR's, mainly the highest pending commitment,<br class=""> &nbsp;&nbsp;&nbsp;backed by a reference counted, cryptographically hashed object store<br class=""> &nbsp;&nbsp;&nbsp;indexed by digest (similar to how git repos work). High-latency ok. We'll<br class=""> &nbsp;&nbsp;&nbsp;cover this in more in detail later.<br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>