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

Johnson Lau jl2012 at xbt.hk
Fri May 20 09:46:32 UTC 2016


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160520/532a993f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 671 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160520/532a993f/attachment.sig>


More information about the bitcoin-dev mailing list