Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

[Johnson Lau <jl2012@xbt.hk>]

[-- Attachment #1.1: Type: text/plain, Size: 1680 bytes --]

How is this compared to my earlier proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html> ?

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.
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 2646 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 671 bytes --]