MIME-Version: 1.0
References: <CAApLimjfPKDxmiy_SHjuOKbfm6HumFPjc9EFKvw=3NwZO8JcmQ@mail.gmail.com>
	<CAAS2fgTHTK8Dve9xHW9yULa1yObWtmwmeKKcD_BMjON=RAw8Sg@mail.gmail.com>
In-Reply-To: <CAAS2fgTHTK8Dve9xHW9yULa1yObWtmwmeKKcD_BMjON=RAw8Sg@mail.gmail.com>
Reply-To: lists@coryfields.com
From: Cory Fields <lists@coryfields.com>
Date: Thu, 17 May 2018 13:16:46 -0400
Message-ID: <CAApLimg2vwfoDPb=q5X8NcU76UPfLSPBhNv=9ECqamK+cVTxmQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="000000000000b66287056c6a0038"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] UHS: Full-node security without maintaining a
 full UTXO set
Precedence: list

--000000000000b66287056c6a0038
Content-Type: text/plain; charset="UTF-8"

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

--000000000000b66287056c6a0038
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Matt: That&#39;s a good point. I&#39;ll do up a chart com=
paring 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&#39;re describing.<div dir=3D"auto"><br></div><di=
v dir=3D"auto">Greg: heh, I was wondering how long it would take for someon=
e to point out that I&#39;m cheating. I avoided using the word &quot;compre=
ssion&quot;, mostly to side-step having the discussion turning into reworki=
ng the wire serialization. But you&#39;re absolutely right, the de-duping b=
enefits are independent of the UHS use-case.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Cory</div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">On Thu, May 17, 2018, 12:56 PM Gregory Maxwell &lt;<a href=3D"mai=
lto:greg@xiph.org" target=3D"_blank" rel=3D"noreferrer">greg@xiph.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 16, 2018 at 4=
:36 PM, Cory Fields via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefer=
rer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br>
&gt; Tl;dr: Rather than storing all unspent outputs, store their hashes.<br=
>
<br>
My initial thoughts are it&#39;s not _completely_ obvious to me that a 5%<b=
r>
ongoing bandwidth increase is actually a win to get something like a<br>
40% reduction in the size of a pruned node (and less than a 1%<br>
reduction in an archive node) primarily because I&#39;ve not seen size of<b=
r>
a pruned node cited as a usage limiting factor basically anywhere. I<br>
would assume it is a win but wouldn&#39;t be shocked to see a careful<br>
analysis that concluded it wasn&#39;t.<br>
<br>
But perhaps more interestingly, I think the overhead is not really 5%,<br>
but it&#39;s 5% measured in the context of the phenomenally inefficient tx<=
br>
mechanisms ( <a href=3D"https://bitcointalk.org/index.php?topic=3D1377345.0=
" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://bitcoi=
ntalk.org/index.php?topic=3D1377345.0</a> ).<br>
Napkin math on the size of a txn alone tells me it&#39;s more like a 25%<br=
>
increase if you just consider size of tx vs size of<br>
tx+scriptpubkeys,amounts.=C2=A0 If I&#39;m not missing something there, I t=
hink<br>
that would get in into a very clear not-win range.<br>
<br>
On the positive side is that it doesn&#39;t change the blockchain<br>
datastructure, so it&#39;s something implementations could do without<br>
marrying the network to it forever.<br>
</blockquote></div>

--000000000000b66287056c6a0038--