From: Cory Fields <lists@coryfields•com>
To: Gregory Maxwell <greg@xiph•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] UHS: Full-node security without maintaining a full UTXO set
Date: Thu, 17 May 2018 13:16:46 -0400 [thread overview]
Message-ID: <CAApLimg2vwfoDPb=q5X8NcU76UPfLSPBhNv=9ECqamK+cVTxmQ@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTHTK8Dve9xHW9yULa1yObWtmwmeKKcD_BMjON=RAw8Sg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]
Matt: That's a good point. I'll do up a chart comparing utxo size at each
block, as well as comparing over-the-wire size for each block. I think the
period of coalescing earlier this year should be a good example of what
you're describing.
Greg: heh, I was wondering how long it would take for someone to point out
that I'm cheating. I avoided using the word "compression", mostly to
side-step having the discussion turning into reworking the wire
serialization. But you're absolutely right, the de-duping benefits are
independent of the UHS use-case.
Cory
On Thu, May 17, 2018, 12:56 PM Gregory Maxwell <greg@xiph•org> wrote:
> On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > Tl;dr: Rather than storing all unspent outputs, store their hashes.
>
> My initial thoughts are it's not _completely_ obvious to me that a 5%
> ongoing bandwidth increase is actually a win to get something like a
> 40% reduction in the size of a pruned node (and less than a 1%
> reduction in an archive node) primarily because I've not seen size of
> a pruned node cited as a usage limiting factor basically anywhere. I
> would assume it is a win but wouldn't be shocked to see a careful
> analysis that concluded it wasn't.
>
> But perhaps more interestingly, I think the overhead is not really 5%,
> but it's 5% measured in the context of the phenomenally inefficient tx
> mechanisms ( https://bitcointalk.org/index.php?topic=1377345.0 ).
> Napkin math on the size of a txn alone tells me it's more like a 25%
> increase if you just consider size of tx vs size of
> tx+scriptpubkeys,amounts. If I'm not missing something there, I think
> that would get in into a very clear not-win range.
>
> On the positive side is that it doesn't change the blockchain
> datastructure, so it's something implementations could do without
> marrying the network to it forever.
>
[-- Attachment #2: Type: text/html, Size: 2643 bytes --]
next prev parent reply other threads:[~2018-05-17 17:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-16 16:36 Cory Fields
2018-05-17 15:28 ` Matt Corallo
2018-05-17 16:56 ` Gregory Maxwell
2018-05-17 17:16 ` Cory Fields [this message]
2018-06-07 9:39 ` Sjors Provoost
2018-06-10 23:07 ` Jim Posen
2018-05-18 15:42 ` Alex Mizrahi
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='CAApLimg2vwfoDPb=q5X8NcU76UPfLSPBhNv=9ECqamK+cVTxmQ@mail.gmail.com' \
--to=lists@coryfields$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(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