From: Johnson Lau <jl2012@xbt•hk>
To: Peter Todd <pete@petertodd•org>,
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments
Date: Fri, 20 May 2016 11:46:32 +0200 [thread overview]
Message-ID: <68A4772D-D423-45F9-ADB7-95BEB3E66F43@xbt.hk> (raw)
In-Reply-To: <20160517132311.GA21656@fedora-21-dvm>
[-- 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 --]
next prev parent reply other threads:[~2016-05-20 9:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-17 13:23 Peter Todd
2016-05-17 14:03 ` Jameson Lopp
2016-05-17 14:25 ` Eric Lombrozo
2016-05-17 18:01 ` Chris Priest
[not found] ` <CABm2gDoj=6CimHm2C0H_qa=o5SRqWr0ZTGamf-qT-kUjt5WXTA@mail.gmail.com>
[not found] ` <CABm2gDqMQanaY0Eo4QAnx2MrKCSP+v31R6J80jSVx+jOwsVsVw@mail.gmail.com>
2016-05-18 11:14 ` Jorge Timón
2016-05-18 23:53 ` Peter Todd
[not found] ` <CABm2gDrXjg_nSKr-ju0jdXxmMc4N=LQFRwaVU3ix1p-T8CVKdQ@mail.gmail.com>
[not found] ` <CABm2gDrmRf9wjddiMb-TTDE0xkBJ6yMz-bW_aTpDuBvNqrnHzQ@mail.gmail.com>
[not found] ` <CABm2gDqfZh0zOqJN5itVk8eP0nshBsydzT6uryrBdRTcYqyhyA@mail.gmail.com>
[not found] ` <CABm2gDr4ZKvGt3qRPpV+iPgGbpQ5cO66M_bPn2HJPn-eYcQMOg@mail.gmail.com>
[not found] ` <CABm2gDrijEMZW1dMjGTfG-32VGvLZvX-ujP1n5mxBeVLQSsL1Q@mail.gmail.com>
[not found] ` <CABm2gDp9N3ZEZcmF28ESv3V7v_HqU5e5KHY69cSxcVm0t7BeDQ@mail.gmail.com>
2016-05-19 9:31 ` Jorge Timón
2016-05-19 22:23 ` Nick ODell
2016-05-20 8:45 ` Peter Todd
2016-05-20 9:46 ` Johnson Lau [this message]
2016-05-22 8:55 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68A4772D-D423-45F9-ADB7-95BEB3E66F43@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox